The #1 reason software projects fail isn't bad engineers or bad clients. It's bad scope. Vague briefs become moving targets, moving targets become endless revisions, and endless revisions kill trust. We've watched this play out enough times to build a fixed pre-code process — six documents, two weeks, one meeting per document. Here it is.
Why we don't just "start building"
Agile is great once you're building. It's terrible for the pre-build phase because it assumes you know what problem you're solving. If a client says "I want an app to help contractors track jobs" — that could mean five different products with five different price tags. Scope work upfront turns ambiguity into a written commitment both sides can point to.
Our rule: no code until the six documents are signed off. Even for small builds, this takes 1–2 weeks. Every week spent scoping saves 3–5 weeks of rework later.
Document 1: Vision brief (1 page)
Written by the client, edited by us. Answers three questions:
- Who is this for? Specific persona, not "small businesses"
- What outcome does it produce? "Save 4 hours a week on manual data entry" not "streamline operations"
- Why now? The trigger event — a compliance deadline, a competitive threat, a new customer segment
If the client can't fill this in, the project isn't ready. We stop here.
Document 2: User stories (2–5 pages)
Written in the format: "As a [role], I want [action], so that [outcome]." Group by user type. Aim for 15–30 stories for a typical app. Each story becomes a testable feature.
Example:
- As a project manager, I want to see all overdue tasks on one dashboard, so that I can reprioritise the week's work in under 5 minutes.
- As a contractor, I want to log time from my phone, so that I don't have to remember jobs at end-of-week.
These stories become the sprint backlog once we're building. If a story shows up mid-build that wasn't here, it's a change request — priced separately.
Document 3: Sitemap or app map
For websites: every page and its parent. For apps: every screen and how the user navigates between them. Draw it as a tree or flow diagram.
This forces two things:
- A count of pages/screens — which drives cost estimates directly
- A discussion of navigation — often surfaces "how does this feature even work?" questions before design
Document 4: Wireframes (low-fidelity)
Not design. Not colours or fonts. Just boxes and labels showing what content sits on each screen. Figma is fine; a whiteboard photo is fine.
Wireframes catch the "oh, we also need X" moments before they're expensive. A single button we forgot at wireframe stage costs 5 minutes. The same button discovered post-launch costs $3,000.
Document 5: Feature list with priorities
Every user story gets tagged MoSCoW:
- Must — launch blocker
- Should — important but launch can proceed without it
- Could — nice to have if time permits
- Won't — explicitly out of scope for this phase (huge value in writing this down)
The "Won't" list is the most valuable — it's the receipt for future scope creep conversations.
Document 6: Risk register (1 page)
Top 5–10 risks, each with likelihood, impact, and mitigation. Common risks we see:
- Third-party integration doesn't work as documented
- Content isn't ready when the site is ready
- Client stakeholders disagree on a critical UX decision
- Regulatory or compliance requirement discovered late
- Client's internal IT blocks the tech choice we made
Written down, these become shared problems to solve early. Undocumented, they blow up mid-build.
What happens after the six docs
We produce:
- A fixed-price, fixed-timeline proposal — because we have enough detail to price it accurately
- A Statement of Work referencing all six documents
- A change-request process for anything discovered later
Then we build. Weekly demos, live staging, and the "Won't" list on the wall. Scope creep still happens — but it's now visible, costed, and negotiated, not a source of resentment.
The counter-argument
"But this is heavy — we want to move fast." Yes. We hear this often. Our answer: you don't move fast by skipping scoping. You move fast by scoping fast and completely. Two focused weeks up front pays back four to six weeks in the build phase.
If your project genuinely can't handle two weeks of scoping, it probably needs to be smaller. Split it into a phase 1 that can be scoped in a week and shipped in six.
Found this useful? Two new posts a month — back to all insights.