Why we agree scope in writing before writing code

Ask anyone who has commissioned software and been burned by it, and the story is rarely about bad engineers. It is about a gap: what the owner asked for and what the team understood were two different things, and nobody noticed until money had been spent building the wrong thing.

That gap is why we put the survey before everything else. Before any code is written, we take the problem or the idea — a manual process that has been costing you for years, an opportunity nobody else has moved on — and work out what is genuinely possible. Then we put the scope in writing: what is being built, what each stage delivers, and what it will take to get there. Both sides agree to it before anything is made.

This is the least glamorous part of the process. There is no demo to admire and no interface to click. But it is the only part that reliably decides whether everything after it works, because a scope agreed in writing cannot quietly drift. When the software arrives, it can be checked against something that exists — not against a memory of a conversation.

It also changes the economics of the engagement. An open-ended project rewards whoever bills the most hours. A scoped stage rewards finishing. We do not publish prices, deliberately — a price without a boundary is a guess, and a guess is what gets renegotiated later. The boundary comes first; the number arrives attached to it.

If you are weighing up a software project of your own, the one-sentence version of this whole article is: do not let anyone start building until both of you can point at the same written description of what done looks like.