Build vs Buy Business Software in Nigeria: The Financial Case

The build-versus-buy conversation usually gets stuck on features. That is the wrong axis. Two products can both do the job; what separates them over three years is how the cost behaves as you grow, who carries the currency risk, and whether the software is a running expense or an asset on your books.

This article is deliberately financial. It gives you the cost lines for each route, the break-even maths, the strategic factors that money alone does not capture, and a scoring sheet to settle the decision. If you want the product-level comparison of custom versus off-the-shelf features, that is a separate question; this one is about where the money goes.

What build and buy actually mean

"Buy" means licensing software somebody else owns and maintains — typically a cloud subscription priced per user per month, sometimes per transaction or per branch. You get the product's roadmap, its limits and its price changes.

"Build" means commissioning software written for your process, which you own. You get exactly what you specify, and you also inherit the responsibility for maintaining, securing and improving it.

Between them sits a third option that is often the correct one: buy a platform and configure it heavily, or buy for standard functions while building only the part of your operation that is genuinely different. Most Nigerian businesses that describe themselves as "building" are in fact doing this.

The financially important distinction is this: buying converts software into an operating expense that scales with headcount and the exchange rate. Building converts it into a capital-style investment that is largely fixed once complete. Which of those your business prefers depends on your growth plan and your cash position, not on ideology.

The cost lines you must include on both sides

Most comparisons fail because one side is costed properly and the other is not. Use the same lines for both.

The two lines businesses most often forget are internal time during implementation and the cost of change requests. Both are real, and both land in the first eighteen months.

Three-year total cost of ownership: a worked comparison

The table below compares a mid-sized operational system — think order management, dispatch or a customer-service platform — for a business with 25 users. All figures are indicative 2026 ranges; actual costs vary with scope, vendor, user count and exchange rate.

Indicative 2026 ranges; confirm subscription prices directly with vendors and obtain two or three written development quotations on identical scope.

Now run the same comparison for a five-user business on the same SaaS product, and the picture inverts: three years of subscription might total ₦2,400,000–₦3,500,000, against a build that still costs several million naira upfront. At that size, buying is almost always correct.

This is the whole argument in one sentence: per-user pricing is cheap when you are small and expensive when you are not, while custom software is expensive when you are small and comparatively cheap when you are not.

The break-even question: when does building pay back?

Build-versus-buy break-even is the point at which cumulative subscription cost exceeds the build cost plus its maintenance. You can estimate it in four steps.

1. Calculate annual buy cost. Users multiplied by price per user per month multiplied by 12, converted to naira at a conservative rate, plus any transaction fees.
2. Calculate annual build cost. Build cost divided across your expected useful life, plus hosting, plus maintenance at 15–25% of build cost.
3. Project both over five years, increasing the buy side for headcount growth and a sensible allowance for renewal increases and naira weakening.
4. Find the crossover year. If it falls beyond year four or five, building rarely makes financial sense, because technology and business needs change too much over that horizon.

A practical rule of thumb for Nigerian SMEs: if your annual subscription bill for one system passes roughly ₦8,000,000–₦12,000,000, a serious build analysis is warranted. Below that, the management overhead of owning software usually outweighs the saving.

Two adjustments matter. First, do not compare a ₦15,000,000 build to a subscription and assume equivalence — a custom build must be scoped down to the same functionality actually used, which is often a fraction of the SaaS product. Second, apply a discount for risk: software projects overrun, and an honest comparison adds a contingency of 15–25% to the build side.

Strategic factors the spreadsheet does not capture

Four considerations can override the arithmetic in either direction.

• Is the process a source of competitive advantage? If your pricing model, dispatch logic or credit assessment is what makes you better than competitors, encoding it in software you own is defensible. If it is payroll, buy it.
• Speed to value. A bought system can be live in weeks. A build takes months. If the business problem is bleeding money now, a bought stopgap that you replace later can be the financially correct answer even if the three-year total is higher.
• Internal capacity. Owning software means owning decisions: prioritising changes, approving releases, managing a developer relationship. A business with no one willing to hold that responsibility will get poor value from a build regardless of cost.
• Data leverage. Software you own gives you unconstrained access to your own operational data for analytics, credit applications and integrations. Some bought platforms make routine data access surprisingly difficult.

A build-versus-buy scoring framework

Use this sheet after you have both cost models. Score each row 1–5 for each option, multiply by the weight, and compare totals. It will not make the decision for you, but it will show you which factor is actually driving it.

If buying wins on TCO but building wins on competitive importance and integration depth, the answer is usually the hybrid route below.

The hybrid route most Nigerian SMEs actually take

In practice, very few growing Nigerian businesses build everything or buy everything. The pattern that works looks like this:

1. Buy the commodity layers. Accounting, payroll, email, storage, project management and support desks are solved problems. Paying for them is cheaper than owning them.
2. Build the differentiating layer. The order flow, pricing engine, dispatch logic, agent network or customer portal that your competitors do not have.
3. Integrate the two. Your custom system pushes invoices into the accounting package and pulls payment confirmations from your gateway, so nobody re-keys anything.
4. Review annually. When a bought tool's cost outgrows its value, or your build's scope creeps into commodity territory, move the boundary.

This keeps the naira outlay proportionate and concentrates custom development where it actually produces a return.

What changes for Nigerian businesses

Four local conditions shift the balance compared with the same decision in a stronger-currency market.

• Foreign-exchange exposure runs one way. Most global SaaS is priced in US dollars while your revenue is in naira. A subscription that was affordable at one exchange rate can become a serious cost line at another, with no change in the value received. Custom software built and maintained locally is largely a naira cost, with only hosting and third-party services exposed.
• Local development rates make building more accessible. Nigerian development costs are lower than equivalent work in Europe or North America, which lowers the break-even user count compared with the same calculation made abroad.
• Support and fit. Local vendors can be on site, understand bank transfer reconciliation, WhatsApp-led workflows and NDPA 2023 expectations, and can respond within your working day.
• Vendor and continuity risk cuts both ways. A global SaaS provider is unlikely to disappear but may deprioritise a market your size. A small local developer may be highly responsive but represents concentration risk — which is why source-code ownership, documentation and a code repository under your own account are non-negotiable contract terms.

On the compliance side, note that if either route processes personal data you remain the data controller under the Nigeria Data Protection Act 2023. Verify your obligations with the Nigeria Data Protection Commission rather than relying on a vendor's assurances, and treat this article as commercial guidance rather than legal advice.

Example (hypothetical): a Nigerian distributor runs the numbers

Example (hypothetical): an FMCG distributor in Onitsha with 18 sales agents, four depots and about 900 retail customers is choosing between an international distribution SaaS product and a custom order-and-stock system.

Their analysis:

• Buy side. The SaaS product is priced per user per month in USD. With 18 agents plus 7 office staff, the indicative annual cost lands in the ₦10,000,000–₦14,000,000 range at the exchange rate they used, before implementation of roughly ₦2,500,000. It handles stock and orders well but cannot model their credit terms, which vary by customer and by product line, so agents would still maintain a side spreadsheet.
• Build side. Two quotations for a custom system covering agent ordering, depot stock, credit rules and an accounting integration came in around ₦11,000,000 and ₦14,500,000, with maintenance quoted at 18% a year and hosting near ₦600,000 a year.
• Break-even. Cumulative buy cost passed cumulative build cost during year two, and the gap widened as they planned to add agents.
• Deciding factor. It was not the money alone. The credit-terms logic was the thing their competitors did badly and they did well, and the SaaS route left it in spreadsheets.

Their decision was to build the order, stock and credit system, keep their existing accounting package, and integrate the two. They added a 20% contingency to the build budget and wrote source-code ownership and repository access into the contract. This is an illustrative scenario, not a client account.

Mistakes that ruin a build-versus-buy decision

• Comparing a build to a subscription over one year. One year always favours buying. Three to five years is the honest horizon.
• Costing the build and not the buy. Implementation, training, connectors and internal time apply to bought software too.
• Ignoring FX on the buy side. Convert USD subscriptions at a conservative rate and model what happens if the naira weakens further.
• Scoping the build against the SaaS feature list. Build only what you use. The bought product's long feature list is not your requirement.
• No contingency on the build side. Add 15–25%. Projects overrun; pretending otherwise makes the comparison dishonest.
• Building a commodity. Nobody has ever gained an advantage from custom payroll software.
• Forgetting who owns the code. A build you do not own is the worst of both routes: capital outlay with vendor lock-in.
• Deciding without an internal owner. Custom software with no accountable owner degrades within a year.

Conclusion

Treat build versus buy as a financial and strategic question, not a technical one. Cost both routes over three years using the same lines, convert USD subscriptions at a conservative rate, add contingency to the build, and find the crossover year. Then apply judgement: buy the commodity layers, build only what makes you difficult to replace, and integrate the two so nobody re-keys data. Most Nigerian SMEs will find that the right answer is not "build" or "buy" but a deliberate boundary between the two, reviewed every year as the business grows.

If you are weighing a build against a subscription and want the numbers laid out honestly, Linestech can scope a custom system, produce a comparable cost model, and tell you plainly when buying is the better decision for your stage.

Frequently asked questions

Is custom software always more expensive than SaaS?

No. It is more expensive upfront and usually cheaper per user at scale, because subscription cost grows with headcount while a built system's cost is mostly fixed after launch. For a five-person team a subscription is almost always cheaper; for a 40-person operation paying per seat in US dollars, the arithmetic often reverses within two to three years.

How do I account for custom software financially?

Custom development is generally treated as an investment in an asset rather than a pure running expense, while subscriptions are an operating cost. The treatment affects your accounts and possibly your tax position, so confirm the correct approach for your business with your accountant and with reference to current FIRS guidance rather than assuming.

What if I build and the developer disappears?

This risk is managed contractually and technically, not by luck. Own the code repository under your own account from day one, require written documentation and handover notes, insist on standard frameworks rather than a developer's private toolkit, and keep your hosting and domain accounts in the business's name. Any competent replacement developer can then take over.

Can I start by buying and build later?

Yes, and it is often the smartest sequence. Buying gets you working quickly and teaches you what your requirements actually are, which makes any later build far more accurate and usually cheaper. The condition is that you must be able to export your data cleanly, so check export terms before you subscribe.

How long does building business software take?

For a focused operational system, three to six months from discovery to a usable first release is typical, with enhancements continuing after that. Larger platforms with multiple user roles and integrations take longer. If a vendor promises a full multi-module system in four weeks, ask exactly what is being deferred to "phase two".

Does building make sense for a business with fewer than ten staff?

Rarely for a general business system, but sometimes for a specific revenue-generating product. A ten-person company should usually buy its internal tools and reserve custom development for the thing customers pay for — a booking platform, a customer portal or the application that is the business itself.

How do I keep a build from overrunning its budget?

Fix the scope of the first release tightly, agree a written specification and acceptance criteria, pay in milestones tied to working software rather than to time, keep a change log where every new request is priced before it is approved, and hold a 15–25% contingency outside the headline budget. Overruns are usually scope changes, not technical surprises.

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)
• Cloudflare Learning Center
• GitHub documentation