10 Questions to Answer Before Commissioning Software: Abdulqader Wahiba's Checklist for Owners
Before you ask anyone to build software for your business, answer ten questions in writing: what problem you are solving and what it costs now; who owns the result; how the work runs today; who will use the system; what you will stop doing; whether a standard product already covers it; what it must connect to; which rules apply; what success looks like; and what you can spend to build and run it.
These are the questions Abdulqader Wahiba, founder and CEO of ZAWAT, recommends every owner answers before speaking to any developer, ZAWAT included. None needs technical knowledge. All of them change the price, the timeline or the decision to build at all.
The short answer
- Two pages of honest answers will save you more money than any negotiation over day rates.
- The first two questions matter most: a problem with a cost attached, and one person inside the company who owns the result.
- If a standard product covers most of the need, buy it and spend on configuration and integration instead.
- Give every supplier the same answers. It is the only way to compare their proposals fairly.
- A supplier who never asks about these things is telling you how the project will go.
1. What problem are we solving, and what does it cost us now?
Write the problem in one sentence, without naming a solution. “Orders are re-typed from WhatsApp into the accounting system, and about one in twenty has an error” is a problem. “We need an app” is a solution looking for one.
Then put a rough cost on it: hours per week, people involved, errors per month, sales lost to slow replies. The UK Government’s guidance for digital projects asks teams to understand “how much the problem is currently costing” before building anything. A range is fine. Without it, you cannot tell whether a quote is expensive or cheap.
2. Who inside the company owns the result?
Name one person with the authority to make decisions and the time to make them quickly. Not the IT person by default, and not a committee. The owner of the result is usually whoever runs the process being changed.
Projects without this person drift. Questions wait a week for answers, and the supplier fills the gaps with assumptions. Why ERP and CRM projects fail puts this decision first for a reason.
3. How does the work run today, and what would we change even without software?
Walk through the process step by step with the people who do it, including the exceptions: the order that needs a manager’s approval, the customer who pays in two instalments, the report rebuilt by hand every Thursday. Mapping the process before you buy software shows a simple method.
Then ask what you would remove or simplify if software did not exist. Every step deleted before the build is a step nobody pays to automate.
4. Who will use it, on what devices, and in which languages?
List the users by role: office staff at desks, drivers on phones, customers on their own devices, a manager approving from abroad. Each changes what gets built. If your staff and customers work in Arabic and English, say so now. Bilingual software is built in from the first screen, not translated at the end; building bilingual Arabic-English software explains why.
5. What will we stop doing on the day it goes live?
This is the question owners skip and later regret. If the old spreadsheet, the WhatsApp group and the paper form all survive alongside the new system, your staff now do the work twice. Decide in advance what gets retired, and on what date.
6. Does a standard product already cover most of this?
Check before you commission anything custom. Accounting, payroll, point of sale and e-commerce are well served by products that are cheaper to buy than to build. ZAWAT’s published principle is blunt: if a standard product covers the requirement, say so, even when the custom build would have been the bigger contract. Build or buy an ERP? sets out how to decide.
Custom software earns its cost where your process is genuinely different, or where it ties several systems together in a way no product does.
7. What must it connect to, and where does our data live today?
List every system the new one must exchange data with: accounting, payment gateway, WhatsApp Business, your website, a government portal. Integrations are often the largest single driver of cost, as what custom software really costs explains.
Then list where today’s data sits and how clean it is. Ten years of customer records in three spreadsheets with different spellings is a project of its own. Moving your data into a new system covers it.
8. Which rules apply?
Three come up for almost every business system in Oman:
- Personal data. If the system holds data about customers or staff, the Personal Data Protection Law applies. What Oman’s data protection law changes inside your systems lists the practical effects.
- E-invoicing. If the system issues invoices, it must be ready for Oman’s e-invoicing programme. See what Fawtara requires from your systems.
- Records. Article 70 of the VAT Law requires tax invoices and accounting records to be kept for ten years after the end of the tax year of the return, and fifteen for real estate. Whatever you build must keep them readable for that long.
9. What does success look like in a year, in numbers we already track?
Pick two or three measures you already collect, so you can compare before and after: days to issue an invoice, orders handled per person, errors per month, time to answer a customer. Avoid measures you would have to invent a new process to collect. If nothing can be measured, the project’s value will be argued about forever.
10. What can we spend, to build it and to run it for five years?
Give suppliers a budget range. It is not a weakness in negotiation; it is the only way to get proposals shaped to what you can afford. And budget beyond launch: hosting, support, security updates and changes as your business moves. What a maintenance and support agreement should cover shows what running costs consist of.
What to do with the answers
Put them in a brief of two pages at most and give the same brief to every supplier you talk to. Their questions back will tell you a great deal. A supplier who asks about your exceptions, your data and your stop list is thinking about your business. One who quotes from the brief without a single question is pricing a guess. Choosing a software partner in Oman covers what to ask them in return.
| Question | If you can’t answer it yet |
|---|---|
| 1. Problem and cost | Time one week of the current process |
| 2. Owner | Don’t start until someone is named |
| 3. Process today | Map it with the staff who do it |
| 4. Users and languages | List roles, not names |
| 5. What stops | Decide before the build, not after |
| 6. Standard product | Trial two products first |
| 7. Connections and data | Inventory systems and spreadsheets |
| 8. Rules | Ask whether it holds personal data or issues invoices |
| 9. Success | Pick measures you already collect |
| 10. Budget | Set a range, including five years of running |
A note from Abdulqader Wahiba: if you can answer only three of these, answer the first, the second and the fifth. A real problem, an owner with authority and a decision about what stops are worth more than any feature list.
Frequently asked questions
Do I need all ten answers before I talk to a developer? No. The first, second and fifth are the minimum. A good discovery phase will help you answer the rest, and the discovery phase explains what it should produce.
Should I give the same brief to several suppliers? Yes. The same brief is what makes their proposals comparable. Differences in price then reflect differences in approach, not differences in what each supplier assumed.
What if I can’t put a number on the cost of the problem? Estimate it from what you have: hours per week multiplied by the people involved, errors per month, complaints, delayed payments. A rough range is far better than none.
Who should write the answers? The person who owns the result, together with the staff who do the work every day. An answer written only by management usually misses the exceptions that decide whether the system gets used.
What if a standard product covers most of what we need? Buy it, and spend your budget on configuration, integration and training. Custom software is worth its cost only where your process is genuinely different.
Sources: GOV.UK Service Manual — How the discovery phase works · Value Added Tax Law, Royal Decree 121/2020, Article 70
Want someone to go through your answers with you? ZAWAT builds custom software for businesses in Oman and the GCC, and will talk your brief through before anyone proposes a build. Book a call.