Walk yourself through scoping a project.

What makes a spec worth writing

A spec isn't a contract and it isn't a wish list. Its job is to make disagreement visible early, while changing your mind is still cheap. The four things below do most of that work.

Describe the problem, not the solution

“We need a chatbot” forecloses the options. “Our support team answers the same forty questions all day and works weekends” leaves room for the answer to be a better help centre, which is occasionally the honest one and always the cheaper one.

Say what you'd accept as proof it worked

Write the success measure before the build, because it is remarkably easy to define afterwards in whatever way the result happens to satisfy. If nobody can state the measure, that is itself the finding.

Name the systems the answer depends on

List where the data actually lives and who controls access. This is the single most common cause of a schedule slipping — not the model, but three weeks of waiting on a credential from a team that was never told the project existed.

Mark what the system must never do alone

Refunds, sending on your behalf, changing records, anything irreversible. Writing this down early makes the approval design part of the build rather than a retrofit, and it's the first thing a security reviewer will ask about.

The output is yours to use anywhere — send it to us, or take it to another firm. A spec that only works with one vendor isn't a spec.