Case studies
What happened, including the bad weeks
Three teams, written up properly: the situation they were in, the request they filed, what the plan came back with, what went wrong, and what changed afterwards. Every number states how it was measured. Every study contains something that did not work.
Featured
Three studies
Tilltap
Four people, one storefront, and a deployment process that lived in one person's head. They earned each autonomy level in turn, and rolled back in front of an audience once.
Read the studyOrderly Health
A founder who cannot read a diff, running scheduling and billing tooling on plain-English plans — after learning the hard way what a one-sentence request produces.
Read the studyNorthwind Freight
A dispatch system whose author left in 2022, a first plan that targeted the wrong module, and a security pass that found something in the logs nobody wanted to find.
Read the studyCase study 01 · E-commerce
Tilltap
Four people · one storefront and an admin back end · moved Manual → Supervised → Autonomous over eleven weeks
The situation
Tilltap sells kitchenware online. Four people: two engineers, a designer who also does support, and a founder who also does everything else. The storefront is one repository, the admin back end is another, and both deploy to a single box over SSH by way of a shell script that one engineer wrote and one engineer understands.
Their problem was not writing code. It was that every change had to pass through the same person, and that person had opinions about Fridays. Code review happened when there was time. There was rarely time. The last security pass anyone could remember was a penetration test a customer had asked for.
What they filed
The first request was deliberately unglamorous: "Refunds partially applied to an order leave the order total wrong on the customer's invoice." A type, a priority, one sentence. The project sat at Manual autonomy, which meant nothing at all would run until a human pressed a button.
What the plan looked like
The Project Manager read both connected repositories and came back with five tasks and a dependency graph: a Database Engineer task to add a migration for the adjusted totals, two Backend Developer tasks that could not start until the migration existed, a Frontend Developer task for the invoice template, and a QA Engineer task at the end that depended on all four.
The founder read the plan summary. He is not an engineer and he understood it, which was the point of the exercise. He approved it. The four buildable tasks dispatched, each onto its own branch in its own git worktree, and each came back with a structured report — summary, files modified, risks, assumptions, recommendations, blockers.
The Code Reviewer rejected one of them. The backend task had introduced a new helper for currency rounding when the repository already had one, three directories away. The task was re-run with that noted, and merged on the second pass.
What went wrong
Two things, and the second one was their fault rather than ours.
A deploy failed at 2am. Six weeks in, at Supervised autonomy, a change to the order-search query shipped and the health check failed. The rollback command ran, the last healthy commit was restored, and an investigation opened with read-only access. By morning there was a written cause — the query relied on an index that existed on the engineer's machine and not on the server — and a follow-up request already filed with the fix. Nobody was woken. But the box did serve errors for the ninety seconds between the deploy and the health check failing, and their customers can count.
They moved to Autonomous too early, on the wrong project. They set the
admin back end to Autonomous in week seven because the storefront had been calm
for a month. The admin repository had a schema migration in its queue that the
founder would very much have liked to read first. Nothing broke. He did not
enjoy it. They dropped that project back to Supervised, left the storefront at
Autonomous, and put requires_review on the Database Engineer role
permanently. That flag is still there.
What changed
Review stopped being a thing they intended to do. Every merged change now carries a reviewer's verdict and a security note, because the gate is not optional and nobody has to be free on a Thursday for it to happen.
The founder's summary was less about speed than about the shape of the week: the deployment process is no longer stored in one engineer's head, and that engineer took a holiday in month three without leaving a phone number.
PLACEHOLDER — illustrative figures for a company that does not exist. A real study replaces these with numbers the customer has seen and agreed, and keeps the method sentence under each one.
Case study 02 · Healthtech admin (non-clinical)
Orderly Health
A founder with a clinic-scheduling and billing product, no engineering team, and an agency retainer that turned every small change into a three-week conversation. One quarter, told in three parts.
The situation and the request
Waiting on somebody else's calendar
Orderly Health builds admin tooling for private clinics — appointments, invoicing, reminders. Nothing clinical, nothing near a decision about a patient. The founder can write SQL, badly, and cannot read a diff. Every change went to an agency, came back as a quote, and landed about three weeks later.
- The first request — "Clinics in Scotland get the wrong bank-holiday dates on appointment reminders." One sentence, filed as a bug, priority high.
- The plan — Four tasks with owners and an order: a Backend Developer to replace the hard-coded holiday list, a Database Engineer for the region column, a Frontend Developer for the clinic settings screen, a QA Engineer at the end.
- What she actually read — The plan summary in plain English, not the code. At Manual autonomy nothing dispatched until she approved it, and the design preview link showed her the settings screen before a branch merged.
What went wrong
A one-sentence request buys a one-sentence answer
Two plans were rejected outright in the first quarter, and both rejections were earned. The second one taught her something about how she was writing requests.
- The rebuild that nobody asked for — A request reading "the invoice screen is slow" produced a plan to rebuild the screen. It was a defensible reading of what she wrote. She rejected it, re-filed with the specific slow report named, and got a two-task plan instead.
- The change that solved the wrong problem — One approved plan shipped cleanly and fixed something she had not meant. It merged, it passed review, it worked. It was simply not the thing. Reverting it was a request of its own.
- What fixed it — She began describing the symptom, the clinic it affected and the screen she saw it on — three sentences instead of one. Plan rejections stopped after week five.
Added the 3-D Secure challenge step to the card payment path.
### Files Modified
- app/payments/challenge.py — new challenge handler
- app/payments/gateway.py — route into challenge
- tests/payments/test_challenge.py — 11 cases
### Risks
- Wallet payments untested against the live sandbox
### Recommendations
- Run T-06 before deploying to production
What changed
She stopped booking calls to ask for things
Not faster software — a different relationship to her own product. The change she notices is that a small fix no longer requires anyone else's availability.
- Approval is the whole job — She stayed at Manual autonomy for the entire quarter and has no plans to leave it. Reading plans and approving them is a task she can do from a phone.
- Previews before merges — Every front-end task produced a shareable design preview link. Two clinics on her advisory panel now see screens before they ship.
- The agency still exists — She kept the retainer for the two integrations she does not want to own. It is a smaller retainer.
Shareable link, expires with the task. No deploy required.
PLACEHOLDER — illustrative figures for a company that does not exist. Method sentences are shown here as a template for the real thing.
Case study 03 · Logistics
Northwind Freight
Nine engineers · a dispatch system inherited from a contractor · first 30 days
The situation
Northwind Freight moves pallets around northern England. Their dispatch system
— routing, driver assignment, proof of delivery — was built by a contractor who
finished in 2022 and did not stay. It runs. It has no tests worth the name, two
directories that appear to do the same job, and a deployment script with a
comment in it reading # do not run twice.
Nine engineers work there, none of whom wrote it, all of whom are slightly afraid of it. It had reached the state where a change request was answered with an estimate and a facial expression.
What they filed
"Drivers assigned to a cancelled run still receive the pickup notification." A bug, high priority, filed by an engineering lead who already knew roughly where the fault was and wanted to see whether the plan would find it.
What the plan looked like
It did not find it. Not on the first attempt.
The repository contains both dispatch/ and dispatch_v2/. The first is
deprecated and still present; the second is what actually runs. The Project
Manager planned against dispatch/, produced three tasks that were internally
coherent and entirely irrelevant, and the engineering lead rejected the plan.
She then did the thing that fixed it permanently: she edited the project's
Architect role contract to state, in two sentences, that dispatch/ is dead
and dispatch_v2/ is live. The re-plan targeted the right module. No later
plan has made the same mistake, because the instruction is now a file in their
repository rather than a fact in somebody's head.
What went wrong
The security pass found something nobody wanted to find. In the first month, the Security Engineer flagged three findings across the requests it touched. One was a duplicated CSRF check, one was a missing authorisation condition on an internal endpoint, and one was a card number written into application logs by a payment-callback handler that had been running since 2022. That last one was not in scope for any request. It was found because the security role reads the surrounding code, and it produced a request of its own the same day.
Finding it was good. Having it there for three years was not, and the study would be dishonest without saying so.
An investigation stalled on a permission. A deployment failed its health
check in week three, rolled back correctly, and opened an investigation. The
investigation then got nowhere for forty minutes, because their diagnostics
command needed sudo and the investigation had read_only access, which is
the default and which they had not looked at. They rewrote the diagnostics
command to work without elevation. The next investigation completed in four
minutes.
Runs were burned on the wrong module. The rejected first plan still cost agent runs. Planning is not free, and a repository with two directories that look alike will cost you a plan before it costs you anything worse.
What changed
Three role contracts are now Northwind-specific — the Architect, the Code Reviewer and the Security Engineer — and they encode the things a new starter used to learn by breaking something. The engineering lead describes the contracts, not the agents, as the thing they actually bought.
The dispatch system is still the dispatch system. But work on it now arrives as a plan they can argue with, on branches they can throw away, behind a review gate that does not get skipped when the week gets busy.
PLACEHOLDER — illustrative figures for a company that does not exist. Two data points are two data points; a real study would say the same.
The first plan it wrote for us was wrong, and that turned out to be the useful part. We had to write down what we knew about our own codebase before anything else worked — and once it was written down, it stopped being knowledge that could leave.
Engineering Lead, Northwind Freight
Find out what your first plan gets wrong
Connect one repository, file one request, and read the plan. If it misunderstands your codebase, that is worth knowing in an afternoon rather than a quarter. Manual autonomy. Nothing runs without you.
No card required · Free plan forever · Export everything, any time