Before you commission a system: questions that come before any quote
The questions I ask a business owner before I write a single line of code, and why the answers change a system’s cost and timeline more than any feature list.
In short
- What a system costs depends on the problem, the users, the existing data and what happens after delivery, far more than on the feature list.
- Write your current problem on one page and name every type of user before you meet any developer.
- Ask who hosts the system, who owns the domain and the accounts, and where the backups are. That is what life after delivery looks like.
In this article
When a business owner comes to me for a system, they usually open with a list of features: an app, a dashboard, reports, a link to WhatsApp. I open with different questions. The answers decide the cost and the timeline more than any list does, and they save both of us weeks of misunderstanding.
The questions come from projects I have worked on in Iraq. Some were new systems, and some were live systems I inherited. I will go through them in the order I ask them.
Start with today’s problem, not the feature list
The first question: what is happening in your company right now that costs you money or time? I want the answer in one sentence, with an example from last week. Something like ‘customers order by phone and half the orders get lost’ tells me more than ten pages of description.
On a delivery project I inherited while it was already live, we began with a written audit before fixing anything, and every finding was tied to evidence. Had we fixed the complaints one at a time, we would have treated the symptoms and left the cause where it was.
The same goes for you before you commission a new system. Write down the problem and the evidence for it first, then ask for the solution.
One page
is enough to set out the problem, the users and the data before you meet any developer
One part
working with real users, before the rest is built
3numbers
you look at every morning, and the reports start from them
People before screens
Who will use the system every day?
The second question: name every type of user for me. The owner, the accountant, the cashier, the courier, the customer. Each type needs a screen, permissions and a way of learning the system, and every screen adds to the cost.
Fast Order is a clear example. It has a customer app, a courier app, a dashboard for restaurants and a dashboard for management. Anyone who says ‘a delivery app’ is picturing one screen. The real thing is four systems that talk to each other.
Think as well about the user who does not like technology. With Madar it was clear that many merchants are not comfortable with it and run their business from a phone. So I built them a phone app alongside the web dashboard.
Delivery appFast OrderA delivery app at the level of the big apps, running in Al-Suwaira, a district of Wasit governorate.
Who on your side says yes or no within a day?
The third question is for you, not for the developer. A project runs into dozens of small decisions every day, such as what to call an order status or who gets to see the wholesale price. If each one waits for next week’s meeting, the project moves at the speed of the meeting.
On the best projects I have worked on, the owner’s notes arrived after every round and we closed them in batches. That rhythm works because someone answers. Pick one person on your side who has the authority, and give the developer their name and number.
What data exists today?
The fourth question: where does your information live now? In a notebook, an Excel file, WhatsApp messages, or the head of a long-serving employee? A new system starts empty, and the old data is what makes it useful from the first day.
On digital menu projects we start from the menu the restaurant already has. Nothing is built from zero, and we go straight to review and correction.
Then there is a harder question: is that data correct? On company websites we keep to one rule, which is to write only what the company’s own documents prove. Anything unproven stays off the site until the owner confirms it.
Tip: One fact sheet
On restaurant projects we gather the name, address, opening hours and phone number in one file. Every item in it is marked as confirmed, assumed or unknown. The website and every other platform copy from this file and nowhere else.
Try the same before any project. You will find that your own company writes its name and its hours in two different ways.
Questions that change the cost quietly
Nobody thinks of these until they turn up in the middle of the project, so I raise all of them at the first meeting. Each thing said in the meeting sounds simple, and behind each one sits a decision.
| Topic | Said in the meeting | What it means for the system |
|---|---|---|
| Payment | ‘Payment is electronic’ | Which gateway? Each has its own interface, its own way of settling and its own cost to implement. |
| Internet | ‘Our internet drops’ | Does the cashier keep selling and recording when the connection is lost? The answer changes the structure of the whole system. |
| Language and numbers | ‘We want it in Arabic’ | Arabic only, or English too? Arabic-Indic or Latin digits? The currency is dinars and the time is Baghdad time. |
| Permissions | ‘Every employee logs in’ | Who sees what? Permissions for each role, and a log that shows who changed what and when. |
| Reports | ‘We want reports’ | Which reports? Write down three numbers you look at every morning, and we start with those. |
| ‘Give us WhatsApp’ | A notification such as a verification code, or a full conversation with the customer? The first is simple. The second is a system in itself. |
Payment deserves a few more words. When a platform connects to more than one gateway, each gateway has its own interface, its own settlement terms and its own way of failing. If we know at the first meeting which gateways your customers actually use, the estimate is more accurate.
The internet question has a separate article of its own, because the answer changes how the system is built from the ground up.
And what happens after delivery?
The last question is the one everybody forgets. Who hosts the system? Who owns the domain and the service accounts? Where are the backups, and has anyone actually tried restoring them?
With Fast Order we host, run and develop the system, so there is one party to call when something breaks on a Thursday night. On other projects we take encrypted backups of the database and the images, and test restoring them on an isolated server to be sure. I do not count a backup that has never been tested as a backup.
Ask before you sign: where does the system run, who holds its keys, and how do I restore it on the day something breaks?
Think about old versions too. The Fast Order app has a maintenance screen, and a gate that makes anyone on a very old version update. Nobody asks for details like these at the first meeting, but they are what gets you through a bad day.
The company owns the domain and the accounts, whichever team manages them. That protects you if you move to another team a year later.
One page, then offers you can compare
What to prepare before the first meeting
Put the answers on one page. You do not need a huge document. You need clear sentences that any developer can read in five minutes.
What to prepare before you talk to any developer
How to read the offers once you have your answers
When two offers are far apart in price, ask first what each one assumed. You will usually find they describe two different jobs. The page you wrote is what makes them comparable.
Give everyone the same page
Each developer reads the same problem, users and data, so their assumptions line up.
Ask for an estimate per part
Payments, permissions, reports and offline work. This shows you where the difference comes from.
Agree on a small first delivery
One part working with real users. Whoever avoids a small delivery will be late on the big one.
Write down what comes after delivery
Hosting, support, backups, and who owns the accounts.
The short version
A good system starts with one page from the business owner. The code comes after. If you answer these questions before you talk to anyone, the offers you receive can be compared, and you will know who actually understood your business.
Projects mentioned in this article
Questions
Do I need a long requirements document before I start?
No. One page is enough: the problem, the users and the data you already have. The details get written with the developer once they understand your business.
How do I know the developer has understood my business?
They ask about the problem, the users and the data before they talk about tools and prices. If they open with technology alone, be careful.
Who should own the domain and the hosting accounts?
The company. Register them in your name and with your email, and give the developer access. This protects you if the team changes one day.
Should I start with a full system or with one part of it?
Start with one real part that works with actual users, then add to it. The first part shows you what you did not expect.
