HOW WE WORK
How we work.
How a project runs — from a written plan to software that works every day, with one person responsible the whole way.
Every engagement moves through the same three steps. Each step is paid for by the last — the $750 credits toward Design, the $20K Design fee credits toward the Build — and you can stop after any of them.
Nothing is hidden. You see the plan, the progress, and working software long before the end.
- 01Written plan first — scope, delivery path, and budget range on paper, agreed before any build begins.
- 02A written check-in every two weeks — what moved, what is next, and what is in the way, in writing, so you are never reconstructing progress from a meeting.
- 03Working software early — delivered in slices you can see and use, not revealed all at once on the last day.
- 04A clear acceptance step — you confirm it does the job before anything is called done.
- 05Everything is yours — the code, its documentation, and all you need to run and maintain it.
One operator directing a fleet of AI agents — and a separate one checking the work.
This is the part most firms leave out of the sales conversation, and it is the whole reason the arithmetic works. The work is executed by AI agents under direction, in parallel, at a volume one person could not reach by hand. That is not a discount and it is not a shortcut — it is the mechanism.
What makes it trustworthy is the second half: the agent that builds is never the agent that checks. Verification runs separately, against the written targets, and a person reviews every change before it ships. A builder grading its own homework is how AI work goes wrong, and it is the specific thing this method is designed around.
The consequence you can feel is the absence of a coordination tax. Nothing waits on a standup, a handoff, a spec written for someone else to read, or a second engineer being brought up to speed on your domain. There is one context, and it is held by the person accountable to you.
Why the builder can never be the verifier — the long form. Read it →
Yes, it is one person. Here is what that costs you, and what it buys you.
You are not worried about documentation. You are worried about month four of a six-figure build, or month fourteen of a retainer, and one person who stops answering. That is the right thing to worry about, and reassurance is not an answer to it. Structure is.
What it costs you
A team of forty has redundancy you do not get here. We are not going to pretend otherwise — it is the one row in the comparison below that an agency wins outright.
What we do about it
- Everything lives in your repository from day oneCode, runbook, and the architecture record land in a repository you own, continuously — not as a handover event at the end. There is no version of this where the work is trapped somewhere you cannot reach.
- Credentials live in your secret storeNever in a repository, ours or yours. You grant access scoped to the statement of work and you revoke it whenever you decide to.
- No standby engineer on retainer — and we will not pretend otherwiseSome firms answer this with a named successor kept on standby. We do not have one, and inventing one would be exactly the kind of reassurance this section refuses to give you. The structural answer is the one above: because the repository, the runbook and the credentials are already yours, whoever picks the work up — your own team, or someone you hire — starts from a written system rather than an excavation. That is a difference you can check in month one instead of discovering in month fourteen.
- An unavailability clause with teethIf ML LABS goes non-responsive for five consecutive business days, Operate fees stop and prorate to that date. You are not paying for silence, and the handover package is already in your hands because it always was.
What it buys you
No account team, no handoffs, no context reset, and nobody learning your system on your budget. The person who scoped it is the person who built it and the person who answers when it breaks. That is not available at forty engineers, at any price.
The bar we would want you to hold us to, written down before you hold us to it. Read it →
Three ways to get this built.
No throughput figures here, because we have not measured any we would be willing to defend. Everything above is a structural claim you can check against the contract.
It's one person — what if you're unavailable?
This is the right question and it deserves a structural answer, not a reassuring one. Every engagement is set up so that nothing you need lives only in one person's head or on one person's laptop: the code, the runbook, and the architecture record land continuously in a repository you own, and your credentials live in your own secret store, never in a repository at all.
On top of that the contract carries a named successor engineer who has read your runbook, and an unavailability clause: if ML LABS goes non-responsive, Operate fees stop and prorate, and the handover package is already yours because it always was. The full commitment, including the windows, is set out in the continuity section above.
It's one person — what if you're unavailable?
This is the right question and it deserves a structural answer, not a reassuring one. Every engagement is set up so that nothing you need lives only in one person's head or on one person's laptop: the code, the runbook, and the architecture record land continuously in a repository you own, and your credentials live in your own secret store, never in a repository at all.
On top of that the contract carries a named successor engineer who has read your runbook, and an unavailability clause: if ML LABS goes non-responsive, Operate fees stop and prorate, and the handover package is already yours because it always was. The full commitment, including the windows, is set out in the continuity section above.
You've seen the process. Run it on your problem.
A written plan before any build · Design and Build: full refund until you accept