When Should You Build Custom Software?

Custom software is a commitment, not a purchase. You are taking on the cost of building it, the cost of keeping it running, and the responsibility for every decision the vendor would otherwise have made for you. That is worth it in a narrow set of circumstances and expensive in all the others.

This is a justification test rather than a list of symptoms. It sets out the five conditions that have to be true together, the arithmetic that tells you whether the build clears its own cost, the cheaper options worth exhausting first, and how the answer changes for a Nigerian business dealing with naira-denominated budgets and USD-priced alternatives. When Should a Nigerian Business Build Custom Software?he operations side; this one is about the buying decision.

What counts as custom software

Custom software is a system built specifically for your business processes, owned by you, and changeable on your instruction. In practice Nigerian businesses commission four broad types:

• Internal operations systems — order management, dispatch, inventory, production planning, field operations.
• Customer-facing platforms — portals, booking systems, application systems, self-service accounts.
• Business management systems — CRM, workflow, approvals, reporting, often replacing a tangle of spreadsheets.
• Product software — the thing you sell, where the software is the business.

It is worth separating custom software from two neighbours that get confused with it. A configured product is an existing tool such as a CRM or accounting package set up for your workflow — that is buying, not building, even when the configuration is substantial. A custom website is a marketing or sales asset; Website vs Software: What Does Your Business Need?ts with different economics.

The distinction matters because the decision is rarely "custom or nothing". It is nearly always "custom, or configure something that exists, or change the process".

The five conditions that justify a build

Building is justified when all five of these are true. Four out of five usually means you should configure an existing product instead.

1. The process is a genuine differentiator or a genuine constraint. Either the way you do this thing is part of why customers choose you, or the current way of doing it is actively limiting growth. Processes that are neither — payroll, basic accounting, email — should be bought, not built.

2. No existing product fits without distorting the business. You have actually looked. Not "we assume nothing exists", but a real shortlist of three products, trialled, with the specific gaps written down. If the only way to use an existing tool is to change how you serve customers, that is a real gap.

3. The volume and stability justify the engineering. High transaction volume, repeated daily, with rules that will still be broadly the same in two years. Low-volume or fast-changing processes do not repay a build.

4. The pain is measurable in naira. Hours lost, orders mishandled, stock written off, revenue uncaptured, penalties incurred. If you cannot put a monthly number on it, you are not ready to spend millions fixing it.

5. You can fund the whole life, not just the build. A custom system needs maintenance at roughly 15–25% of build cost per year, hosting, and someone internally responsible for it. A business that can afford the build but not the upkeep ends up with an unsupported system and no vendor relationship.

There is a common sixth argument — "the subscription costs are getting expensive" — which is weaker than it looks. Per-user SaaS fees in US dollars do add up, and at a certain headcount the arithmetic genuinely turns. But a build only beats a subscription once you include maintenance, hosting and the cost of the features the product gives you free.

The arithmetic: what level of pain justifies what budget

Treat a custom build like any other capital decision: what does it cost, and what does it release?

Step 1 — quantify the annual pain. Add up, for the process in question: staff hours consumed × fully loaded hourly cost; errors per month × average cost per error; revenue lost to delay or capacity limits; and current tool subscriptions you would retire.

Step 2 — quantify the all-in first-year cost. Build price, plus data migration, plus hosting, plus maintenance at 15–25%, plus internal time for specification, testing and training. In practice, first-year total is commonly 1.3–1.6 times the build quotation.

Step 3 — compare, conservatively. A defensible build releases enough value to pay for itself within about 18–30 months, allowing for the fact that it will not remove 100% of the pain.

Indicative planning guidance for 2026, not fixed rules. Build costs in Nigeria run indicatively ₦1,500,000–₦10,000,000+ for a custom web application and ₦2,000,000–₦30,000,000+ for a custom CRM or business management platform, varying with modules, integrations and vendor. Business Software Development Cost in NigeriaDevelopment in Nigeria go deeper on the cost side.

The critical discipline is conservatism on the benefit side. Assume the system removes 60–70% of the pain, not all of it, and that adoption takes three to six months.

Cheaper options to exhaust first

Before committing to a build, work through this ladder. Each rung is cheaper, faster and lower-risk than the one below it.

1. Change the process. A surprising share of "we need software" problems are sequencing or ownership problems. Removing an approval step or assigning one person to a queue costs nothing.
2. Use what you already pay for. Most businesses use a fraction of the features in the tools they subscribe to. Audit before buying more.
3. Configure an existing product properly. A well-configured CRM or inventory system, set up by someone who understands your workflow, solves most standard problems. When Should You Buy Existing Software?.
4. Integrate the tools you have. Connecting your website, payment gateway, accounting package and WhatsApp with an integration layer costs far less than replacing them. How to Connect Your Business Software.
5. Automate the workflow around existing tools. Business automation — indicatively ₦500,000–₦5,000,000 plus tool subscriptions — often delivers most of the benefit of a custom build at a fraction of the cost.
6. Build a narrow custom module. One screen, one process, connected to what you already run, rather than a whole platform.
7. Build the full custom system. The last resort, justified when the rungs above genuinely do not fit.

Most Nigerian SMEs that believe they need rung seven actually need rung three, four or five. That is not a criticism — it is the normal result of a real problem being described as a software problem.

Strong cases and weak cases for building

What changes for Nigerian businesses

The build-or-buy calculation looks different here for reasons that have nothing to do with engineering quality.

Foreign SaaS is priced in dollars; your revenue is in naira. A per-user subscription that looked affordable at one exchange rate can become a serious line item at another. This genuinely strengthens the case for owning software at scale — but only if you are honest about maintenance and hosting, which are also partly USD-linked.

Local payment, delivery and identity realities are rarely supported out of the box. Bank transfer confirmation, POS reconciliation, USSD flows, NIN or BVN handling, state-by-state delivery pricing, informal addressing in areas without reliable street numbering — these are exactly the gaps that push Nigerian businesses towards custom work. Integration with Paystack, Flutterwave, Interswitch or Moniepoint is usually straightforward; the surrounding business rules are what need building.

Offline tolerance matters. Systems used in markets, warehouses, delivery vans or clinics with unreliable power and connectivity need to work when the network drops and sync later. Most foreign products assume constant connectivity. This is a legitimate and frequently decisive reason to build.

WhatsApp is an operational channel, not a marketing extra. Nigerian businesses take orders, confirm payments and handle support on WhatsApp. Custom systems that ignore this get bypassed. Any build should plan for the WhatsApp Business Platform (API) from Meta rather than assume staff will stop using their phones.

Data protection is a design requirement. Systems holding customer names, phone numbers, financial or health data fall under the Nigeria Data Protection Act 2023. Build in a lawful basis, access controls, retention rules and an export route from the start; verify current obligations with the Nigeria Data Protection Commission (https://ndpc.gov.ng/).

Vendor continuity is a real risk. A two-person development shop that stops responding leaves you with a system nobody can change. Insist on source-code ownership, documentation and a repository under your control. Who Owns Custom Software Code?.

Example (hypothetical): a Port Harcourt logistics firm

The following is a hypothetical illustration, not a Linestech client result.

A haulage and last-mile delivery company runs 22 vehicles across Rivers, Bayelsa and Delta. Jobs arrive by phone and WhatsApp. Dispatch is managed on a whiteboard and a shared spreadsheet. Proof of delivery is a photographed waybill sent to a WhatsApp group. Invoicing is reconstructed at month-end from those photographs.

The measured pain over one quarter: two staff spend the equivalent of roughly 50 hours a month reconstructing job records; invoices are raised on average 18 days after delivery; a recurring share of jobs are invoiced at the wrong rate; and the operations manager cannot answer "where is that vehicle" without three phone calls.

What they tried first: an off-the-shelf fleet product priced per vehicle per month in US dollars. It handled tracking well but could not model their rate card — which varies by client, route, tonnage and waiting time — and had no offline proof-of-delivery capture for areas with weak signal. Two of the five conditions failed on the buy route.

What they built: a driver mobile app capturing proof of delivery offline and syncing when signal returns, a dispatch board, a rate engine encoding the client rate cards, and automatic invoice generation feeding their existing accounting package. Indicative cost ₦12,000,000 for the build, with maintenance budgeted at 20% per year and hosting at ₦600,000 per year.

Why it was justified: the rate logic was genuinely unique, the volume was high and stable, the pain was measurable, and offline capture was a hard requirement no product met. Note what they did not build: accounting, payroll and vehicle tracking hardware were all bought.

Decision framework: build, configure, or wait

Score each statement 0 (no), 1 (partly) or 2 (yes).

1. We have written down the specific gaps after trialling at least two existing products.
2. The process runs at high volume, most working days.
3. The rules will be broadly the same in two years.
4. We can state the annual cost of the current problem in naira.
5. That annual cost exceeds ₦6,000,000.
6. The way we do this is part of our competitive position, or a hard constraint on growth.
7. Existing products fail on a requirement we cannot compromise on (offline, local payments, multi-site, regulatory).
8. We can fund the build plus 25% of it again in year one.
9. A named person internally will own the system and its roadmap.
10. We can commit management time to specification, testing and training for three months.

0–8 — Do not build yet. Configure, integrate or automate. Revisit in six to twelve months.

9–14 — Build narrowly. Commission the one module that fits nothing, integrate it with what you already run, and keep the scope capped.

15–20 — A full custom build is justified. Invest properly in a requirements document, phased delivery and a maintenance agreement.

How to Create a Software Requirements Document above 9, and Build vs Buy Business Software in Nigeria.

Implementation: how to start a custom build safely

1. Document the current process end to end. Every step, every exception, every person. Vendors quote on what you describe; vague descriptions produce vague systems.
2. Write the requirements before requesting quotes. Not screen designs — outcomes, rules, volumes and constraints. This is what makes two quotations comparable.
3. Separate must-have from nice-to-have explicitly. Half of most first specifications is optional and can wait for phase two.
4. Request two or three [written quotations](/pricing/) on identical scope. Compare method, team and assumptions, not only price. Questions to Ask a Software Development Company.
5. Phase the delivery. A working first release covering the core process in 8–12 weeks beats a twelve-month build that lands all at once.
6. Agree ownership, source code and hosting in writing. Repository access from day one, not at handover.
7. Plan the data migration early. Cleaning and importing existing records is routinely underestimated and routinely delays launch.
8. Budget maintenance from the first year. Support, hosting, changes and security updates, in a written agreement. Software Maintenance Costs in Nigeria.
9. Assign an internal product owner. One person who can make decisions, answer questions within a day and drive adoption.

Mistakes that make a justified build fail anyway

• Automating a broken process. Fix or redesign the process first, then encode it. Building the current mess faster is an expensive way to keep it.
• Specifying by feature list instead of by outcome. Feature lists produce systems that do many things and solve nothing.
• Building everything at once. Scope discipline is the strongest predictor of a delivered project.
• Skipping the buy evaluation. Without a documented product comparison, you cannot defend the decision internally or to a finance team.
• No internal owner. Projects run by committee drift; projects run by the busiest director stall.
• Ignoring the people. If staff were not consulted, they will keep the spreadsheet running in parallel.
• Paying the full price upfront. Stage payments against milestones, with a portion held until acceptance.
• Leaving code, repository and hosting in the vendor's name. The most avoidable and most damaging mistake in this whole category.
• Forgetting the exit. Ask how data comes out, who else could maintain the system, and what happens if the vendor becomes unavailable.

Conclusion

Build custom software when an existing product cannot support how you actually make money, the process is high-volume and stable, the annual cost of the gap is large enough to repay the investment, and you can fund and own the system for its whole life. Those conditions apply together, not individually.

If you score below the threshold, the honest answer is to configure, integrate or automate — and to revisit the question when volume or complexity has grown. That decision saves money now and produces a far better specification later, because by then you will know exactly what the gaps are.

Trying to establish whether your situation genuinely justifies a build? Linestech works through the process, the pain arithmetic and the buy alternatives with Nigerian businesses first, and will say plainly when configuring an existing tool is the better call.

Frequently asked questions

How much does custom software cost in Nigeria?

Indicatively, a custom web application runs ₦1,500,000–₦10,000,000+, and a custom CRM or business management platform ₦2,000,000–₦30,000,000+, depending on modules, integrations and vendor. Add maintenance at 15–25% of build cost per year and hosting at ₦150,000–₦800,000+ per year. These are 2026 indicative ranges; compare two or three written quotations on identical scope.

How long does a custom software project take?

A focused first release covering one core process typically takes 8–16 weeks. A multi-module business platform commonly runs six to twelve months in phases. Timelines stretch most often because requirements were unclear, data migration was underestimated, or the client team could not review deliverables quickly enough.

Can we start with off-the-shelf software and move to custom later?

Yes, and it is often the sensible sequence. Use a product while volumes are low and the process is still changing, keep your data in an exportable form, and build once the gaps are documented and the volume justifies it. The main cost of switching later is data migration and retraining, both manageable if you avoid tools that lock your data in.

Is custom software cheaper than paying SaaS subscriptions long term?

Sometimes, at scale. Compare total cost over three to five years: subscription fees at a stressed exchange rate against build cost plus annual maintenance, hosting and internal support. Below roughly twenty users, subscriptions usually win. The stronger argument for building is capability you cannot buy, not cost avoidance.

What should we build first if the budget is limited?

Build the single process that is both highest-volume and worst-served by existing tools, and integrate it with the systems you already run. Resist starting with reporting dashboards — they are visible but rarely the constraint. A narrow first module also tells you whether the vendor can deliver before you commit the rest.

Who owns the software once it is built?

You should, and it should say so in the contract: source code, repository, documentation, design assets and hosting accounts in your business name. Some vendors retain reusable framework components, which is normal, but your business logic and data must be yours. Who Owns Custom Software Code?.

Do we need a software requirements document before approaching vendors?

For anything above about ₦3,000,000, yes. It does not need to be long — processes, rules, volumes, integrations, constraints and success criteria. Without it, quotations are not comparable and change requests become inevitable. How to Create a Software Requirements Document.

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)
• Paystack developer documentation
• Flutterwave developer documentation
• WhatsApp Business Platform — Meta for Developers
• Cloudflare Learning Center
• GitHub documentation