Five stages, and an exit at every one.
You should be able to stop after any stage and still be better off than when you started. That is the whole design of this.
This page is the leave-behind. It is written to be printed — Cmd+P gives you the whole method on paper, with every link spelled out. We do not send a PDF, because a PDF goes stale the day after you file it.
The briefing
45 minutes with your engineers and the person who owns the problem. We are working out whether there is a real system to build and whether we are the right firm for it. No charge, no deck.
Read the systems and the work
We sit with the people doing the task, read the systems it touches, and count what it actually costs today. Most of what we learn contradicts the brief, which is the point. You end with a written scope, an estimate, and a recommendation that is sometimes to do nothing.
Build narrow, on your infrastructure
One workflow, real data, inside your VPC, with the failure cases handled rather than hidden. A build pod is chartered for the engagement — senior engineers on the calls, agent crews on the volume — and stays fixed until handover. Working software every week from week one. If the numbers do not hold up we stop here, and you keep everything built so far.
Hand over properly
Source, architecture documentation, runbook, and sessions with the team who will own it. Handover is a deliverable with a date on it, not a goodbye email. If your engineers cannot change the thing themselves, we have not finished.
Stay useful, optionally
Some clients keep us on for monitoring, cost review, and the next workflow. Others take it in-house and we hear from them a year later. Both are fine, and the contract does not push you toward either.
Code, prompts, data and documentation are yours from the first commit, on your accounts and inside your cloud.
Not status reports. Something your team can run, every week, from the first one.
If a query and a rule solve it, that is our recommendation, and we will help you write the rule.