The First Version of a Business System: Small Enough to Finish, Complete Enough to Replace
The first version of a business system should cover one core process from start to finish, for the people who do it every day, well enough to replace the old way of doing it, and nothing more. Everything else waits until real use shows what is actually needed. Small does not mean flimsy: security, access control, both languages and data export belong in version one, because they cannot be bolted on later without rework.
The test is simple: can you name the spreadsheet, form or chat group the first version retires? If not, it is not a first version yet. It is a demonstration.
The short answer
- One process, end to end, chosen for its pain and its clear owner.
- Must haves are what staff need to do that job every day, including the exceptions that happen weekly.
- Rare exceptions are handled manually at first, and automated only if they turn out to be frequent.
- Never cut: security and permissions, audit trail, backups, personal data protection, Arabic and English, data export.
- Usually waits: extra dashboards, rare cases, a native mobile app, AI features and non-essential integrations.
- Version two is planned from usage, not from the original wish list.
What “minimum” means for a business system
The term “minimum viable product” comes from start-ups. Eric Ries, who popularised it, defined it in 2009 as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. He added a warning that is often forgotten: “MVP, despite the name, is not about creating minimal products.”
A business system is different from a start-up’s experiment in one important way: people must run real operations on it from the first day. So the useful idea is not the smallest thing you can show, but the smallest thing your staff can actually use to do their work. The DSDM framework, now maintained by the Agile Business Consortium, describes the Must Haves as the “Minimum Usable SubseT”, which is the right spirit.
Abdulqader Wahiba, founder and CEO of ZAWAT, puts the trade-off this way:
“We would rather build less software that people use every day than a bigger system they work around. A first version should be small enough to finish and complete enough to replace something.” — Abdulqader Wahiba
His test for any proposed first version is the one above: name what it retires.
How to choose what goes in
1. Pick one process
Start from your process map. Choose the process with the most pain and a clear owner, such as order to invoice, purchase requests or job scheduling. One process done properly teaches the organisation more than five done halfway.
2. Define “done” as something retired
Write down which spreadsheet, paper form or WhatsApp group the first version replaces, and the date it becomes read-only. That turns a vague goal into a scope.
3. List the musts from real cases
Walk recent real cases through the proposed system. What does staff need to complete each one? Include the exceptions that happen every week. Exceptions that happen twice a year can be handled by a person, with a note, until you know they matter.
4. Keep the reports people actually use
Ask which two or three reports are used every week to make decisions. Build those. A long list of “nice to have” reports is usually a sign that nobody has yet decided what to measure; dashboards and reporting helps with that.
5. Integrate only what the process cannot work without
If the process needs live stock levels or payment status, connect them. If a nightly export to the accounting system would do for now, start with that. Each integration adds testing, risk and time.
6. Migrate only what is needed to operate
Open orders, active customers and current price lists, yes. Ten years of closed history can usually be archived in a readable form and consulted when needed. Moving your data into a new system explains the approach.
What never gets cut
Some things look optional in a first version and turn out to be expensive to add later:
- Roles and permissions, so each person sees and changes only what they should. Access control and audit trails covers the design.
- An audit trail of who changed what and when.
- Backups that have been tested by restoring from them.
- Personal data protection, decided before the first screen. See privacy by design.
- Arabic and English, built from the first component. Retrofitting right-to-left layout into a finished interface costs more than building it in, as ZAWAT’s published principles put it.
- Data export, so you can always get your records out.
What usually waits
| In version one | Usually waits | Never cut |
|---|---|---|
| One core process, end to end | Rare exceptions (handled manually) | Permissions and audit trail |
| Weekly exceptions | Extra dashboards and reports | Backups, tested |
| The two or three reports used weekly | Native mobile apps (start with the web) | Personal data protection |
| Essential integrations | Non-essential integrations | Arabic and English |
| Data needed to operate | Full historical migration | Data export |
| Training for the people who use it | AI features | Security updates |
A native mobile app is a common candidate for later: a phone-friendly web app serves most users first, as native app, web app or PWA explains. AI features are another: they work far better once the system holds clean, structured data, which is the subject of is your data ready for AI?.
An example: a maintenance company
Take a hypothetical building-maintenance company in Muscat that runs on phone calls, a WhatsApp group and a spreadsheet of jobs.
A sensible first version covers one process: a job comes in, is assigned to a technician, is completed with photos and a customer signature, and is marked ready to invoice. Invoices are still raised in the existing accounting system, from an export. Supervisors get one report: open jobs by age and technician.
What waits: a customer portal, automatic invoicing through an integration, spare-parts inventory and route planning. Each may well come later, once the job records show where the time actually goes.
After launch: let usage decide version two
Collect requests in one list, with who asked and why. Look at what people actually do in the system: which screens they use, where they get stuck, which manual workarounds reappear. Then plan the next version from that evidence. The original wish list was written before anyone had used the system; it is a starting point, not a commitment.
Frequently asked questions
Is a first version the same as a prototype? No. A prototype is for testing an idea and is often thrown away. A first version runs real operations, with real data, security and support. It is small, but it is finished.
Does building in phases cost more in total? Sometimes slightly, because later phases revisit earlier work. But it usually costs less than building a large system in one go and discovering after launch that parts of it were never needed.
How small is too small? If it does not replace anything, it is too small. Staff will keep the old tool, and the new system will become an extra step instead of a better one.
Can the first version be released to customers? Yes, if it is complete for the part it covers. Customers are less forgiving than staff, so test it with real cases first and keep the scope narrow.
What if every department wants its process in version one? Choose by pain and ownership, publish the order, and give each department a date. A clear sequence is easier to accept than a vague promise that everything will come together.
Sources: Eric Ries — Minimum Viable Product: a guide (2009) · Agile Business Consortium — What is MoSCoW Prioritization?
Want help deciding what your first version should be? ZAWAT scopes and builds custom software and business systems that launch small and grow from real use. Book a call.