How to Scope the First Release of Custom Software

The biggest risk in custom software is building too much before anyone uses it. Requirements gathered up front are guesses; real use replaces them with evidence. A small, useful first release gets you that evidence sooner and for less money.

What "first release" should mean

A first release is not a prototype or a demo. It is a version real people use for real work, with a narrow scope. It should:

• Solve one clear problem from start to finish.
• Be used by a defined group of people.
• Replace something, such as a spreadsheet, an inbox or a manual step.
• Be safe to run with real data.

A simple scoping method

1. Name the job. One sentence: "Dispatchers can see and assign every booked load without the spreadsheet." If you cannot write the sentence, the scope is not clear yet.

2. List the users and their main task. Usually two to four roles. Write the one thing each must be able to do.

3. Walk the path end to end. From the moment work arrives to the moment it is finished. Every step on that path is in scope. Everything off the path waits.

4. Mark the data. Which records the release creates, reads or changes, and where each one lives today.

5. Sort the wish list. Put every other idea into one of three groups:

Be strict. Most items belong in "Next".

What to defer on purpose

These are commonly pulled into first releases and commonly regretted:

• Complex reporting. Start with a few key numbers; build dashboards once data has accumulated.
• Every edge case. Handle the common path well and let rare cases fall back to a person.
• Deep customisation and settings. Hard-code sensible defaults until you know what people change.
• Mobile apps. A responsive web app usually covers early needs.
• Integrations with every tool. Connect the one or two that remove the most re-keying.

Signs the scope is still too big

• The release needs more than one major integration to be useful.
• There are more than four user roles.
• Nobody can explain what the first week of use looks like.
• The estimate is long enough that priorities might change before launch.

If any of these are true, split the release.

After launch

Plan time for changes. The first weeks of real use always reveal something the plan missed. Budget for a short improvement cycle right after launch rather than treating launch as the finish line.

Scoping is the first part of how we approach custom software projects. If you are not sure whether to build at all, start with custom software vs off-the-shelf.