The 60-page spec problem.
Every traditional consulting engagement starts with a discovery phase that produces a long document. The document looks impressive, costs a quarter of the engagement budget, and goes unread for the rest of the project. By the time the team is shipping, the document is wrong in at least three important places — but nobody updates it because the team is busy shipping.
The cost of the spec was not the writing. It was the false confidence everybody borrowed against while it was being written.
Demo-driven planning.
We replace the long spec with a two-week demo cycle. Every two weeks, we put working software in front of the client. Not screenshots, not Figma, not a Loom video — software you can click. At the end of each demo we agree, on the spot, what the next two weeks will produce.
This forces three healthy behaviours. We can't punt hard decisions to a future document — the calendar makes us decide. The client gets to react to something concrete instead of approving abstract bullets. And the team gets to course-correct early and often, when the cost of changing direction is small.
What we still put in writing.
Demos do not replace writing entirely. There are three things we always write down.
Decisions. Every meaningful trade-off — "we chose row-level security over a per-tenant database" — gets a one-paragraph entry in a decision log. Future-us reads it more often than we expect.
Contracts. Anything that crosses a system boundary (an API, a webhook, a CSV import, a data model another team depends on) gets a written contract. These are short and precise. They are also versioned.
The next two weeks. A bullet list. Never longer than one page. Signed off by the client at the end of every demo.
That's it. Nothing else gets written into the long-form documents the project would have produced with a traditional spec — because nothing else changes slowly enough for documents to be worth maintaining.
What we put on screen.
The demo is the deliverable. We host the build on a staging URL the client can poke at any time, not just during the demo call. We seed it with real-looking data — sometimes anonymised production data, sometimes generated. We don't pre-bake demo flows; the client can wander wherever they want.
After six years of running this way, we have one strong belief: the projects that ship well are the ones where the client sees the software early, often, and with the rough edges left in. Polish too soon and you can't have the right conversations.