How to Scope Custom Software Before You Write a Spec

A spec prices the known and guesses the unknown

A written specification is good at describing screens, roles and fields. It is silent on the things that actually decide the timeline: whether the integration is stable, whether the data reconciles, whether the performance target is reachable. So the estimate ends up precise about the cheap work and vague about the expensive work.

That is why pre-build estimates feel like they should be trustworthy and then move. The variance was never in the parts anyone wrote down.

Scope the unknowns first

Start by naming the two or three things you are least sure will work — the hardest integration, the trickiest data model, the performance-critical path. These carry most of the project’s risk and almost none of its documentation.

Then reduce the project to a sequence: prove the unknown, build the core flow, add the edges. Scope is not a list of features; it is an order of questions.

Write the smallest thing that proves the flow

• Pick one end-to-end job the system must do — not the whole product.
• Identify what that job depends on that you have not yet proven.
• Prototype the dependency, then build the job so a real user can run it.
• Decide the next step with evidence rather than a change request.

Make ownership and exit explicit up front

Two scoping questions decide more than any feature list: who owns the code, and how either side can stop. Custom software should mean you own the source outright, and the engagement should have natural checkpoints — after the prototype, after the core flow — where both sides can change course without a rewrite.

Spelling this out early is what separates a partner from a supplier, and it is the same principle behind how we run custom software development.

Sequence delivery in vertical slices

A vertical slice is a thin cut through the whole stack that delivers one complete, usable capability — as opposed to a horizontal layer that shows nothing a user can touch until the very end. Slices make progress visible, testing continuous, and every stage shippable.

They also keep scope honest: if a slice cannot be made shippable, the thing you are trying to build is not understood yet.

What a good scope looks like

Not a 60-page document. A short statement of the problem, the one job to prove first, the riskiest dependencies, the sequence of slices, and the decision points. Enough to start, small enough to stay true as you learn.

The measure of a scope is not how much it describes — it is how much it de-risks. A prototype is the cheapest way to buy that certainty before you commit.