Scope first, code second

The most expensive conversation in software is the one you have three weeks into a build when someone says "I thought we were also doing X." By then you've written code that assumes X doesn't exist. Undoing that assumption costs time, morale, and money — usually in that order.

What actually goes in the document

Before we write a line of code for any project, we produce a scope document. Not a proposal. A proposal is designed to win business. A scope document is designed to prevent arguments. It contains four things:

• What we're building and what we are explicitly not building
• The technology stack and why we chose it for this specific project
• A timeline with milestones, not just a delivery date
• The exact cost, with no ranges or "to be confirmed" line items

Why clients push back on it

The most common objection is "can't we just start and figure it out as we go?" The honest answer is yes. Some projects are genuinely exploratory and benefit from flexibility. But most projects are not exploratory. Most have a known goal, a known budget, and a known deadline. For those projects, starting without a document isn't agility. It's avoidance.

What clients are usually really saying is "I don't want to make hard decisions yet." The scope document forces those decisions to happen before they're expensive instead of after. That's uncomfortable. It's also the entire point.

What it does to the working relationship

Once both parties have agreed on a scope document, something shifts. The question stops being "are we building the right thing?" and becomes "how do we build the thing we agreed on?" That's a much cheaper question to answer.

It also changes how surprises get handled. When something unexpected comes up mid-build — and something always does — the document gives both sides a reference point. Either it's in scope and we solve it together, or it isn't and we discuss adding it. Neither conversation is a fight because neither side is arguing from memory.

"A scope document isn't a legal contract. It's a shared understanding written down so neither party has to rely on memory six weeks later."

The one thing the document can't prevent

The document handles scope. It doesn't handle taste. Clients can approve a scope document and still be surprised by what something looks and feels like when it's built. That's a design problem, not a scope problem, and it's solved earlier in the process through wireframes and prototypes — not later through contract language.

The scope document is the floor. Design references, prototypes, and regular demos are what build the walls. All of it together is what gets you a project that ships on time, on budget, and without anyone feeling like they were misled.