Almost every unhappy software project we have been asked to rescue failed in the same place, and it was not the code. It was that nobody wrote down what was being built. Two people left a meeting with different pictures in their heads, work began, and the gap only became visible weeks later when there was something on a screen to disagree about. By then the disagreement is expensive.
So we start every engagement with a written specification. Not a proposal full of adjectives, but an actual document listing the screens, the rules, the things the system will do and, just as importantly, the things it will not do in this phase. It states what you are getting, what it costs and when it lands. You read it, you argue with it, and you approve it before anyone opens an editor.
This is unglamorous and it slows the start down by a few days. It is still the single highest-value thing we do. A written scope converts a vague expectation into a testable claim. When the build is done there is no debate about whether it is finished: either the system does what the document says or it does not.
It also protects you from us. A scope makes it obvious when we have missed something, and it makes a change request a conversation rather than an accusation. Requirements change, which is normal, and we would rather hear about it in week three than discover it at handover. What the document does is make the change visible: this is new, here is what it costs, here is what it moves. That is a decision you get to make with real numbers instead of a surprise you absorb later.
The other thing a written scope does is force the hard questions early. What happens when two people edit the same record? What should the system do when a payment half-succeeds? Who is allowed to delete this? These questions have to be answered eventually. Answering them on paper costs an afternoon. Answering them after the fact costs a rewrite, and usually a live incident first.
We are not precious about the format. A scope can be a few pages for a landing site or a few dozen for a platform with real permissions behind it. What matters is that it exists, that both sides have read it, and that it is specific enough to be wrong. A document nobody can disagree with is not a specification, it is marketing.
If you are talking to any development team and they want to start building before anything is written down, that is worth pausing on. Ask what happens when the two of you remember the conversation differently. The answer to that question is the whole reason we work this way.
