“How much does custom software cost in Nigeria?” sounds like a pricing question.
In practice it is a scope question.
A dashboard that lets five staff approve expenses is custom software. A property platform with owners, managers, tenants, payments, documents, permissions and reports is also custom software.
Both may be called “a web app.” They are not the same project.
For 2026 planning, I would use these bands:
| Scope | Planning budget | Typical shape |
|---|---|---|
| Focused internal tool / workflow | ₦1.5m–₦4m | One team, a few roles, one core process |
| Serious business system | ₦4m–₦10m | Multiple workflows, roles, reports, integrations |
| Multi-module operational platform | ₦10m–₦30m+ | Several departments, complex rules, migration, auditability |
| Regulated / enterprise platform | Scope individually | Higher assurance, security, compliance and integration burden |
These are planning ranges, not an industry tariff.
The useful number only becomes visible when the business process is understood.
What are you actually paying for?
The interface is only the visible layer.
A serious business system usually contains:
- a data model;
- business rules;
- permissions;
- workflows;
- integrations;
- reports;
- exception handling;
- deployment and operational tooling.
That is why screen-count pricing can be misleading.
Ten simple screens can be easier than one payment reconciliation workflow.
The biggest cost driver is usually business behaviour
Imagine a rent-management system.
A basic brief might say:
Add properties, tenants and payments.
Discovery quickly exposes the real product:
- Can one owner have several properties?
- Can a manager see only selected properties?
- Can an owner revoke that access later?
- What happens when a tenant pays partially?
- Can a confirmed payment be edited, or only reversed?
- Does an old tenancy remain in history?
- Who can issue or reissue a receipt?
Each answer becomes logic that has to be designed, implemented and tested.
This is the same reason a focused MVP can be cheaper than a “simple” product with unclear rules.
Roles and permissions add architecture
“Add login” is not a complete security requirement.
Authentication answers:
Who are you?
Authorization answers:
What are you allowed to see and change?
For applications built on platforms such as Supabase, database-level Row Level Security can enforce granular access rules close to the data. Supabase currently recommends enabling RLS on exposed tables and applying least-privilege grants. See Supabase RLS documentation.
The stack can vary. The principle does not:
permissions should be enforced by the system, not just hidden in the interface.
Integrations change the estimate quickly
Custom software often has to communicate with:
- payment gateways;
- accounting tools;
- email/SMS providers;
- identity services;
- HR systems;
- maps;
- cloud storage;
- legacy databases;
- AI APIs.
The difficult part is rarely displaying a button.
It is handling:
- timeouts;
- failed requests;
- retries;
- duplicated events;
- partial success;
- reconciliation;
- provider outages.
If payments are involved, see my payment gateway integration cost guide for the difference between adding checkout and building reliable payment state.
Existing data can become its own project
A company replacing spreadsheets or an old system may need to migrate years of records.
That can involve:
- duplicate customers;
- inconsistent names;
- broken dates;
- missing IDs;
- historical balances;
- abandoned fields;
- manual corrections.
Migration should be designed and tested, not treated as “upload the Excel file.”
Security and privacy need budget before launch
If the system stores customer, employee, tenant, student, patient or financial information, privacy becomes part of architecture.
Nigeria’s data-protection framework is overseen by the Nigeria Data Protection Commission.
For technical assurance, the OWASP Application Security Verification Standard provides a useful framework for testing web-application security controls.
A serious project should define:
- what data is collected;
- who can access it;
- how secrets are stored;
- how actions are logged;
- how accounts are revoked;
- backup and recovery expectations;
- what happens when staff roles change.
Security is cheaper when it is part of the model.
What should ₦1.5m–₦4m buy?
This band makes sense when the problem is focused.
Examples:
- an approval workflow;
- a reporting dashboard;
- a controlled internal operations tool;
- a simple customer portal;
- a digital replacement for one complex spreadsheet process.
It should not secretly contain ten products.
A good first release may have few screens but one complete workflow from start to finish.
What changes around ₦4m–₦10m?
The application usually starts behaving like an operating system for part of the business.
You may now have:
- several roles;
- dashboards by user type;
- notifications;
- documents;
- reports;
- integrations;
- audit history;
- payments;
- admin tools;
- data migration.
At this point, business analysis is as important as coding speed.
Why larger platforms move beyond ₦10m
Complexity compounds when requirements interact.
A multi-branch system with permissions, money, external integrations and years of history is not just a longer version of the first prototype.
The cost now includes confidence: the ability to change the system without guessing what will break.
Should you build custom software at all?
Sometimes the best answer is no.
Buy or configure an existing product when it already solves 80–90% of the workflow and the remaining gaps are tolerable.
Custom becomes more interesting when:
- the workflow is genuinely different;
- staff spend meaningful time fighting existing tools;
- several disconnected systems need to behave like one process;
- per-user economics become painful at scale;
- ownership/control matters;
- the workflow itself creates competitive advantage.
How I would prepare for a serious quote
Write down seven things:
Users
Who uses the system?
Jobs
What must each user accomplish?
Permissions
What can each user see, create, approve, edit or reverse?
Data
What information exists today and where?
Integrations
What outside systems must connect?
Exceptions
What happens when the normal process goes wrong?
Success
What measurable operational improvement makes the project worth paying for?
You do not need to write a technical architecture first.
A good discovery process should turn those business facts into architecture.
Compare proposals by responsibility, not only price
A useful custom-software proposal should explain:
- what is in scope;
- what is excluded;
- assumptions;
- delivery phases;
- testing;
- deployment;
- data migration;
- security responsibility;
- source/account ownership;
- support after launch;
- how changes are handled.
A ₦3m quote and a ₦9m quote may be describing entirely different levels of responsibility.
Build the smallest system that removes the real bottleneck
The cheapest responsible route is usually not “hire the cheapest developer.”
It is reduce the first scope without cutting trust.
Automate the bottleneck first. Keep secondary work manual while you learn. Put real users through the workflow. Then let evidence decide what deserves more investment.
If your business is running an important process through spreadsheets, WhatsApp, email and repeated manual reconciliation, send me the current workflow and what you want the software to replace. I can help turn it into a buildable first scope before development starts.
