Commissioning Software: A Business Owner's Guide From Idea to Support
A software project for a business runs in seven steps: decide, discover, define, choose, build, launch and run. Coding sits in the middle, and it is rarely where projects fail. They fail when the problem was never pinned down, when the scope keeps moving, when nobody tests with real cases, when staff quietly keep the old spreadsheet, or when nobody pays to keep the system healthy after launch. All five sit on the owner’s side of the table.
This guide follows the sequence that Abdulqader Wahiba, founder and CEO of ZAWAT, recommends every owner insists on, whoever builds the system: understand the work, simplify the work, then build the smallest system that supports it. Each step links to a detailed article in this series.
The short answer
- Decide whether software is the answer at all. Map the process first; often the fix is a change in how the work is done.
- Discover before you build: users, constraints, data, and what the problem costs today. Stopping here is a valid outcome.
- Define a first version small enough to launch, in requirements a developer can quote and test.
- Choose who builds it and what shape it takes: web app, mobile app, portal or website.
- Build with working software on screen every week or two, early data migration and acceptance tests written from real cases.
- Launch with training and a firm end date for the old way of working.
- Run it: a support agreement, a budget for change, and a habit of paying down technical debt.
“Most companies don’t have a software problem. They have a process problem that software has been asked to hide. Fix the process first, and the system you need gets smaller.” — Abdulqader Wahiba, founder and CEO of ZAWAT
Step 1: decide whether software is the answer
Start with the work, not the product. Write down how the process actually runs today, who touches it, where it waits and where it breaks. Mapping the process before you buy software shows a method that takes days, not months.
Three outcomes are possible. The process needs fixing, not software. An existing product covers it, and you should buy rather than build; build or buy an ERP sets out that trade-off. Or the process is specific enough that custom software earns its cost.
Before you call any supplier, do the owner’s own homework: who owns the outcome, what success looks like in numbers you already track, and what you will stop doing. The ten questions to answer before commissioning software is a checklist for exactly that.
Step 2: discover before you build
Discovery is paid research before any build. The UK Government’s service manual puts it plainly: “Before you commit to building a service, you need to understand the problem that needs to be solved.” It also says something suppliers rarely do: “It’s not a failure to stop at the end of the discovery phase if your research shows that’s the best thing to do.”
That second sentence is the point of the step. A discovery that can only end in a build is a sales meeting with a fee attached. The discovery phase covers what it should deliver and how long it usually takes.
Step 3: define the first version
Requirements turn the findings into something a developer can build, quote and test: who needs what, why, and how you will know it works. Writing requirements with user stories and acceptance criteria shows the format.
Scope is where the money goes. A first version that covers the core process and does it well beats a complete system that arrives a year late. Scoping the first version explains how to choose what goes in.
Time is the question owners ask first and the one answered worst. Estimates made at the idea stage can be off by a factor of four in either direction, according to software-estimation author Steve McConnell, and they narrow only as decisions get made. How long a software project takes shows how to read an estimate before you sign.
Step 4: choose who builds it, and what shape it takes
Who. A freelancer, an agency, a software studio and an in-house team suit different projects and carry different risks. Who should build your system compares them, and choosing a software partner in Oman covers the request for proposals, the red flags and the contract clauses. Whoever you choose, settle who owns the code in writing before work starts.
What shape. Many businesses ask for a mobile app when a web app would serve them better, at lower cost. Native app, web app or PWA helps you decide. If customers need to see their orders, invoices or bookings, a customer portal may be the system you actually need. If the goal is to be found and contacted, start with what a company website must do.
Step 5: build, with the owner in the room
The build is the stage owners delegate most and should delegate least. Your job is to make decisions quickly and to look at working software often.
- See it working every week or two. A demonstration on real screens, not a status report.
- Start the data work early. Cleaning and mapping old records takes longer than anyone expects. Moving your data into a new system sets out the steps.
- Test with your own cases. User acceptance testing is how you sign off without regret.
- Watch for drift. Demonstrations that stop, a scope that grows by stealth and a supplier who goes quiet are early warnings. If the developer disappears altogether, rescuing a stalled project covers what to secure first.
Resist adding people to rescue a late schedule. Frederick Brooks observed in 1975 that “adding manpower to a late software project makes it later”, because newcomers need time and attention from the people already doing the work.
Step 6: launch, and make the new way the only way
A system that staff work around is the most expensive one you own. Adoption is planned, not hoped for: training built on daily tasks, a named champion in each team, and a date after which the old spreadsheet becomes read-only. Getting staff to use the new system explains how.
Step 7: run it for years, not months
Most of a system’s cost and most of its value arrive after launch. Plan for both from the start:
- A support agreement with response times you can hold the supplier to. What a maintenance and support agreement should cover lists the clauses.
- A budget for change, because the business will change, and so will tax rules, devices and the systems you connect to.
- A habit of paying down shortcuts before they compound. Technical debt, explained for owners shows how to spot it.
- Clean data, especially before you put AI on top of it. Is your data ready for AI? covers what to fix first.
The owner’s checklist, step by step
| Step | The owner’s job | What you should hold at the end |
|---|---|---|
| Decide | Name the problem, the owner and the measure of success | A process map and a one-page brief |
| Discover | Give access to people, data and constraints | Findings, a recommendation, and the freedom to stop |
| Define | Choose what goes into version one | Requirements with acceptance criteria; an estimate given as a range |
| Choose | Compare like with like; settle ownership | A signed contract covering IP, handover and support |
| Build | Decide quickly; attend demonstrations | Working software every fortnight; rehearsed data migration |
| Launch | Set the cut-over date; back the champions | Trained users; the old tool retired |
| Run | Fund support and change | A support agreement, a roadmap and a debt list |
Two more articles in the series
Two further pieces cover situations most mid-sized companies meet. Digital approvals for purchases, leave and expenses replace the chains that stall when a manager travels. And for family-owned companies, digital transformation in a Gulf family business deals with the part no software vendor mentions: trust, succession, and the one person who knows everything.
Frequently asked questions
What is the owner’s most important job in a software project? Deciding. Owners who answer questions within days, attend demonstrations and hold the scope keep projects on course. Delegating every decision to the supplier is how a system ends up fitting the supplier’s assumptions instead of your business.
How long does a typical business software project take? It depends on the number of workflows, the integrations and the state of your data. Treat any precise date given at the idea stage with caution: early estimates can be off by a factor of four either way. A good supplier gives a range that narrows as discovery and requirements are completed.
Should I pay for a discovery phase? Usually, yes. It is the cheapest point at which to find out that the project should be smaller, different or not happen at all. Paying for it separately also keeps the supplier honest, because their fee does not depend on recommending a build.
What should I own when the project ends? The source code, the database schema, the deployment configuration and the documentation. Agree this in the contract before work starts. ZAWAT publishes the same principle on its about page: you should be able to leave.
When is custom software the wrong choice? When a standard product covers the process with little compromise, or when the process itself is broken and software would only make the mess faster. In both cases, buying or fixing the process is better value.
Sources: GOV.UK Service Manual — How the discovery phase works · Steve McConnell — Software Development’s Cone of Uncertainty (Construx, 2010) · Frederick P. Brooks Jr., The Mythical Man-Month (Addison-Wesley, 1975)
This guide is the hub of a 20-part series from ZAWAT (ذوات), the software studio Abdulqader Wahiba founded in Muscat in 2024, on commissioning software from the owner’s side of the table.
Planning a system and want a second opinion before you commit? ZAWAT designs and builds custom software for businesses in Oman and the GCC, starting with discovery. Book a call.