How to commission custom software without falling into infinite scope

Infinite scope is not something contractors do to you. It is what happens when nobody in the room defines what the software must not do. A project without explicit boundaries expands to absorb every good idea anyone has along the way, and every one of those ideas is individually reasonable. The result is a build that is permanently three months from done.

The fix is not a tougher negotiator or a thicker contract. It is a different way of scoping: define the project by the operational outcomes it must produce, not by the list of features it should contain. We say this as a team that both builds software and operates its own products in production. Running software after shipping it teaches you fast that a small scope working in a real day beats a large scope that exists only in a document.

Why feature lists create infinite scope

A feature list looks like rigor, but it has a one-way valve built in. Every meeting adds a feature, because adding feels like progress and costs nothing at planning time. Nobody removes one, because removing feels like giving up something already paid for. So the list only grows, and each addition makes the next one easier to justify.

Then the list becomes the spec, and the spec becomes the fight. Every ambiguity, like whether 'reports' included export to Excel, turns into a negotiation about who owes what. The document that was supposed to protect both sides becomes the terrain they fight over. And while that fight runs, nobody is asking the only question that matters: does item 23 change anything about how the business actually operates?

Scope by outcome instead

An operational outcome is a specific moment in the business that must be different once the software exists. For example: a field worker photographs a receipt, and the expense exists in the system, categorized, before they are back in the truck. That one sentence beats three pages of expense-module features, because it names who, doing what, with what result, and it can be verified by watching a real person on a real day instead of by reading a checklist.

This is how Cazullo scopes projects: as a short set of named moments, each one testable in the real operation. Features turn into implementation details, chosen by whoever builds and judged against the moment they serve. Anything that does not serve a named moment is, by definition, out of scope. Not rejected, just not in this project.

The v1 discipline

Once the moments are named, the first version needs one more act of discipline: refusing breadth. We hold this line on our own products for a selfish reason, because we are the ones who have to operate whatever we ship.

• One workflow end to end beats five half-workflows. A receipt that reliably becomes a categorized expense is a product. Five modules at 60 percent is a demo.
• Software that runs a real day earns the right to grow. Once one workflow carries real operations, the next scope conversation is grounded in usage instead of imagination.
• Everything else is a labeled backlog, not a promise. Write the cut ideas down with a name and a reason, so removing them from v1 feels like filing, not losing.

Contract shapes that help

No contract shape eliminates scope drift, so be suspicious of anyone who claims theirs does. Some shapes make honesty easier, though. The main one is phases where each phase ends in something that operates: a deliverable a real person uses in real work. 'Requirements complete' and 'architecture approved' are documentation milestones, not deliverables. A worker submitting a real expense through the system is a deliverable.

The other useful shape is the ability to stop after each phase without wreckage. If the client can walk away after phase one with working software they own, then the builder has to make phase one genuinely useful, and the client has to put what really matters into it. That exit option keeps everyone honest, including us.

Questions that shrink scope

When a scoping conversation starts inflating, these questions deflate it:

• Which spreadsheet dies in v1? If no spreadsheet, group chat, or paper process disappears, the software is an addition rather than a replacement, and adoption will show it.
• Who uses this on day one? Name real people. A feature no named person will touch in the first month belongs in the backlog.
• What breaks if we cut this? If the honest answer is 'nothing yet', cut it.
• How does the operation cope while this is being built? The manual workaround usually reveals which part is actually urgent.
• Which of these features did someone ask for, and which did we imagine someone would want?
• What must be true in ninety days for this phase to be called a success, without anyone running a demo?
• If the budget were cut in half, what would we keep? Whatever survives that question is the real scope.

Start smaller than feels comfortable

Our recommendation is blunt: commission the smallest software that changes one real operational moment, put it in real hands, and let what actually happens write the next scope. A v1 that is small, live, and used will teach you more about what to build next than any planning cycle. Coming from a team that has to operate what it builds, that is not a compromise. It is the fastest route we know to software that matters.