Scoping a First Version: What Decision Will It Produce?

A useful first version has four parts: one complete workflow, one condition that says it worked, a written list of what is deliberately out, and the decision it lets you make next.

The first three are standard advice, and good guidance already exists for them. The fourth is the one that stops you building something tidy that nobody can use.

What is already settled - and who said it

It would be misleading to present the internal-tools angle as ours. A UK custom software firm published a guide on scoping internal software projects that makes the distinction explicitly: you are not building a product for external customers, you are building something your team will use to run the business, and success is replacing a stack of spreadsheets and manual steps rather than validating a hypothesis. That is exactly right, and if you read nothing else you would be in reasonable shape.

They go further. They insist on an explicit “no” list. They define done operationally - you can stop using the spreadsheet. They give a worked example where phase one of a job tracker is six verbs: create, assign, attach, log time, mark complete, view list.

Even the startup-flavoured guides converge on much of this. One MVP checklist we read, aimed squarely at external products, still requires an explicit OUT list, a one-page data model, a ceiling on features, and a done definition that is testable rather than aspirational.

So three of the four parts above are settled practice, not insight. Treat them as the floor.

The three everyone agrees on

Briefly, because they are commodity and you can find them elsewhere.

One complete workflow. Not one screen, not one entity, not one integration - one path from trigger to outcome that the business can operate on. The test is whether someone can do their actual job through it on the Monday after launch.

One acceptance condition. Written before the build, in operational language: we can stop using the spreadsheet, or every job invoiced this month went through the system. If your acceptance condition needs interpretation, it is not one.

Named exclusions. Everything discussed and deliberately left out, written down where the people who asked for it can see it. Exclusions are not rejections. They are the record of what the next conversation is about, which is why they defuse the pressure rather than inflaming it.

The fourth part: what decision does this version produce?

Here is the part we have not found in anyone else’s guidance, and it is the one we care most about.

A first version is an instrument. It is the cheapest way to learn something about your own operation that you cannot currently know - and if you cannot say what that something is, you are not scoping a first version, you are just building less of the eventual thing.

Before the build, finish this sentence: once this is running, we will know whether ____, and then we will decide ____.

Some real shapes that sentence takes:

• “We will know whether the team will actually record jobs at the point of work rather than at the end of the day - and then we will decide whether to build the mobile view or drop it.”
• “We will know whether the quote-to-invoice path removes the re-typing - and then we will decide whether reporting is worth building or whether the spreadsheet was only ever a symptom.”
• “We will know how many jobs hit an exception - and then we will decide whether exception handling is a feature or a process change.”

Notice what each of these does. It makes the first version falsifiable. It names a real fork with two live options, one of which is usually “do less than we planned.” And it turns the exclusions list from a queue of promises into a set of questions that the first version will answer.

A first version with no decision attached tends to grow, because nothing tells you when to stop. A first version with a decision attached has a natural end: it ends when you can answer the question.

One page, not ten

The strongest guide we read recommends producing a specification of five to ten pages, covering user roles, entities, workflows, permissions, integrations, reporting, and out-of-scope items.

For a business with a product function, that is sound. For an owner-operated business it is, in our experience, the single most common reason scoping never happens at all. A ten-page document is a project in itself, it needs someone who writes documents for a living, and the version that gets written under time pressure is worse than the one page that would have been written willingly.

We are disagreeing with them openly rather than pretending they said something else. Their advice fits a reader with more capacity than ours has.

One page, four headings, two or three sentences under each. If the workflow genuinely cannot be described in that space, that is information too - it usually means you are scoping two workflows and should pick one.

The fragment failure

The failure this rule exists to prevent is not scope creep. Scope creep is well covered elsewhere and everyone already fears it. The failure we see more often is the opposite, and nobody warns about it.

A first version can be small, bounded, on time, and inside budget, and still be useless - because it is incomplete rather than small. It implements four of the six steps in a path, so every job still has to be finished by hand somewhere else. It captures the data but has no way to get it out. It works for the normal case and silently drops the exception that happens twice a week.

The symptom is unmistakable once you know it: the team keeps the spreadsheet. Not out of resistance - because they have to. The new system does most of the job, and “most of the job” means the old process survives alongside it, and now there are two.

The test is the acceptance condition, applied honestly. “We can stop using the spreadsheet” is not satisfied by “we mostly use the new thing.” Either the old process is retired or the first version has not landed, and it is much cheaper to discover that in the scoping conversation than in the month after launch.

This is why one complete path beats a slice of several. A narrow path that works end to end retires something. A broad slice that works partway retires nothing.

The rule, and what each part prevents

Part	What it is	What goes wrong without it
One complete workflow	A single path from trigger to outcome the business can operate on	You get a slice of several paths; nothing is retired and the old process survives alongside the new one
One acceptance condition	An operational sentence, written before the build, that says it worked	”Done” is decided by whoever is most tired, and the launch is a matter of opinion
Named exclusions	Everything deliberately left out, written where the askers can see it	The list lives in people’s heads as promises, and every conversation reopens the scope
The decision it produces	What you will know afterwards, and what you will decide with it	Nothing tells you when to stop, so the first version grows until the budget ends it

What this rule cannot do

Three limitations worth stating.

It does not price anything. Knowing the shape of a first version tells you what to ask for, not what it should cost, and a confident single number against a one-page scope deserves the same suspicion as one against a thin brief.

It does not resolve disagreement about which workflow comes first. That is a business judgement about where the pain is, and no scoping rule substitutes for making it.

And it assumes you have decided to build. If that decision is still open, this is the wrong page - the question of whether the problem is software at all comes first, and it is a different piece of work.

What to do this week

Write the sentence: once this is running, we will know whether ____, and then we will decide ____. If you cannot finish it, you are not ready to scope, and that is a useful thing to discover on a Tuesday rather than three months in.

Then pick the single workflow that sentence depends on and walk it end to end with the person who does it, listing every step that would still have to happen by hand after launch. Anything on that list either comes into scope or goes onto the exclusions list by name. Nothing stays undecided.

That is the whole exercise, and it fits on one page.

FAQ

Everyone wants their bit in version one - how do I say no? You do not say no, you say “not first, and here is when we will decide.” Put every request on the exclusions list by name, attached to the decision the first version will produce. People accept a queue with a stated review point far more readily than a refusal.

What if the first version is not worth using on its own? Then it is not a first version, it is a fragment, and you should either widen it until one complete path works or pick a smaller path that does. A first version nobody can run on retires nothing.

How long should a first version take? We deliberately do not give a number - it depends entirely on the path you chose, and any guide quoting a fixed timebox is quoting its own commercial model rather than your project.

Do we need a written spec? One page, yes. Ten pages, almost certainly not for a business this size - the long version tends not to get written at all, which is worse than a short one that does.

Notes

• Live result set retrieved 2026-08-24 (en, GB proxy) via requests req_8ae3c4557396 and req_e72c16cf75a0, both at zero budget. Two pages opened and read in full; a third internal-tools guide returned HTTP 403 and was not read, so nothing here draws on it. See research/live-result-set.md.
• The internal-versus-startup distinction, the complete-workflow rule, the operational acceptance condition and the exclusions list are established practice, published by others including a UK firm serving the same readers. This page credits them rather than claiming them.
• What we have not found elsewhere, and what this page is for: naming the decision the first version produces, arguing for one page over ten, and the fragment failure mode. These are Garaxe’s framing, described as we use them. No client outcome or success rate is claimed, and the example sentences are illustrative rather than drawn from named client work.
• One opened source publishes fixed price tiers. They are that studio’s commercial offer and are deliberately not reproduced here as market rates.
• No AI-assistant answer baseline was collected - the probe was unavailable on 2026-08-24 - so nothing here is a claim about what an assistant answers.
• Autocomplete returned no suggestions and no People-Also-Ask questions were returned, so this page makes no claim about what owners search for.