Skip to content
Careers

Work on the hard part

Starting a project is easy now. Taking somebody else’s half-finished app, working out what will break it, and fixing that without breaking anything else is not. That is the job here, on real deadlines, with the original failure modes still in place.

See open rolesApply through the contact form

Roles open now

Applications go through the contact form. We reply to every one.

The work

What the work actually is

uBuilt is a production engineering practice, not a product team. Almost nothing you touch here will be greenfield.

You will spend most of your time inside codebases you did not write, generated quickly by somebody optimising for a demo, and your job is to make them safe to put in front of real users without stopping the founder from shipping in the meantime.

That means reading before writing. It means finding the two things that will genuinely hurt among the twenty that are merely untidy, and being able to defend that ranking to somebody who is paying for the difference. It means writing the fix, the test that proves the fix, and the paragraph that lets a non-engineer act on it.

The variety is real: a Supabase policy audit on Monday, a query-plan session on Tuesday, a migration rehearsal on Wednesday, a cost model on Thursday. So is the responsibility. When an app we manage goes down, the alert reaches an engineer here - and that engineer is expected to fix it, tell the client, and then write down why it happened so it cannot happen the same way twice.

Depth is available. Nobody is asked to be shallow across everything: most people here own one area properly - security, data, or infrastructure - and are competent in the rest.

Work that shows up most weeks

  • Rewriting row-level security policies and testing them role by role
  • Rotating a service-role key that shipped inside a client bundle
  • Moving a SQLite file off an ephemeral container disk onto managed Postgres
  • Adding the indexes a query plan asks for, then proving the p95 moved
  • Replacing a framework dev server with a real one, behind a health check
  • Standing up CI with preview environments and a rollback someone has rehearsed
  • Running the first restore drill a project has ever had, and finding out it fails
  • Writing the runbook the client’s team uses after we hand the work over

Composite of engagements; details anonymised.

Fit

Who this suits

We are small. There is no bench to hand work to and no manager translating between you and the client. That suits some engineers and quietly makes others miserable, so here is both sides of it.

You will do well here if

  • You have operated something in production and been on the wrong end of an incident. You know what the hour after the alert feels like.
  • You can own an incident end to end: detect, mitigate, fix, write it up, and tell the client what happened without varnishing it.
  • You read unfamiliar code without contempt for whoever wrote it - including when the author was a language model at 2am.
  • You can explain a risk to a non-engineer in one paragraph, without jargon and without frightening them into a rebuild.
  • You look for the smallest change that removes the risk before you look for the most correct architecture.
  • You are senior enough to decide and self-directed enough that “what should I work on” is a question you can usually answer yourself.

This is probably not the job if

  • You want a large team, a well-groomed ticket queue, and a spec somebody else wrote.
  • You need one codebase to live in for years. We are across many, and the context switching is the job rather than a side effect of it.
  • You would rather rewrite than read. Most of the value here is in what you decide to leave alone.
  • Client contact makes you uncomfortable. You will be on the call, and you will write the report that goes with it.
  • You only want to work on new tooling. A great deal of this is Postgres, HTTP, permissions, backups, and money paths.

None of these are character flaws. They are just a different job, and there are good ones out there.

Process

How hiring works

Four steps, no more than a few weeks, and you are paid for the part that takes real effort.

  1. 1

    You write to us

    Through the contact form. Tell us what you would want to own, one thing you have taken to production, and one incident you handled badly enough to still remember.

  2. 2

    A short call

    Around forty-five minutes with somebody who does the work, not a recruiter.

  3. 3

    A paid trial engagement

    A small, scoped piece of real client work at a rate agreed in writing before it starts.

  4. 4

    A decision, quickly

    We give you an answer within a week of the trial ending, with the reasoning behind it.

Rates are agreed in writing before the trial starts. We do not publish bands, because we would rather quote a number for the actual work than anchor you to a range that was invented for a careers page.

Open roles

Three shapes of engineer

Roles open when the work supports them. If the one you want is not listed, the general application below is not a formality - we read all of them.

  • Production Engineer

    The core role. Take an app that works on the founder’s screen and make it safe for real users - across security, data, performance, and deployment.

    Apply

    What you would own

    • Run production checks end to end: read the code, test the failure modes, write the report, rank the findings by what will actually hurt
    • Close critical and high findings, then prove they are closed with a test or a reproduction that now fails
    • Design schemas and indexes from query plans; make every migration reversible and reviewable
    • Stand up CI/CD with preview environments, automated checks, and a rollback path you have personally rehearsed
    • Instrument apps properly: error tracking, structured logging, uptime checks, alert thresholds that survive a week without being muted
    • Be the named engineer on a handful of managed apps, including when something breaks outside office hours

    What we look for

    • Several years building and operating web applications that had real users on them
    • Real Postgres depth: you read EXPLAIN output, you know what a missing index costs, and you have fixed an N+1 in production
    • Fluency in TypeScript or Python, and a willingness to work in whatever the client actually built
    • Practical security instincts around authorization, secrets handling, and dependency risk
    • Writing a founder can act on - clear, ranked, and free of hedging

  • Security Engineer

    Application security for teams that have none. Mostly authorization, secrets, and data exposure in small multi-tenant apps - not compliance paperwork.

    Apply

    What you would own

    • Lead the security half of production checks: authentication, authorization, access rules, injection and IDOR surfaces, upload handling
    • Test access policies against real role scenarios rather than reading them and forming an opinion
    • Build the secret-handling story: managed stores, per-environment scoping, and rotation after an exposure
    • Put dependency and secret scanning into CI, then triage the output so the alerts keep meaning something
    • Write findings with reproductions the client can run themselves, and severities you can defend
    • Help founders answer their first enterprise security questionnaire without overstating what is in place

    What we look for

    • Hands-on application security: you have found, reported, and fixed real vulnerabilities in real products
    • Deep understanding of authorization models, session handling, and multi-tenant data isolation
    • Working knowledge of Postgres row-level security and the specific ways it gets misconfigured
    • Enough engineering ability to write the fix, not only to file the finding
    • Severity judgement based on exploitability and blast radius rather than scanner output

  • Cloud / Platform Engineer

    Move apps off builder hosting onto infrastructure the client owns - without downtime, and without leaving them dependent on us afterwards.

    Apply

    What you would own

    • Design target architectures sized to measured traffic and a stated budget, then defend the choices in plain language
    • Write the infrastructure as code so an environment can be rebuilt from an empty account
    • Plan and rehearse zero-downtime data migrations, including the rollback nobody expects to use
    • Execute DNS, TLS, CDN, and domain cutovers with a measured window agreed in advance
    • Model cost before and after, at current traffic and at ten times it
    • Hand over runbooks, documentation, and a walkthrough so the client’s team can operate the result without a retainer

    What we look for

    • You have moved production systems between providers and been awake for the cutover
    • Terraform and Docker day to day; Kubernetes where it is warranted, and a clear opinion about when it is not
    • AWS or GCP depth, plus familiarity with the smaller platforms - Vercel, Fly, Railway, Render
    • Backups, restores, and the discipline to test them on a schedule rather than on an incident
    • Cost literacy: you can read a cloud bill and explain each line to a founder
Applying

Applications go through the contact form

There is no applicant portal and no résumé parser reading for keywords. Use the contact form, put “Careers” in the message, and a person will read it.

Applications are read in batches, usually once a week, by an engineer rather than a filter. If the timing is wrong on your side, say so - “not looking until the spring” is useful information, not a reason to wait.

If we are not hiring for your shape of work when you write, we will tell you that instead of leaving the message unanswered.

Include these four things

  1. 1Which role you are writing about - or what you would want to own if none of the three fit.
  2. 2One thing you took to production, and what broke after it went live.
  3. 3A link that shows how you work: a repository, a write-up, a postmortem, a pull request.
  4. 4Whether you are looking for contract work, something longer, or are not sure yet.

We reply to every application, including the ones where the answer is no.

Questions

Before you write

  • No. Production experience matters far more. If you have kept something running for real users and can explain the decisions you made, the client-facing part is learnable and we will help you with it.

  • Rarely, and we would rather say so plainly than waste your time.

  • Always, at a rate we agree in writing before it starts.

  • No. We look for depth in one area and the willingness to be useful in the others.

  • Write anyway and tell us what you would want to own.

No role that fits? Write anyway.

Tell us what you would want to own and one thing you have taken to production.

Open the contact form