The short answer
Nobody can honestly price custom software before they understand the work. The cost is driven by things you can identify in advance: business rules and exceptions, user roles and approvals, integrations, data migration, and security, privacy and audit obligations. Add hosting, support and maintenance for every year the software is in use; that is part of the cost, not an afterthought.
The practical approach is to budget in three pieces: a small, fixed-scope discovery; a first release sized to the most valuable part of the problem; and a yearly allowance for running and improving what you built. If a quote arrives without any of those, ask why.
What actually drives the cost
Screens are not what make software expensive. Rules, connections and data are.
| Cost driver | Why it matters | What to have ready |
|---|---|---|
| Business rules and exceptions | Every "except when" needs design, code and testing. Exceptions are where most effort goes. | Real examples of awkward cases, not just the normal path |
| User roles and approvals | Each role needs its own permissions, screens and tests, including what it must not see | A list of who does what, and who signs off |
| Integrations | Connecting to your ERP, CRM, accounting, payment gateway or Microsoft 365 depends on their APIs, limits and data quality | Names and editions of the systems involved, and who administers them |
| Data migration | Old spreadsheets and databases carry duplicates, gaps and unwritten rules | Sample exports and an owner who can decide what is correct |
| Security, privacy and audit | Personal information brings obligations under the Nigeria Data Protection Act 2023 (NDPA); some processes need full audit trails | Your privacy commitments, retention rules and any customer or regulator requirements |
| Accessibility and language | Public-facing software should be usable by everyone, on phones first, and some organisations need local languages as well as English | Who the users are, which devices they use, and whether any are members of the public |
| Hosting, power and connectivity | A tool used during office hours costs less to run than one that must be available around the clock, and users on patchy connections need software that copes with them | How much downtime the business can tolerate, and where the users work |
Two deserve a Nigerian note. If the software handles personal information, the NDPA, enforced by the Nigeria Data Protection Commission (NDPC), shapes design decisions such as lawful basis and consent, data subject rights, retention, data protection impact assessments for high-risk processing, and rules for transfers outside Nigeria; the NDPC's General Application and Implementation Directive (GAID) 2025 sets out how it applies in practice. And for accessibility, the Discrimination Against Persons with Disabilities (Prohibition) Act 2018 sets a general duty without naming a web standard, so we recommend targeting WCAG 2.2 Level AA as good practice. Designing for both from the start costs far less than retrofitting.
Why quotes for the same project differ so much
When three firms quote the same brief and the numbers are far apart, it is usually because they are quoting different things:
- Different assumptions about exceptions. One firm priced the happy path; another priced the edge cases you mentioned in passing.
- Testing and documentation included or not. Automated tests, deployment pipelines and handover documentation take real time. Leaving them out makes a quote look cheaper and the software more expensive to own.
- Data migration treated as "your job". Moving and reconciling data is often left vague. Ask who does it and how results are checked.
- Different views of risk. A fixed price includes a buffer for uncertainty. A time-and-materials estimate shows you the uncertainty instead.
- Different currencies and exchange assumptions. A quote in naira and a quote with dollar-priced cloud or licence items are not comparable until you see the exchange rate each one assumed.
- Who owns the result. Confirm that source code, infrastructure and accounts end up in your organisation's name. Under Nigerian copyright law, the first owner of copyright is generally the author, or in some cases the employer, and an assignment of copyright generally has to be in writing, so code written by an outside firm needs a written assignment or licence in the contract. Have your legal adviser confirm the wording.
The fair way to compare quotes is to ask each firm to list its assumptions and exclusions. The cheapest total with the longest exclusion list is rarely the cheapest project.
How to build a realistic budget
1. Fund discovery separately. A short, fixed-scope discovery maps the process, the rules, the data and the systems involved, and ends with a written scope, a release plan and an estimate in naira (or US dollars where a licence or service is priced in dollars). It is the cheapest point at which to find out the project is bigger, smaller or different than you thought.
2. Size the first release to the most valuable problem. Not the whole wish list. A first release that replaces one painful spreadsheet or approval process properly is worth more than a broad release that does everything half-way.
3. Hold a contingency. Requirements change once people see working software. That is healthy, and it is why part of the budget should be held back. If cloud services or licences are priced in dollars, hold an exchange-rate allowance as well.
4. Budget for the years after launch. Plan a yearly amount for hosting, security updates, monitoring, support and small improvements. Unfunded software becomes a risk, however good the first version was.
5. Check the tax treatment. Ask your accountant how development spending is treated for tax, including VAT and withholding tax on the supplier's invoices, and whether any government or development-agency programme might apply to your organisation. Do not count on an incentive until it is confirmed. This is general information, not tax advice.
A hypothetical budget structure for a mid-sized distributor replacing a spreadsheet-based returns process:
- Discovery (fixed scope): map the returns process, list the exceptions, review ERP integration options, produce a scope and phased estimate.
- Release 1: returns requests, approvals and credit notes pushed to the ERP, for two user roles.
- Release 2 (only if release 1 proves its value): customer self-service portal and reporting.
- Contingency: a portion of each release held for changes that emerge in testing, plus an exchange-rate allowance for any dollar-priced items.
- Yearly running allowance: hosting, monitoring, updates and a small block of improvement hours.
Each line would carry its own estimate in naira (or US dollars where priced in dollars) and its own list of assumptions.
Rather talk it through? We can turn your process into a written scope and a phased estimate before you commit a full budget. Talk to a Promatics specialist
The questions people ask before they call us
"We are too small for custom software." Sometimes true, and we will say so. If a packaged product fits with configuration, buy it. Custom work earns its place when the process is specific to you and workarounds cost you time every week. Our build, buy or integrate guide helps you decide honestly.
"Can AI tools build this for less?" AI coding assistants genuinely speed up parts of development, and we use them, with people reviewing the output. They do not uncover your exceptions, decide what happens when rules conflict, test against your real data, or answer for the result when something breaks. That judgement and accountability are most of what you are paying for.
"What if the project runs over?" Phased releases limit the damage. Each release is scoped, estimated and accepted on its own, so you can pause, change direction or stop without being left with nothing usable.
What working with Promatics looks like
We start with discovery and a written recommendation, which may be to buy or integrate rather than build. If building is right, we agree the first release, deliver it in short iterations with regular demonstrations, migrate and reconcile your data, and hand over the source code, documentation and infrastructure in your organisation's accounts. Support after launch is covered by a separate agreement so you know exactly what you are paying for each year. See custom software development for the full approach.
When to bring in help
- You can describe the process, but not yet the exceptions or the data it depends on.
- The software will hold personal information or support decisions that must be auditable.
- It must connect to at least one system you do not control.
- Nobody inside the organisation will be funded to maintain it after launch.
- You have quotes you cannot compare because they assume different things.
If none of these apply and the tool is small and internal, a capable in-house developer or a low-code platform may be enough. If two or more apply, an experienced partner usually pays for itself by getting the scope and ownership right before money is spent.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- Nigeria Data Protection Commission (NDPA, GAID 2025, registration and guidance), Nigeria Data Protection Commission
- Web Content Accessibility Guidelines (WCAG) 2.2, World Wide Web Consortium (W3C)
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.