Custom Software Development in Pakistan: The Requirements Checklist Before You Hire

Most custom software projects that go wrong in Pakistan do not fail because the developer was bad. They fail because nobody wrote down what the software was for until money had already been spent.

The pattern is always the same. A business owner describes the problem in a half-hour meeting. The developer hears enough to start. Three weeks later there is a demo, and it is not wrong exactly — it just answers a slightly different question than the one the owner was asking. Another meeting, another three weeks, and now there is a disagreement about whether the change is a fix or a new feature.

That whole argument is avoidable, and it is avoidable before you hire anyone. This is the checklist we wish every client arrived with — not a technical specification, which is our job, but the business facts only you have. Working through it takes an afternoon. It will save you weeks, and it will tell you more about which developer to hire than any portfolio.

1. The workflow, written as it actually happens

Not how it should happen. How it does.

Write down one complete journey through your business, step by step, including the ugly parts. Who touches it, in what order, what they write down, where it waits, and what they do when something goes wrong. If an order arrives on WhatsApp, gets copied into a register, then into Excel at month end, write all three down.

The ugly parts matter most, because that is where the software either earns its money or becomes a second job. We have seen a shop where the "system" worked perfectly except that every evening someone re-keyed the day's sales into a separate book, because the accountant wanted it in a particular order. Nobody mentioned that in the requirements meeting. It was just what Tuesday looked like.

What to bring: one workflow per page, from the moment work arrives to the moment it is finished and paid for.

2. Who does what, and what they must not see

List every person who will open the software and what each is allowed to do. Then — more importantly — what each must not do.

This is the single most common gap. "Staff can use it" is not a requirement. A cashier who can edit a price after the sale, a storekeeper who can see purchase costs, a branch manager who can see another branch's figures: each of those is a decision, and each is far cheaper to decide now than to retrofit.

Be specific about approvals too. Who can give a discount beyond the limit? Who can void a bill, and for how long after it was made? Who can reopen a closed month? In our own products these turned out to be the rules owners cared most about, and they are invisible on a feature list.

What to bring: a table of roles down one side, actions across the top, and a yes or no in every cell.

3. The reports you will actually open

Everyone asks for "reports and dashboards". Almost nobody can name the three they will look at on a Monday morning.

Do that instead. Name each report, say who reads it, how often, and — this is the part that changes the build — what decision it leads to. A report nobody acts on is a page that costs money to build and maintain forever.

Then say what each figure means to you, because the obvious words are not obvious. Does "sales" include tax? Does it include an advance a customer paid for goods not yet delivered? Is a return subtracted from today or from the day of the original bill? Two accountants will answer differently, and the software has to pick one.

What to bring: three to five named reports, each with its reader, its frequency, and the decision it drives.

4. What it has to talk to

Software almost never lives alone. List everything it must exchange data with, and be honest about which direction the data flows.

• Money: a bank, Easypaisa, JazzCash, a card terminal, a payment gateway.
• Messaging: SMS to customers, WhatsApp, email.
• Tax: FBR POS integration if you are a Tier-1 retailer, which brings its own rules about invoice numbers and credit notes.
• Hardware: thermal printers, barcode scanners, label printers, a cash drawer, a weighing scale.
• Other software: your accountant's package, a supplier's portal, an existing website.

For each one, the useful question is not "can it integrate?" — most things can — but what happens when it is down. If the SMS gateway fails at 9pm, does the sale stop? If the internet drops, does the counter stop? We build our own POS products offline-first for exactly this reason, and the decision has to be made at the start, because it shapes everything underneath.

What to bring: a list of integrations, each marked as essential or nice-to-have, with what should happen when it is unavailable.

5. The data you already have

This is the step that quietly eats project timelines, and it is almost never in the first conversation.

You have history: customers, suppliers, stock, outstanding balances, maybe years of it. Someone has to get it in. The questions worth answering now:

• Where is it? Excel, an old software's database, a register, three registers and a notebook.
• How clean is it? Are there duplicate customers under slightly different names? Three men called Muhammad Ashraf with no way to tell them apart?
• How much history do you actually need? Usually far less than people expect. Current balances carry forward; the bills behind them are already settled into that figure. Entering positions rather than history turns a month of typing into a day.

Ask any developer how they handle an import that fails halfway. The answer tells you a great deal. A good one previews what will change before writing anything, numbers the rows that are wrong, and can resume after a crash. We learned that the hard way and it is now the part of our own software we test hardest.

What to bring: a sample export of your real data — twenty rows is enough — and an honest account of where the mess is.

6. Money, and how it is staged

Nobody can quote a fixed price for software whose requirements are not fixed, and a developer who gives you one on day one has either padded it heavily or will come back for more.

What you can and should fix is the shape of the spend. Ask for the work in stages, each with something you can open and use at the end of it. A first stage that bills and prints correctly is worth more than four weeks of invisible progress on a system that does everything.

Questions worth asking before you sign:

• What is the first stage, and what will I be able to do when it lands?
• Is this billed by stage, by month, or on delivery?
• What counts as a bug, which you fix, and what counts as a change, which I pay for?
• Who owns the code and the data when it is finished?
• What does support cost after go-live, and what does it cover?

The last three are where relationships break. Get them in writing, however comfortable the conversation feels now.

What to bring: a budget range you are comfortable with, and the one outcome that would make the project worth it.

7. Who runs it when we are gone

Software is not finished when it is delivered. Decide now who in your business owns it: who adds a new user, who changes a price list, who notices the backup has not run.

And ask what happens on the bad day. Where are the backups, how do you restore one, and has anybody ever tried? A backup nobody has restored is a hope, not a backup.

What to bring: the name of one person in your business who will own this after launch.

The checklist, in one place

What good answers sound like

Take the checklist to two or three developers and listen to how they respond. The signal is not enthusiasm — it is specificity.

Encouraging: they ask about the ugly parts of your workflow. They push back on a report you cannot justify. They want to see your real data early. They talk about what happens when the internet or the printer fails. They propose a small first stage rather than quoting the whole thing.

Worth a second thought: a fixed price before seeing your data. "Yes" to every integration without asking what happens when it is down. A quote that only lists technologies. Reluctance to put ownership and support terms in writing. A six-month first delivery.

We have built five products of our own — pharmacy, agriculture, book depot, school and sales software — and almost everything on this list is something one of them taught us by being wrong first.

Frequently asked questions

How much does custom software cost in Pakistan?

There is no honest fixed figure, because the work is not fixed. What you can pin down is the shape of the spend: ask for staged delivery with something usable at the end of each stage, and a clear line between a bug and a change. Our own custom software and ERP work is quoted after the requirements conversation, not before it.

How long does a custom software project take?

Most of ours run between two weeks and three months depending on scope, delivered in stages rather than one drop at the end. The variable that moves it most is not the feature list — it is the state of your existing data.

Do I need to write a technical specification before hiring?

No, and you should be wary of anyone who asks you to. The technical design is the developer's job. What only you can supply is the business reality: the workflow as it actually runs, who may do what, which reports you open, and what the figures mean in your trade.

What is the most commonly forgotten requirement?

Two, equally. Permissions — what each person must not be able to do — and data migration. Both are cheap to decide at the start and expensive to add later, and neither appears on a feature list.

Should I buy ready-made software instead?

Often yes, and we will tell you so. If your trade is well served by an existing product, buying it is faster and cheaper than building — which is why we sell five of our own rather than building every pharmacy a new POS. Custom work earns its keep when your process is genuinely your own, or when you need several systems to talk to each other.

Who owns the code when the project is finished?

Settle this in writing before work starts, whoever you hire. Ask the same about your data: how you export it, in what format, and whether you can do it yourself without asking.

What happens after go-live?

Someone in your business has to own it, and someone has to answer the phone when it breaks. Ask what support costs, what it covers, and what the response looks like at 9pm on a Saturday — because that is when counters actually stop.

In short

You do not need to know how software is built to hire well. You need to know your own business precisely enough to describe it: one workflow written honestly, a table of who may do what, the reports you will really open, what the system must talk to, where your data is and how messy it is, what you can spend, and who owns it afterwards.

Bring that to a conversation and two things happen. The quotes you get back are comparable, and the person who should not be building your software usually reveals it in the first twenty minutes.

If you want to work through it with us, talk to us — we are in Jhang, on WhatsApp and the phone — or read more about custom software and ERP solutions. Not sure whether to build or buy? Start with what we already sell.