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.

Read this first These three companies are invented, and so is every number below. We built the page before we had customers willing to be named, and we would rather publish an obvious placeholder than a flattering fiction you might mistake for evidence. When real studies replace these, they will keep the same structure — including the section about what went wrong — and each figure will still say how it was measured.

Case 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.

9 → 2 days, median request to production Median across 38 requests in the 11 weeks after adoption, versus 34 comparable changes in the 11 weeks before. Measured from request creation to the merge commit reaching the deployment target. Their own git history supplied the 'before'.
1 automatic rollback One health-check failure in 63 deployment runs over the same period. The rollback restored the previous healthy commit; the investigation that opened produced the follow-up request.
11 weeks, Manual to Autonomous On the storefront project only. The admin back end went back to Supervised in week seven and stayed there.
0 changes merged without review A product fact rather than an achievement: the Code Reviewer gate was on from day one and cannot be bypassed while it is on.

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.

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.
46 plans read and decided Counted from the approval log over one quarter: 35 approved as written, 9 edited before approval, 2 rejected outright.
2 plans rejected outright Both in the first five weeks, both traceable to a request written as a single ambiguous sentence. None after week five.
1 change that solved the wrong problem Merged, reviewed, working, and not what was wanted. Counted here because leaving it out would make the quarter look tidier than it was.
Manual autonomy, all quarter No project moved past Manual. Nothing dispatched without an explicit approval, by choice.

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.

3 security findings, first 30 days Raised by the Security Engineer across the requests it reviewed. One duplicated CSRF check, one missing authorisation condition, one card number in application logs. Each opened a follow-up request.
1 plan rejected for targeting dead code The repository holds a deprecated module alongside the live one. Fixed by editing the project's Architect contract; no later plan repeated it.
40 → 4 minutes to an investigation summary First investigation stalled on a diagnostics command requiring elevation it did not have. After the command was rewritten, the next investigation summarised in four minutes. Two data points, not a trend.
3 role contracts rewritten Architect, Code Reviewer and Security Engineer, edited by the team as Markdown files in their own project.

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.

Sofia Lindqvist
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