Speed is cheap, discipline isn't

## Welcome to "Build your own tools", a series on the tools we build for ourselves. 

Every so often we hit an internal problem that the market solves badly, costly, or not quite the way we work. Building our own used to be too expensive to justify. AI changed that. When used right.

In two weeks, we built an internal meetings platform that should have taken months. It records, transcribes and summarises every meeting, makes the whole archive searchable, and exposes all of it to our agents. So they can pull a decision out of a call from six weeks ago without anyone digging for it. Two weeks, start to working product.

I want to be clear about why that was possible, and clear about what it didn't solve. Because the platform itself is not the interesting part. It's the reminder that there is a lot more to product development than meets the eye.

Speed is a trap if you let it be

Agentic tooling collapses the cost of the first version. The demo that used to take a sprint now takes an afternoon. That is genuinely new, and it is useful. The danger is what it does to your judgement. When building costs almost nothing, the temptation is to ship the demo and call it a platform.

But a thing that works once on the happy path is not a thing you can run for years. The first version was never the hard part. Everything that keeps it alive afterwards is, and none of that comes for free with the tooling.

Where the real work went

Almost none of the two weeks was the part you would put in a demo. The work that mattered was the work nobody asks to see.

Standardised. I wanted the next service we build to look like the last one, not a fresh set of surprises. That means shared conventions for how a service is structured, configured, deployed and observed, so the team carries one mental model instead of one per project. The tooling will happily generate four services in four different shapes. Resisting that is a choice you have to make on purpose.

Observable. A platform you cannot see into is a platform you find out about from your users. We wired in logging, traces and the signals that tell us when something is degrading before someone reports it. This is unglamorous, and it is the difference between operating a system and being surprised by one.

Retrievable. Storing the data is the easy half. Making it genuinely useful, indexed, chunked and reachable by the agents that need it, is the half that pays off. Data that is merely stored is a cost. Data that is retrievable is a capability.

Self-healing. Some failures should recover on their own, with retries, backoff and idempotent steps, so a transient blip never becomes an IT support desk ticket. The system absorbs the small stuff without a human in the loop.

Maintainable. Independently of all that, the code has to be clean to change long after the week it was written, with clear boundaries and no clever shortcuts that only the author understands. A perfectly self-healing service still has to be readable and safe to evolve. Recovery and maintainability are different problems, and a system needs both.

The tooling gets you to the starting line

That is the real framing. The tooling gets you to the starting line faster than anything I have used before. It does not run the race for you. The race is operability, and operability is still earned the slow way, through decisions about structure, visibility, data and failure that no model makes on your behalf.

Here is what I am taking from these two weeks. When building gets cheap, the demo stops being a signal of anything. Anyone can produce one now. The discipline of building well is the only thing left that separates a demo from a platform. If you already build with that discipline, the speed is a gift. If you don't, it is just a faster way to ship something you cannot keep alive.