Infrastructure & Release Engineer

We should be straightforward about the situation you would be walking into, because it is the whole job.

We run a large multi-service codebase with a high rate of schema change and continuous deployment. We deliberately do not run automated test or typecheck gates in CI — that was a considered decision to maximise shipping speed, and at a single engineer with full context it was the right one. Correctness is currently held by one person's attention and a large body of hard-won convention.

That model has a known expiry date, and team growth is it. More builders without a verification layer do not create proportional output; they create a shared codebase where nobody can tell whether a change was safe until a customer finds out.

This role exists to build the systems that let product engineers move quickly without making reliability depend on founder memory. It is deliberately separate from the senior product role: you own the delivery, migration, access, and operational foundations they build on.

• The verification layer, from nothing. Test and typecheck gates, what runs when, and — the harder half — what is fast enough that people do not route around it. A gate everyone learns to skip is worse than no gate.
• Release and deployment. Multiple independently-deployed services across a monorepo, plus a signed and notarized desktop client. Making "merged" and "actually running in production" the same statement, which today they are not.
• Migration safety. A high volume of schema changes against a live production database, with real ordering and collision hazards. You will own the tooling that makes an unsafe migration fail at review time instead of at apply time.
• Database authorization. Row-level security policies, privilege grants, and the audit posture around them. A meaningful part of the first six months is a remediation program that is already scoped and waiting for an owner.
• Production observability. Today an error surfaces when someone goes looking. You will own turning that into something that reaches a person on its own.
• Internal IT foundations. Practical device, account, access, and support systems appropriate for a small team serving larger organizations.
• Dependency and supply-chain hygiene. Regular, unglamorous, and genuinely load-bearing.

• You have built this before, at a small company, without a platform team behind you. Not "operated a mature pipeline" — built one from close to zero, under delivery pressure, for engineers who did not initially want it.
• Strong Postgres operations. Migration mechanics, lock behaviour, and row-level authorization models. This is closer to a database-focused role than a pure cloud-infrastructure one, and if the phrase "row-level security policy" is unfamiliar this is probably not your role.
• You optimize for the pipeline people actually keep. The instinct that a slow or noisy gate will be bypassed, and that this is a design failure rather than a discipline failure.
• Security as a practice, not a checklist. Auth boundaries, secret handling, and least privilege as things you reason about rather than audit for.
• You can hold the line and stay liked. You will sometimes be the reason a change does not go out today. Doing that without becoming an obstacle everyone routes around is most of the job.

• You have introduced testing or CI into a codebase that had none and can describe how you got adoption rather than compliance.
• Experience with a managed Postgres platform and its authorization model in production.
• You have owned code-signing and release pipelines for a desktop application.
• You have run an incident and written the postmortem, and you treat the second part as the important one.

We are a very small, distributed, engineering-led team, and we ship continuously. No standups for their own sake, no story points, no committee between you and production.

The specific thing to understand about this role: you are not being hired to slow us down. Our shipping speed is a real competitive advantage and we intend to keep it. You are being hired because the current speed depends on a single person holding the whole model in their head, and that does not survive a team. The mandate is to make the fast path also the safe path.

You will have unusual latitude — this is a greenfield mandate inside an established codebase, and you will largely set your own priorities against the outcomes above.

Fair warning on ramp: the codebase is large and much of the operational knowledge is still undocumented. Your first month will involve a lot of reading and a lot of questions.

Competitive salary and meaningful equity. We will give you the band in the first conversation rather than making you ask.

The process is short and grounded in what you have actually run:

1. A 45-minute conversation with our founder about the current state and what you would be taking on.
2. A technical deep-dive on infrastructure you have built — specifically how you got engineers to adopt it.
3. A paid, scoped exercise: a design proposal against our real constraints, sized to a day. You will get an honest picture of the codebase for this.
4. A final conversation on how we work, comp, and your questions.

We do not do unpaid take-homes and we do not do surprise algorithm rounds.