Eighteen months, three systems in production: an exchange for Connected TV inventory, an exchange carrying two-sided billing, and a platform for creators. One person. I want to be precise about what that does and does not demonstrate, because the honest version is more useful than the impressive one.
What genuinely got faster
- Anything I had written before. Scaffolding, wiring, the fourth CRUD surface in a product that already has three — work that is entirely determined by what exists around it.
- Unfamiliar interfaces. Reading a specification and producing a first working call against it used to be an afternoon; it is now minutes, and the minutes are spent checking rather than typing.
- Exploring a codebase I have not touched in months. Asking where something is handled beats grepping for it, by a distance.
- Tests for code whose behaviour I can already describe. Not deciding what to test — writing the cases once I know.
Taken together that is a real multiple. It is also almost entirely the easy half of the work.
What got no faster at all
- Deciding what to build. Still the hardest thing, still entirely on me, and getting it wrong is still the most expensive mistake available.
- The month between a working demo and something dependable. Tenancy, money that reconciles, evaluations, the answer for three in the morning — none of it compressed.
- Debugging anything distributed. When the cause is an interaction between a deploy script, an empty environment variable and a filter that cannot distinguish absent from false, no amount of generation helps. You have to hold the whole thing in your head.
- Knowing which three of the remaining twenty problems matter. That is judgement, it comes from having been wrong before, and it does not transfer.
The failure mode nobody advertises
Generated work reports success by default. I had an in-page assistant delivered as four completed phases; it contained six independent defects and had never once rendered. On another system, a local model fabricated a statistic in both of two prose generations, once with a plausible source attached.
Neither of those is an argument against the tooling. They are an argument about where the time goes. The work did not disappear — it moved from writing to verifying, and verification is harder to timebox because you cannot know in advance which part is wrong.
The actual bottleneck
Review does not parallelise. I can have four things generated at once and I can still only read one at a time, carefully, which is the only way reading is worth anything.
This is why the thing that moved my output most was not a better model. It was writing my own review procedures down — about thirty of them — so that checking a system follows a route instead of depending on what I happen to remember that day. The leverage was in making my own judgement repeatable, not in outsourcing it.
The honest limit
Building capacity and demand are different problems, and the tooling only touches one of them. Eighteen months of it will give you systems that work. It will not tell you whether anyone wanted them, and it is very good at helping you avoid finding out.
That is the part I would want to hear from somebody in my position, so it is the part I will say.
Written by Manmohan Singh, who builds the systems that move the money. About.
The build log, by mail
New notes, when I publish them.
One mail per note: what broke, the theory I held before I understood it, and the rule I kept afterwards. Irregular on purpose — I write these when something happens, not to a schedule, and I would rather send you nothing than send you filler.
Also in the log
Thirty per cent of our volume stopped earning money
Yield was falling and every instinct in the room said send more. We sent less of what paid, and yield rose about eighty per cent.
The ad you cannot change after you send it
An image URL inside a delivered email is immutable, and Google caches it. Both facts are fixed. The ad still had to change on every open.