How we build with AI

The failure mode of building with AI isn't bad code. It's building the wrong thing quickly, then spending three days unpicking it.

Almost everything we ship starts as a written specification — the sections of a page in order, the exact copy, the data model with column names, the states a form can be in. Writing that takes twenty minutes and removes most of the iteration that would otherwise happen in a chat window. The model is very good at execution and indifferent to whether the thing is worth executing. That judgment stays with us.

Every project carries a written set of rules: the colour tokens, the type roles, the spacing scale, the things that are never allowed. It lives with the project rather than in a conversation, so it applies to work done six weeks from now by someone who wasn't there for the original decision.

This is the difference between a codebase that drifts and one that doesn't. Taste doesn't survive in chat history. It survives when it's written down where the next edit will read it.

The reason one team can run this many products is that they are not really separate products. Identity, messaging, scheduling and payments are solved once and pointed at a new market. What changes per deployment is the vocabulary, the compliance constraints and the defaults — not the machinery.

The consequence is that the fifth product is faster than the second, and a fix in one deployment tends to improve the others.

We operate directories, service businesses and marketplaces of our own. Every product gets pointed at one of them before anyone else sees it.

This is a slower way to launch and a much faster way to find out the truth. You learn in a week what a demo would never tell you: that the message arriving four minutes later matters more than the copy, that nobody reads the dashboard, that the feature you argued about for a day gets used twice.

Deciding what to build. Deciding what to stop building. Anything where being confidently wrong is expensive — pricing, compliance, a schema that other things will depend on, an irreversible migration. Those get read line by line by a person before they ship.

The rule we use: if being wrong is cheap and reversible, move fast. If it isn't, slow down and read everything.

Not fewer people. Fewer weeks between deciding something and finding out whether it was right. That compounds in a way that headcount doesn't.