Small team, real ownership, little ceremony
We build platforms and engineering systems for organisations that depend on them. That means engineers carry decisions rather than tickets, and stay responsible for what ships.
What the work actually looks like.
Written as we would want to read it, rather than as a recruitment brochure.
You are given the constraint, not the ticket
Work arrives framed as a problem to solve. You decide how to approach it, and explain the reasoning afterwards so others can correct it.
Review is about correctness and clarity
We review design and code because mistakes are expensive later, not because anyone is counting throughput. Arguing with a reviewer is normal here.
Decisions get written down
Trade-offs and runbooks are recorded while the reasoning is still fresh. Knowledge that lives only in a chat thread is knowledge that disappears.
You operate what you build
Engineers stay involved after release. If a design breaks at 2am, understanding it should not depend on somebody who has since left.
The areas the current work demands.
This is what we are hiring against. If your strength is elsewhere and you can prove it, we still want to read your note.
Backend engineering
Domain modelling, APIs, background processing and the unglamorous work that keeps a system correct under load.
Software engineering 02Frontend engineering
Accessible, fast interfaces with the awkward states designed properly: loading, empty, error and partial success.
Software engineering 03Infrastructure and reliability
Infrastructure as code, delivery pipelines, observability and the operating practice that makes a system dependable.
Cloud and DevOps 04Applied AI and automation
Retrieval, document intelligence, bounded agents, plus the evaluation and governance work that makes them dependable in production.
AI and automation 05Data and integration
Schema design, data migration and integration between systems that were never designed to speak to each other.
API and integrationSomething else entirely?
We are a small team and the shape of the work changes. Tell us what you have built and why it is built that way.
Introduce yourselfThere are no vacancies published today.
Keeping a list of roles we are not hiring for would be dishonest, so here is the actual position.
We are always interested in meeting strong engineers.
If you have built something you are proud of and can explain why it is shaped that way, we would like to hear about it. A short note, a repository or a paragraph about the hardest problem you have solved is enough to start.
Four steps, no surprises
- Introductory call, covering what you have built and what you want to build next
- Technical conversation, a real problem discussed out loud, no whiteboard tricks
- Paid work sample, scoped properly and paid at our normal rates
- Team fit, meeting the people you would actually work with
What we look for
- You can explain why a design is shaped the way it is
- You have thought about failure modes, not only the happy path
- You would rather remove a requirement than work around it
- You write clearly, because half of engineering is explaining
What working with us looks like.
The unglamorous parts, written down so you can judge them properly.
No translation layer
Small team, so you speak to whoever decides things. There is no account manager between your work and the client.
Learning budget tied to the work
Conferences, courses and books are funded when they connect to something you are actively working on.
You keep what you build
Systems you helped design stay yours to operate. We hand over properly rather than rotating ownership for convenience.
Have a look at how we work
The things we hire for are the things we argue about on the About page. Reading it first will save you both time.
No specific role required.
Send a short note about something you have built and what you would like to build next. We read everything that arrives.