Model · How an engagement is structured
One person owns your outcome. The engine sits behind them.
Most firms make you choose: a senior you trust, at a rate that hurts, or a distributed team at a price that works and a distance you have to absorb. We split the role instead. The person who owns your result sits in your working hours. The team that builds and proves it does not need to.
The split
Two jobs, fused by habit. We separate them.
An engineer who owns a customer is doing two jobs at once: holding the relationship and the intent, and running the build. They are different jobs. They need different things. And they do not have to happen in the same building — or the same country — once you can show your working.
So the seat that owns your outcome sits close to you. The pod that builds and verifies sits where the cost base is. What connects them is not optimism about communication; it is a stack of evidence that means the same thing wherever it was produced.
The pod
Four seats that are never left empty.
When generating code got cheap, the junior-heavy pyramid stopped making sense. The unit of delivery is now a small group that owns one outcome end to end, rather than a large team that owns a backlog. One person can hold more than one seat — with a single exception, below.
The exception: nobody verifies what they built. Multi-role is fine and normal on a small team. One engineer building one thing and verifying a different thing is fine. The same person signing off their own work is not, and no deadline has ever been a good enough reason.
The chain of custody
The paperwork that settles the worst conversation.
Every services firm eventually has the same conversation: this is not what we asked for. It is unwinnable from a distance if the only record is memory and a thread of emails. So the record is built as the work happens, not reconstructed afterwards when it is already too late.
- 01
Every change request is a document
Versioned in the repository, with its criteria written down, its design attached, and a feasibility review signed off with your technical contact before it locks. After lock, a change is a new revision — never a verbal adjustment someone half-remembers.
- 02
Every contribution is attributable
Each role's work lands as a commit against the change it belongs to. The audit trail is not a document someone maintains; it accumulates as the residue of working in the open, which is why it costs almost nothing to produce.
- 03
The trail settles the argument
When a delivery matches the signed spec, this is not what we asked for stops being a negotiation about competence and becomes a review of an approved document — one you can hold us to from any time zone.
Your data
What may reach a model, and what may not.
An engineering practice that uses AI has a security question the old review was never built to catch. Keeping secrets out of source control is the floor. The ceiling is that a careless prompt can put your regulated data across a border and into a vendor's retention window, and no code review will ever see it happen.
So it is settled in writing before any work starts: what data may enter a model context and what is redacted or synthesised first; which endpoints and retention terms are permitted and which cross a border we may not cross; where a private or on-premise model is required instead of a public API; and, in regulated work, which named credentialed person signs the correctness gate and carries the accountability a firm and an agent cannot.
A practice that proves the code correct while leaking your data through a prompt has proved the wrong thing.
The honest edges
Where this model stops working.
A trail proves conformance, not fitness. When what we delivered matches what you signed, the record settles it. When the delivery matched the spec and still did not do what you needed, the record settles nothing — that is a different failure, it is usually more expensive, and we treat it as its own category rather than filing it under yours.
It needs you to be able to say what you want. This structure runs on intent that can be written down and locked. If you are genuinely still discovering what the product should be, a feasibility-gated lock is the wrong instrument, and we would rather scope a discovery engagement than sell you a machine that fights you.
We are describing our structure, not a track record for it. This is how our engagements are organised and what you would be handed. We are not claiming it has been run end to end, start to finish, across a full engagement and measured — because it has not, and you should discount anyone who tells you their method is finished.
FAQ
What buyers ask about the structure.
Where are your engineers actually based?
Isn't this just offshore delivery with a nicer name?
Who do I actually talk to?
What happens when something conforms to the spec but still doesn't work for us?
Does the verifier really stop releases?
Ask who'd own your account.
Thirty minutes, no deck. We'll tell you which seat you'd be talking to, what the pod behind them looks like, and what lands in your inbox at each checkpoint.