Software
How to scope the first version of business software
Define one useful workflow, its users and acceptance criteria before adding dashboards, integrations or future features.
The first version of business software should complete one valuable workflow reliably. Start by naming the user, the job they need to finish and the information they need to do it. A feature list is useful later; it is a poor substitute for understanding the work.
Describe one journey from start to finish
Suppose a service team needs to handle new enquiries. A first version might let an operator receive a structured request, see its details, assign it and record the next action. This is an illustrative scope, not a description of a customer's system.
Write the journey as ordinary steps. Where does the request come from? What information must be present? Who can see it? What decision happens next? What should the record show after the operator acts? If several people have different permissions, name those differences early.
Set a boundary for version one
For the example above, a focused first release might include:
- A customer form with the few fields needed for triage.
- An operator view showing new and assigned enquiries.
- An assignment action and a dated follow-up note.
- A way to detect failed notifications and find the original record.
A customer portal, automated pricing, complex reports and broad CRM integration can wait unless the first workflow cannot function without them. Deferring a feature does not mean it is unimportant. It means the first release can be tested before more dependencies are added.
Write acceptance criteria as observable outcomes
“Easy to use” is a goal, but it is hard to test. Better criteria describe what someone can do and what the system must record:
| Situation | Expected result |
|---|---|
| A customer submits a complete enquiry | One record appears for the operator with the submitted details. |
| Required information is missing | The form explains what is needed without losing valid entries. |
| An operator assigns an enquiry | The right person and assignment time are visible. |
| A notification fails | The enquiry remains in the workspace and the failure is visible to someone responsible. |
These are example criteria. The real project needs its own users, data rules and failure cases. Test the complete journey with realistic sample data before calling the version finished.
Agree the ongoing work
Ask who will manage accounts, update the software, back up data, handle support and approve future changes. Record what belongs to the business and what a developer will maintain. A small first release still needs a safe way to fix a defect and recover from a failed deployment.
The first release is easier to judge when its limits are visible. In the illustrative enquiry workflow, the software records and routes a request; it does not assess the job, agree a price or promise an appointment. Those remain business decisions. If you have a workflow to turn into a first release, explore the software service or start a project.
Put the thinking into practice
Make the next step clearer.
Explore how I can help with bespoke business software, or tell me what you have in mind.
Explore software