This guide is for the person inside a business who has been asked to “build something internal” and now has to turn a vague brief into a project that can actually be quoted, built, and used. By the end you will know how to pin down what the tool needs to do, what it does not, what to defer to a later phase, and how to write that down in a way developers can estimate without guessing.
Who This Guide Is For
Operations leads, founders, and product owners commissioning a custom internal tool — anything from a job tracker to an onboarding workflow to a reporting layer that pulls data from three other systems. You are not building a product for external customers; you are building something your team will use to run the business. The scoping rules are different from a SaaS launch because the audience is captive, the success measure is operational, and the people complaining about it sit in your office.
Before You Start
You should already have decided that custom is the right route rather than configuring an existing tool. If you are still on the fence, How to Evaluate Build vs Buy covers that decision. You should also have a rough budget envelope in mind — not a number you are ready to commit, but a band (“twenty grand”, “six figures”) that tells you whether you are scoping a phase one or a full system.
The other prerequisite is access to the people who will actually use the tool. Scoping without users in the room produces a feature list that matches the commissioner’s mental model, not the workflow that breaks every Tuesday afternoon.
Step 1: Write Down the Process, Not the Software
Start with the workflow the tool exists to support, before any feature decisions. For each major task, document the steps a person takes today, in order, including where the data lives, who they hand off to, and where things go wrong. Do this for the three or four most common scenarios — not every edge case.
A useful output looks like: “When a new client signs the contract, Sarah pastes the details into the master spreadsheet, emails the welcome pack manually, creates a folder in Drive, and adds them to the project management board. This takes twenty minutes per client and we onboard fifteen a month.” That paragraph contains more useful scope information than a feature list ever will, because it tells you what the tool is replacing and what success looks like.
If you skip this step, the developers will have to reverse-engineer the process from the feature list, and they will guess wrong on at least one critical detail.
Step 2: Separate Workflow Logic From Reporting
Almost every internal tool has two layers: the workflow that captures and moves data, and the reporting that lets managers see what is happening. These should be scoped separately because they have different builders, different costs, and different priorities.
The workflow layer is non-negotiable for phase one — without it, nobody can use the tool. Reporting is often deferrable. A dashboard that surfaces “open jobs by status by owner” is useful, but it is not the thing that gets you out of the spreadsheet. If you scope reporting in too early, you spend three weeks building charts before the team has used the tool for a single day.
A clean phase split for most internal tools: phase one ships the data capture, workflow, and basic list views. Phase two adds reporting, exports, and the dashboard. Phase three layers in the integrations and automations. Try to push reporting and integrations into phase two unless the business case depends on them from day one.
Step 3: Define the Hard “No” List
A scope document with only a “yes” list invites scope creep, because anything not on the list defaults to “we’ll figure it out”. The strongest scope documents include an explicit “out of scope” list — things people will ask for that the project will not deliver in this phase.
Concrete examples of a strong out-of-scope statement: “Mobile-first design — the tool will be usable on a phone but is designed for desktop.” “Two-way sync with Xero — invoices export one direction only.” “Custom roles per user — there are three roles, fixed.” Writing these down before the build starts saves arguments later, because the question “why doesn’t it do X?” has a documented answer.
A weak scope statement says “the tool will support invoicing”. A strong one says “the tool will generate a PDF invoice from a job record and email it to the client; it will not record payments, chase overdue invoices, or sync to accounting software.” The strong version is twice as long and removes ten future arguments.
Step 4: Decide What “Done” Looks Like for Phase One
Before writing the spec, define the minimum behaviour that lets you turn off the current process. Not “the tool is finished” — that never happens — but “we can stop using the spreadsheet.” This is your phase one acceptance criteria.
For a job tracking tool, “done” might be: a team member can create a job, assign it, attach files, log time against it, mark it complete, and see a list of their open jobs. That is six verbs. Everything else — reporting, notifications, client visibility, integrations — is phase two unless the business case proves otherwise.
The benefit of defining “done” this way is that the developers can estimate against a concrete target instead of a feature wishlist. A six-verb scope is quotable in a day. A 47-feature wishlist takes a week to estimate and the number will be wrong because half the features turn out to be ambiguous.
Step 5: Write the Spec in Terms of Users and Outcomes
Once you have the workflow, the phase split, the out-of-scope list, and the “done” definition, the spec writes itself. The structure that works:
- User roles: who uses the tool and what each role can do
- Core entities: the main things the system tracks (jobs, clients, invoices, requests)
- Workflows: for each user role, the sequence of actions they take
- Permissions and visibility: who sees what
- Integrations: which other systems the tool talks to, in which direction
- Reporting and exports: what data leaves the system, in what format
- Out of scope: the explicit “no” list from step 3
This format is enough for a developer to produce a meaningful estimate and start architectural work. It is short enough to fit in a single document and complete enough that nobody starts coding before the gaps are closed.
Step 6: Get the Spec Reviewed by Someone Technical Before You Send It Out
Even if you are commissioning the build from an external partner, have a technical person read the spec before it goes out for quotes. They will spot ambiguities you cannot — places where two reasonable interpretations exist, or where a casual requirement implies a week of work the budget will not cover.
A common example: a spec that says “the system should send the client an email when their job is complete” sounds simple. A technical reader will ask: which email address? sent from where? what if it bounces? what template? logged where? Those questions add up to two days of work that nobody priced in. Catching this before quotes go out prevents change requests and bad-faith disputes later.
If you do not have an in-house technical person, pay for an hour of consulting from someone outside the build team. It is the cheapest insurance you can buy on a software project.
Common Mistakes
- Scoping the dream system instead of phase one. The dream system has 47 features and takes nine months. Phase one has six and ships in eight weeks. Scope phase one.
- Writing the spec without the users. Specs written from the commissioner’s perspective always miss the awkward parts of the workflow — the bit where someone has to manually rename files, or the exception that happens twice a month and nobody talks about.
- Treating integrations as an afterthought. “And of course it integrates with our accounting system” is a sentence that can add £15,000 to a quote. Integrations are scope items, not assumptions.
- No out-of-scope list. Without it, every conversation about a missing feature becomes a negotiation. With it, the negotiation happened once, in writing, before the build started.
- Confusing scope with detail. Scope is the list of what exists; detail is how each thing works. A scope can be a few pages. Detail is twenty. Do not try to do both at once — get scope agreed, then move into detail with the build partner.
What Good Looks Like
A well-scoped internal software project has a single document — five to ten pages — that lists user roles, core entities, workflows, permissions, integrations, reporting, and an explicit out-of-scope list. Every reader of that document, technical or not, can describe what the phase one tool will and will not do. The development partner can give a confident estimate without needing three rounds of clarification, and the team that will use the tool recognises their own workflow in the spec. When the build starts, change requests are rare because the hard decisions were made in scoping, not in development.
Next Steps
If the project involves replacing existing internal systems and you need to think about the data side, How to Plan a Data Migration covers the migration scope. If you are about to take the spec to market, How to Write a Software RFP covers the procurement document. For help shaping the spec itself, get in touch.