When Should a Nigerian Business Build Custom Software?

Timing matters more than the decision itself. The same project that wastes ₦6,000,000 in year two of a business can save ₦6,000,000 a year in year five, because by then the process is settled, the volume is real and the cost of doing it manually is visible.

This article is about when, not whether. If you are still comparing the two routes in principle, our comparison of custom software versus off-the-shelf software covers that ground. Here we look at the signals that say now, the signals that say wait, and how to tell the difference honestly.

The three conditions that must all be true

Custom software is justified when fit, stability and capacity all line up. Treat them as gates rather than factors to be traded off.

1. Fit. A ready-made product genuinely cannot do the job. Not "we would prefer it differently", but a demonstrated wall: you tried to configure it, or a vendor demonstrated their product against your real scenarios and two of them required a spreadsheet, an export or a promise about a future release.

2. Stability. The process you want to encode has been done the same way for at least two or three quarters. Software is expensive to change, so building around a process still in flux means paying twice.

3. Capacity. You can fund the build, fund maintenance at roughly 15–25% of build cost per year, and name one internal person with authority to make decisions and time to test. Projects fail more often for lack of an owner than for lack of money.

If fit is missing, you are buying preference, not need. If stability is missing, wait. If capacity is missing, the software will be delivered and then rot.

Eight signals that it is time to build

These are the patterns that most reliably indicate a build will pay back. One alone is rarely enough; three together usually are.

1. A spreadsheet runs alongside your software. Staff export from the product, manipulate it in Excel, then act on the spreadsheet. That spreadsheet is a specification for the system you actually need.
2. The same data is typed more than once. An order typed into WhatsApp, a delivery note, then an invoice, then the accounts package. Re-keying is the cheapest thing custom software removes.
3. Your rules cannot be expressed in the product. Customer-specific pricing tiers, credit limits by relationship, discounts that depend on volume history, commission split across a team — these routinely defeat standard products.
4. Per-user subscription costs have outgrown the benefit. As staff numbers climb, a USD-priced product becomes a significant naira line that grows with the exchange rate while the value stays flat.
5. You cannot get the report that matters. If the number your board asks for every month is assembled by hand from three sources, the systems are not serving the business.
6. Field staff cannot work in the system. Warehouses, delivery routes and site visits often need offline capability, which off-the-shelf products rarely offer.
7. Growth is blocked by manual work. You can only take as many orders as one person can process, and the fix is another salary rather than another customer.
8. The process is how you compete. If your delivery reliability, credit management or turnaround time is the reason customers stay, encoding it well is a commercial investment, not an IT expense.

Five signals that you should wait

Equally important, and less often discussed.

1. Your process changes every quarter. Young businesses should keep flexibility cheap. Configurable products absorb change; custom code charges for it.
2. You have not tried to configure a product properly. Many "impossible" requirements are settings nobody explored. Run a real trial with your own data before concluding.
3. The pain is training, not software. If two staff use the product well and five do not, you have an adoption problem that a new system will reproduce.
4. Nobody internally will own it. Without a decision-maker who tests, approves and champions the system, delivery drags and adoption fails.
5. The budget covers the build but not the year after. Software without maintenance becomes a risk: unpatched, unsupported, and increasingly avoided by staff.

There is also a simple financial test. If the manual work you want to remove costs less per year than the maintenance alone, build later and fix the process now.

Readiness check before you commission anything

Work through this before you approach a developer. Each unticked item is either work to do first or a risk to manage explicitly.

• The process has been written down as it actually happens, including exceptions.
• At least one ready-made product has been trialled with real data, and the specific gaps are documented.
• The manual cost of the current approach has been estimated in hours per week.
• The process has been stable for two or three quarters.
• One internal owner is named, with authority and available time.
• A budget exists for the build, for year-one hosting and for maintenance.
• Existing data has been reviewed for quality, duplicates and gaps.
• The systems it must connect to have been identified, with confirmation that each has an API or export route.
• Success has been defined in measurable terms: hours saved, errors reduced, days sales outstanding cut.
• Contract expectations are clear: code ownership, documentation, handover, support.
• A phase-one scope exists that delivers value on its own.
• Staff who will use it have been consulted, not just informed.

If you can tick nine or more, you are ready. Six to eight means fix the gaps first; below six, buy a product and revisit.

Timing by stage of business

Custom software rarely makes sense at every stage. This is a guide, not a rule: a two-person startup whose product is software is a different case entirely.

The pattern worth noticing is that the trigger is usually capacity, not size. The moment the business cannot grow without adding administrative headcount is the moment a build starts paying back.

What changes for Nigerian businesses

Budget realism and phasing

Naira budgets for software compete with generators, stock and rent. That argues for phasing: build the module that removes the largest manual cost first, prove it, then fund the next phase. A ₦9,000,000 project delivered in three phases is approvable in a way that the same project quoted as one number often is not.

Exchange-rate pressure on subscriptions

Because many products are USD-priced, the economics of building shift each time the naira weakens. A subscription that was comfortable two years ago may now justify ownership. Recalculate rather than relying on an old comparison.

Founder and key-person dependency

In many Nigerian SMEs the process lives in the owner's head, and approvals route through one phone. Custom software forces those rules to be written down, which is valuable in itself but also means the owner must be available during discovery. Build when the owner has the bandwidth to be interviewed and to make decisions.

Statutory and compliance changes

VAT presentation, tax reforms effective from 2026, pension schedules and data protection obligations under the Nigeria Data Protection Act 2023 all change over time. Custom software means you carry the cost of keeping up. Confirm current requirements with FIRS, PenCom, the Nigeria Data Protection Commission or a qualified adviser, and budget for updates.

Infrastructure reality

Power and connectivity affect design decisions: offline capability, lightweight interfaces, data efficiency for staff on mobile data. These are legitimate reasons to build rather than buy, and they should be stated as requirements rather than discovered after launch.

Access to developers

Nigeria has a deep pool of developers, which is an advantage, but continuity is the risk to manage. Insist on a repository you own, documentation and a support agreement so the system can be handed to another team if needed.

What to build first when the answer is yes

Start where the business bleeds time, not where the idea is most exciting.

1. Map the workflow end to end, including every handover between people and every exception.
2. Quantify the cost of the current approach: hours per week, error rate, delayed collections, lost orders.
3. Choose the narrowest phase one that delivers standalone value. Stock control before purchasing. Order capture before analytics. One branch before all branches.
4. Decide the integrations that matter now and defer the rest. Accounting export in phase one, full two-way sync later.
5. Write acceptance criteria in business language: "a field rep can capture an order with no signal and it appears in the office within five minutes of reconnecting".
6. Commission a paid discovery phase. A documented scope, data model and screen design makes a fixed price meaningful and is portable if you change developer.
7. Plan the data migration early, including who cleans the existing records.
8. Agree maintenance before launch, not afterwards.

Example (hypothetical): a Port Harcourt equipment servicing firm

Example (hypothetical): a company servicing industrial generators and compressors across Rivers and Bayelsa has 30 staff, including 16 field engineers. Jobs come by phone and WhatsApp, are scheduled on a whiteboard, and job sheets are completed on paper and returned to the office days later. Invoicing waits for the paperwork, so collections lag by weeks.

Assessing the three conditions:

• Fit: the firm trialled two field-service products. Both handled scheduling but neither could model its maintenance contracts, where a customer pays an annual fee covering four visits plus parts at a discount. The contract logic is central to its revenue.
• Stability: the contract structure has been unchanged for three years.
• Capacity: the operations manager can own the project, and the firm can fund a phased build plus maintenance.

All three are met, so the answer is build — but narrowly. Phase one is a mobile job sheet with offline capture and photo evidence, plus a scheduling board, indicatively ₦2,500,000–₦4,500,000. Phase two adds contract management and automatic invoicing from completed jobs, indicatively ₦2,500,000–₦4,000,000. The firm keeps its accounting product and integrates.

Had the contract logic been absent, the right answer would have been to buy a field-service product and accept its scheduling model. Figures are illustrative, not a quotation.

The cost of building too early and too late

Too early costs money in obvious ways: rework when the process changes, features nobody uses, and a maintenance bill for software that no longer matches the business. It also has a hidden cost — management attention diverted from customers during the period when attention is the scarcest resource.

Too late is quieter and often larger. Symptoms include administrative headcount added purely to move data between systems, orders lost because nobody could confirm stock, collections delayed because invoices follow paperwork, decisions made on numbers that are three weeks old, and staff who have stopped reporting problems because "that's just how the system is".

A practical way to judge: estimate the weekly hours spent on manual movement of data, multiply by a blended staff cost, and compare the annual figure with the build plus first-year maintenance. If manual cost exceeds the annual cost of ownership, you are already late.

Mistakes to avoid

• Building because a competitor did. Their process and constraints are not yours. Score your own situation.
• Skipping the product trial. Without a documented gap, you cannot brief a developer properly, and you may pay to rebuild something you could have configured.
• Scoping the whole business at once. Multi-module platforms attempted in one phase are the most common source of stalled projects.
• Letting the developer define success. Acceptance criteria should come from the business and be written in business terms.
• No maintenance budget. Unmaintained custom software becomes the next legacy problem within two years.
• Ignoring the people who will use it. Field staff and clerks know the exceptions. Excluding them guarantees a system that fails in week three.
• Treating discovery as a cost to avoid. Poor requirements are the most expensive thing in software, and discovery is the cheapest way to fix them.
• No exit plan. Without code ownership, documentation and credentials, you have rented something you believe you own.

Conclusion

Build when fit, stability and capacity are all present: a product genuinely cannot handle a process central to your operation, the process has held steady for several quarters, and you can fund maintenance and name an owner. Until then, configure a product, remove the worst manual steps with small automations, and keep a log of every workaround your team invents — that log is your future specification. When you do build, start with the narrowest phase that stands on its own, agree ownership and maintenance in writing, and measure the result in hours saved and errors removed.

If you are trying to judge whether your situation justifies a build yet, Linestech can review your current process, the gaps in the products you have tried, and what a phased first build would realistically involve.

Frequently asked questions

How do I know whether a product really cannot do what we need?

Run a structured trial. Write your five most common scenarios and your three most awkward ones, load real data, and ask the vendor to demonstrate each. Record which require a workaround, an export or a future release. If the awkward scenarios all fail and they are central to your revenue, the gap is real. If they fail on preferences rather than requirements, it is not.

What is the minimum sensible budget for a first custom build?

For a focused single-workflow tool, indicatively ₦1,500,000–₦3,500,000 plus hosting and maintenance. Below that, scope is usually too thin to justify the process of specification, testing and handover, and you are often better served by configuring an existing product or by a small automation project.

Should we build custom software before we have a website?

Rarely. A website is how customers find and trust you; internal software is how you operate. If both are missing, the website usually generates returns sooner. The exception is a business whose operational chaos is actively losing existing customers, where fixing operations comes first.

Can we build custom software with a freelancer instead of an agency?

For a narrow tool, yes, provided you own the repository, receive documentation and have a written support arrangement. The risk is single-person dependency: illness, travel or a new job can stall your system. For anything the business depends on daily, a team with testing and continuity is usually worth the higher price.

How long should we use off-the-shelf software before deciding?

Long enough for the process to stabilise and for the gaps to be documented — typically two to three quarters of real use. Keep a running log of every workaround, export and spreadsheet your team creates. That log, not a feeling, is the evidence that decides the question.

What if we build and the business changes direction?

Phase the work so that no single phase represents more than you can absorb, and prefer configurable design where change is likely. Well-built systems can be extended; the loss when direction changes is usually a portion of the investment rather than all of it. This risk is also the strongest argument for not building until the process is settled.

Does custom software require an in-house IT team?

Not usually. Most Nigerian SMEs run custom systems with a support agreement from the developer and one internal owner who handles user administration and gathers change requests. An in-house team becomes worthwhile when you are running several custom systems or when uptime is business-critical.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• GitHub documentation
• WhatsApp Business Platform — Meta for Developers