When to Build vs Buy: A Decision Framework for Businesses

Consider a scenario that plays out frequently in business. A B2B startup founder sits with their development team, facing a critical decision. They need a CRM. The off-the-shelf options start at $25 per user monthly, which would cost their 20-person team $6,000 annually. Their lead developer estimates they could build something custom for about ₦6 million.

"Building seems cheaper, and we can make it exactly what we need," they reason. "Why would we pay monthly for something that does not fit perfectly?"

However, it is not always that simple. Industry research indicates that approximately two in every three software projects fail to meet their objectives, with McKinsey reporting that 56% of large IT projects fall short of their original vision. These statistics suggest this is not merely a financial decision but one that can define a company's trajectory for years.

The hypothetical founder? Six months into development, their custom CRM is three months behind schedule, has consumed ₦15 million, and still lacks basic features that the $500/month solution offered out of the box. Meanwhile, the sales team manages leads in WhatsApp and Excel, waiting for the "perfect" solution that may never arrive.

Why This Decision Matters More in Nigeria (and Africa)

Before we dive into the framework, it is worth understanding why this decision carries particular weight in the African business context.

Capital Efficiency is Critical

Nigerian businesses typically operate with less access to capital than their counterparts in more developed markets. Whether you are a startup stretching seed funding or an established company managing cash flow carefully, how you deploy technology investment has an outsized impact on your ability to survive and grow.

Making the wrong choice does not just mean wasted money. It can mean the difference between reaching your next milestone and running out of runway. ₦15 million (about $10,000) feels different for African founders than their Western counterparts.

Technical Talent is Expensive and Scarce

While Nigeria has tremendous technical talent, experienced software engineers command significant salaries. Remote developers working for international companies can command even higher rates, averaging $53,658 annually.

When you choose to build, you are not just competing with other Nigerian companies for talent. You are also competing with international companies offering remote positions at dollar-denominated salaries. This makes the true cost of building higher than simple salary calculations suggest.

Infrastructure Challenges Increase Development Complexity

Nigeria's 4G internet penetration stands at about 51%, and infrastructure challenges remain significant across the country. Building software in Nigeria means accounting for unreliable power, variable internet connectivity, and the need to support users across a wide range of devices and connection speeds. These factors add development complexity that off-the-shelf solutions have often already solved.

Time to Market Can Make or Break You

In fast-moving markets like Nigeria, where competition is fierce and customer needs evolve rapidly, speed matters even more. The six months you spend building a custom solution might be six months your competitor spends capturing market share with an off-the-shelf tool.

The True Cost of Building

When companies evaluate building custom software, they typically focus on obvious costs: developer salaries, infrastructure, and project management. But the true cost of building goes far beyond these line items.

Development Costs

This is the part that is very visible. Building custom software requires direct labour costs. This includes salaries, infrastructure (tools, cloud hosting, etc.) and in some cases, setup fees for third-party services.

For a moderately complex system, you are looking at a minimum team of 3-5 people over 4-6 months. At ₦300,000 to ₦1,500,000 average monthly cost per person (depending on seniority), that is ₦5.4 million to ₦45 million before the first line of code is deployed.

Infrastructure costs include cloud hosting, development tools, testing environments, and staging servers. Depending on complexity, budget ₦100,000 to ₦500,000 monthly, even before production deployment.

Third-party services like payment gateways, SMS providers, email services, and analytics tools accumulate quickly. Even custom software relies on external services for core functionality.

"Invisible" Costs

Here is where the math gets uncomfortable. Every month spent building software can easily be a month not spent on your core business. This also means additional costs incurred. Research estimates that only about 47% of projects finish on time and 59% finish within budget, regardless of project size. This means most projects take longer and cost more than initially estimated.

Maintenance and Evolution (The Forever Cost)

Software is never really "done." It needs constant maintenance, bug fixes, security updates, and feature enhancements.

Industry practice suggests budgeting 15-30% of the original development cost annually for maintenance and updates. For example, a system that costs ₦10 million to build could require ₦1.5-3 million annually to maintain. Over five years, the maintenance cost equals or exceeds the original development cost.

The Knowledge Risk

What happens when your lead developer leaves? This is a valid concern because software engineers do not lack offers. With custom software, you inherit significant knowledge risk. Off-the-shelf software has documentation, communities, and multiple experts who understand the platform. Even when there is documentation for your custom solution, the additional knowledge that context and nuance bring is likely locked up in individual heads.

The True Cost of Buying

Buying off-the-shelf software seems straightforward. You pay the license fee, and you are done. But the real cost equation is also not that simple.

Licensing Costs (The Obvious Part)

Very obvious. However, subscription fees add up, especially when calculated over multiple years. A $20-per-user monthly fee for 20 users is $4,800 annually, or $24,000 over five years. For larger teams, this becomes substantial. Some vendors also charge based on usage, data volume, or feature tiers. As your business scales, this cost will increase.

Integration Costs

Off-the-shelf software rarely works in isolation. You will need to integrate it with your existing systems. For example, an e-commerce solution needs to interact with localised payment options, inventory management, third-party shipping and logistics, etc. These integrations usually require custom API development, middleware platforms, and ongoing maintenance.

Customisation and Configuration

Depending on the size of your organisation, the off-the-shelf solution might require substantial configuration to match your business processes. Some of these might be as simple as a learning curve for your Operations team, or it might require engineering input, where the customisation is only possible through code. This means you are essentially building on top of bought software and combining costs from both approaches.

Training and Adoption

Your team needs to learn the new system. Training time is a real cost. This includes the direct cost of training sessions and the productivity loss as people climb the learning curve.

Vendor Risk

When you buy, you are betting on the vendor's continued existence and commitment to the product. This is particularly true with international vendors who might exit Africa if the operational markets prove challenging or with local vendors who might not have sustainable business models. Security risk is also a concern. You are betting on the ability of the vendor to protect any data exposed to their ecosystem as a result of your usage.

The Decision Framework: A Systematic Approach

Considering there is no perfect route, how do you decide? Here is a framework for making this decision systematically.

Step 1: Categorise Your Need

Not all software needs are created equal. Start by categorising what you need:

Core Differentiator: Does this software create a competitive advantage? Is it central to what makes your business unique? For example, Paystack and Flutterwave had to build proprietary payment infrastructure that could handle multiple African currencies and payment methods. This was core to their value proposition.

Critical Enabler: Is this software essential for operations but not a source of competitive advantage? E.g. Email infrastructure, HR management systems, accounting software.

Productivity Tool: Does this software improve efficiency, but not mission-critical? E.g. Internal communication tools, project management software, and note-taking applications.

General Rule: Build core differentiators, buy critical enablers and productivity tools.

Step 2: Evaluate Market Solutions

Before committing to build, thoroughly evaluate what exists. If software exists that solves 70% or more of your needs, buying and adapting your processes or customising the remaining 30% is usually more cost-effective than building from scratch.

Businesses, especially when the resources are available, underestimate how much they can accomplish with off-the-shelf software and light customisation.

Local alternatives should also be considered, not out of patriotism but because local providers will typically have a better understanding of the local market needs E.g. prevalent payment methods, and infrastructure constraints. A Nigerian accounting software might natively support local payment transactions and local tax calculations that international software requires custom development to handle.

Step 3: Calculate the Five-Year Total Cost

Build a realistic five-year financial model for both options. As mentioned earlier, about 59% of projects finish within budget, so use conservative estimates.

For Building:

• Initial development
• Maintenance and bug fixes (15% - 30% of development cost annually)
• Feature enhancements
• Infrastructure and hosting
• Team retention or replacement costs
• Opportunity cost of delayed time-to-market

For Buying:

• License fees (assume annual price increases. 10% - 15% is realistic)
• Integration development
• Customisation costs
• Training and productivity loss
• Vendor support fees
• Upgrade costs

Run three scenarios: best case, expected case, and worst case.

Step 4: Assess Risk Factors

Beyond pure cost, evaluate qualitative factors:

Technical Risk: How complex is the software? Does your team have expertise in the required technologies? With a fairly high failure rate for software projects, technical risk assessment is critical.

Market Risk: How fast is your market moving? Can you afford to wait 6-12 months for a custom solution? Will customer needs change substantially during development?

Team Risk: Do you have developers who can build and maintain this long-term? What is your plan if key developers leave?

Vendor Risk (for buying): Is the vendor financially stable? Are they committed to the market you operate in? Do they have local support? How mature is the product?

Step 5: Consider Hybrid Approaches

The build-versus-buy decision is not always binary. A hybrid strategy is sometimes best:

Buy the Foundation, Build the Difference: Start with off-the-shelf software for core functionality, then build custom features on top that create a competitive advantage.

Build to Prove, Buy to Scale: Build a minimal custom solution to prove your concept and understand requirements deeply. Once proven, migrate to enterprise software that scales better. This approach reduces initial risk while preserving the option to scale efficiently.

Buy First, Build Later: Start with off-the-shelf software to move fast. Once you reach scale and have resources, build custom solutions for areas where you need a competitive advantage.

When You Should Definitely Build

Despite the costs and risks, there are situations where building is clearly the right choice:

1. True Competitive Differentiation: If the software creates a genuine competitive advantage and no market alternative comes close, build it.

2. Unique Market Position: If you are pioneering a new market or business model with requirements that no existing software addresses, you might need to build.

3. Security or Regulatory Requirements Some industries have security or compliance requirements that commercial software cannot meet. Banks, healthcare providers, and government contractors might need custom solutions that meet specific regulatory frameworks.

4. You Have Technical DNA: If you are a technology company with strong engineering capability and software development is core to what you do, building makes more sense, especially when there is a strong market use case.

When You Should Definitely Buy

On the flip side, some situations make buying the obvious choice:

1. Commodity Functionality: If the functionality you need is standard across industries, buy it. Email, accounting, HR management, and document storage have all been solved. Do not reinvent them (unless you have a radical idea to execute)

2. Speed is Essential: If time-to-market is critical and waiting 6-12 months for custom development means losing market opportunity, buy something and start immediately.

3. Limited Technical Resources: If you do not have strong technical capability in-house and software is not your core business, buying makes more sense than attempting to build. You will waste time and will likely abandon the project in the future

4. Unclear Requirements: If you are not entirely sure what you need, buying lets you experiment cheaply. You can learn what works, what does not, and what features you actually need before committing to expensive custom development.

Red Flags That You Are Making the Wrong Decision

Watch for these warning signs that emotion rather than logic is driving your decision:

Red Flags for Building:

• "We can build it cheaper than buying". This is usually inaccurate, especially as the use case becomes more complex.
• "We want full control". Do you really need full control? If it is about data, global data policies usually mandate that you own your data anyway.
• "Our needs are unique". Your needs may not be as unique. Do not confuse the need for software extension with a complete lack of fit.
• "It will only take 2-3 months" Again, this is likely inaccurate. If you are not a technology company with in-house expertise on the problem area, you are likely way off with your estimates.

Red Flags for Buying:

• "Everyone uses this software" Your context might be different.
• "The vendor promises it does everything" The sales representative's primary concern is closing the deal. They may admit that the software is not the perfect fit, but it might be less perfect than they are describing. Verify independently.
• "We can customise it easily" Customisation can easily become building. You should not need to build entire modules as "customisation".
• "The contract seems reasonable" Read the fine print on lock-in and price increases. If you are buying to build later, you do not want to keep paying when you are ready to move on.
• "We will figure out integration later". Be clear on what needs to happen in terms of integration and plan for it in advance. You might find that your vendor has no APIs to integrate with.

The Wisdom of Iteration

Here is a final perspective that will serve you well: the best decision is the one that lets you learn as quickly as possible.

Whether you build or buy, prioritise learning over perfection. Buy something to understand the evolution of your needs. Build a minimal prototype to test assumptions. Do not commit to massive costs before you understand what actually creates value for your business.

Moving Forward

Not every aspect of your business will have the same decision. The build-versus-buy decision will be a recurring point over the lifetime of the business. Each time, run through this framework systematically. Do not rely on gut feeling or assumptions, even those based on what worked the last time you assessed. Every situation has unique factors that will require consideration.

The goal is not to make the perfect decision. The goal is to make a sound decision based on evidence and clear thinking, then execute it well.

Whether you decide to build custom software, buy off-the-shelf solutions, or pursue a hybrid approach, let data and systematic analysis guide your decision rather than emotion or intuition.