Before we write any code, every project gets a single page that says what we're building, what we're not, and how we'll know it worked. Here's the template.
The first thing we hand a new client isn’t a design or a prototype. It’s a single page of plain text.
It has no Gantt chart and no forty-row feature list. Just one page that everyone involved can read in five minutes and argue with in ten.
Why one page
Long specs feel thorough, but nobody reads them twice. By week three the real decisions live in chat threads and meeting notes, and the forty-page document quietly stops being true.
One page works for the opposite reason. It’s short enough that people actually keep it open. When something changes, updating it takes two minutes, so it gets updated.
It also forces choices. When there’s only room for five things, you find out quickly which five matter.
What goes on it
Every scope page has the same six headings, in the same order:
- The problem. Two or three sentences, in the customer’s words, not ours.
- Who it’s for. One kind of person. If we list four, we haven’t decided yet.
- The first release. The smallest thing that solves the problem for that person.
- Not this time. The ideas we like but are deliberately leaving out.
- How we’ll know. One or two numbers we expect to move.
- Open questions. Each one has an owner and a date.
That’s the whole template. Here’s a real “first release” line, lightly edited:
Staff can mark an order as ready from their phone, and the customer gets a text within a minute.
It’s one sentence, it can be tested, and anyone on the client’s team can tell whether we delivered it.
The “not this time” list
This is the section clients push back on most, and the one we defend hardest.
Everything on it is a good idea. That’s the point. Bad ideas are easy to drop; it’s the good ones that quietly double a project’s size. Writing them down shows we heard them, and it gives them a place to wait instead of a place to grow.
Most of these items come back later. Some never do, and nobody misses them.
Arguing on paper
The page is a draft until the client has crossed something out. We mean that literally: the first review meeting is a read-through where anyone can strike a line or question a word.
Disagreements are cheap at this stage. Changing a sentence costs nothing. Changing a database schema in week six costs a sprint.
Keeping it alive
Once the build starts, the scope page lives in Logbook, pinned to the top of the project. Every Friday demo starts with it on screen:
- Did this week’s release move us toward “how we’ll know”?
- Did anything move from “not this time” into scope? If so, what came out?
- Which open questions got answered, and which are now late?
If the page and the project drift apart, we fix whichever one is wrong. Usually it’s the page, and that’s fine. A plan that changes in writing beats a plan that changes in someone’s head.
Try it on your next project
You don’t need us to do this. Open a blank document, write the six headings, and give yourself one page. If it doesn’t fit, the project isn’t small enough yet, and that’s worth knowing before anyone writes a line of code.
