Building the part that says no
We build guardrails for automation that touches money and personal data, which means most of the interesting work here is about what the software refuses to do. If you have ever argued that a feature should ship slower because nobody could explain what it would log, you will recognise the job.
How we work
Stated specifically enough to be falsifiable. If any of these stopped being true, someone on the team would notice and say so.
Decisions are written down before they are made
Proposals circulate as documents with the tradeoff stated in the first paragraph, not as a meeting invitation. It means fewer meetings, and it means a decision made eight months ago can still be explained to the person who has to live with it.
Security work is not a special project
Scope review, redaction behaviour, and audit coverage are part of shipping any feature, handled by whoever is building it. There is no separate team that arrives at the end to say no.
You are on call for what you build
Engineers carry the pager for their own services on a rotation that assumes a full night's sleep is the normal case. If a service pages more than twice a quarter, fixing that is the roadmap.
Async by default, deliberate about overlap
The team spans three time zones with four hours of common overlap, reserved for the conversations that genuinely need to be synchronous. Everything else happens in writing so nobody is a bottleneck for being asleep.
Engineers read the support queue
Every engineer spends one day a month on support rotation. It is the cheapest way to learn which of your abstractions are confusing, and it ends arguments about what users actually do.
We do not reward heroics
A weekend spent rescuing a launch is treated as a process failure to investigate, not a story to celebrate. Sustainable pace is a security property when your product holds other people's credentials.
Hiring plan
Each role describes the first six months of actual work rather than a list of required years. Expand one to read what you would own.
No roles are open right now. This page describes how the team works and what the hiring process involves, so it is worth reading before a future posting rather than after.
Hiring process
You get the role document before the first call, compensation is a published band we open at, and we pay for any exercise longer than an hour.
Written application
Reply within 5 working days
A note about something you built and what you would change about it. No cover letter, and we do not ask for a portfolio of side projects — what you do outside work is your own business.
Conversation with the hiring manager
45 minutes
45 minutes on what the role actually involves and what you are looking for. You get the same document the team uses to describe the role, before the call rather than after.
Technical discussion
90 minutes
We work through a real problem from our backlog, with the constraints we actually had. No whiteboard algorithms and no take-home longer than two hours; if we ask for code you are paid for the time.
Meet the people you would work with
2 x 30 minutes
Two conversations with future colleagues, at least one outside your function. This is as much your evaluation of us as ours of you, so it is unstructured on purpose.
Offer and reference conversation
Within 3 working days
Compensation is a band published in the role document, and we open at the band rather than at your last salary. References are a conversation about how you work, requested only after you have accepted in principle.