The thing that stopped your last build from closing wasn’t the bugs. It was the ideas. Every call produced three. Each one was good. Each one, with nowhere to go, quietly reopened the phase everyone was trying to finish.
On a client build I gave them somewhere to go. One page, published alongside the acceptance checklist: everything raised in scoping and on the calls that isn’t in the fixed-hour build, placed in a suggested order. Fourteen items, four waves. It’s the page that let the phase end.
The header does most of the work
“Everything raised in scoping and on the calls that is not in the build, put in a suggested order.” That one line tells the client their idea was heard, recorded, and placed. It also tells them, without a meeting, that it’s not in this phase.
Then the ordering rules, written out before the list so the order can be argued rather than guessed:
- Finish what is already half built first.
- Learn from real use before changing how the core flow works.
- Build on stored data before adding new systems.
- Leave the speculative items last.
The rules are the point. With them on the page, a disagreement becomes “should rule two apply here?” instead of a negotiation over a list. I’m not defending my taste. We’re both reading the same four lines.
Waves, not a backlog
Each wave is a theme with one line of why. On that build: tidy up and use what’s there. Refine the core flow after real use. Extend downstream, from an accepted quote to a paid job. AI and visual extras.
Each item under a wave gets a plain explainer of what the user would get, a rough size label such as small or small to medium, where it was raised (scoping, or a dated call), and a “why here” line that ties it to one of the rules. The explainer matters more than it looks. The client raised the idea in their words, and seeing it explained back in plain language is most of what they wanted.
A “not scheduled” box at the bottom holds the revisit-if-needed items and the ones explicitly ruled out, with the date they were ruled out. That stops them coming back as new ideas in three months.
The last line is the commercial one
Every item on the page is a change request. Scope and hours are agreed before any work starts. That sentence, in writing, before handover, is what separates the phase that’s ending from the work that might follow. It’s the same rule as what counts as a bug: a failed line on the acceptance checklist is a bug and gets fixed inside the phase. A preference, however good, is a change request and lives here.
The page is also a pipeline. Wave one is the natural next engagement, already scoped in outline, already ordered, already agreed to be a change request. Nobody has to sell it.
If you’re the client
Ask for this page before the build closes, whether a contractor built it or your own staff did. If the person building for you can’t show you where the “could it also” ideas went, they went into the phase, and the phase isn’t ending. If they can, you’ve got a plan for what comes next that you can read, argue with rule by rule, and fund one wave at a time. The build is the cheap part. The page is how you keep the rest of the cost in view.