What Should the First Version of Your Business Software Include?

For the first version, choose a piece of work that somebody can finish. Then include what lets them finish it when a detail is wrong, a colleague is away or the system needs help.

Picture it on a Monday morning: a member of staff opens the software, does a useful job and leaves a result the next person can trust.

Choose where the work starts and ends

Imagine a fictional maintenance company building a work-order system. Its first users will be the office coordinator and one maintenance team. The coordinator records a job, assigns it, and the team records what was done. The coordinator checks the result and closes the job.

That could be a useful first release. “A work-order screen” tells us much less. Can the team see the assignment? Can somebody correct it? What does a closed job mean?

Define the people and the result before deciding how many screens to build. One complete workflow may need several screens and roles. A screen count tells you very little about whether people can use the software for work.

The UK Government's guide to the beta phase describes building and testing a service that meets user needs, including the wider journey and the people who support it. Its government delivery process has its own requirements. For this maintenance company, the useful question is whether the chosen group can get a job all the way through.

Bring the awkward parts inside that boundary

In our fictional example, the coordinator assigns a job to the wrong team. The team notices before leaving the depot. Somebody needs to correct the assignment, and both teams need to see which version is current. Leaving correction for later would leave a hole in the job you have promised to support.

Go through the proposed work with the people doing it. Ask who may create, change, assign and close a job, and who can see the information. Decide what happens when the job cannot be finished: perhaps access to the building is unavailable, or a part must be ordered. The job needs an agreed next state and someone responsible for it.

The second column depends on the business. If a job cannot be treated as complete until an invoice is issued, decide how that happens in the first release. An agreed handover to the existing invoicing process may be enough. Quietly dropping the step leaves staff to discover the gap.

Include what lets the work keep running

The team will need real job information. Decide which existing records must be brought across, who checks them and how mistakes are handled. An import does not become optional merely because it has no impressive screen.

Agree who creates and removes accounts, answers staff questions, investigates failures and looks after the service. Include the help or instructions that the first group needs. Check what happens if the service is unavailable and how the relevant information can be recovered.

Google's account of transferring operational responsibility discusses readiness checks, documentation and training. It describes Google's own setting, rather than a required team structure for a small business. The practical point here is to name who will run and support the release, and make sure they have what they need.

Test the uncertain part before committing to launch

A prototype can help you check whether the coordinator understands an assignment screen or whether the team can record a visit on a phone. Label what it can demonstrate. A convincing demonstration may still use invented records and skip permissions, storage or recovery.

Before approving production use, agree what evidence is needed for the actual release. For our example, that includes trying a normal job and the wrongly assigned job with the intended roles in a separate test setup. Check that a team cannot see work it should not see, that corrections reach the right people, and that unfinished work remains visible.

Choose further checks around the risks of this system: imported records, simultaneous changes, failure recovery or the amount of work it must handle. One successful walkthrough does not settle all of those questions. Give unresolved risks an owner and decide what must be resolved before staff depend on the service.

Write down the release you are approving

A useful release boundary for the maintenance company could read:

• People: the coordinator and one named maintenance team.
• Work: from recording a job to an agreed completion or an explicitly recorded reason it remains open.
• Essential support: role-based access, corrections, the necessary starting records, staff help, operation and recovery arrangements.
• Acceptance evidence: the agreed normal and awkward cases, plus checks addressing the identified risks.
• Open decisions: named people responsible for answering them before the affected work is approved.
• Later: customer self-service, route planning and automatic invoicing, subject to the agreed handover to existing processes.

Review that boundary with the staff, the person responsible for the business process and the people building and running the software. They should be able to explain both what this release handles and where the rest of the work goes.

We build custom business software. If you want to discuss a first release with us, bring the job you want people to finish, the group who will use it and the parts you are unsure about. Scope, delivery and ongoing care are agreed for the project.

Questions about a first software release