When to Build Custom Software — and When Not To

Most companies that commission custom software didn't need it.

That's a strange thing for a software development company to say. But it's true. And the companies that ignored it are the ones now spending two years in rewrites.

The build-vs-buy decision isn't technical. It's strategic. Most technical founders get it wrong for the same reason: they confuse what they want to build with what they need to build.

Is this a differentiating capability, or commodity infrastructure?

That's the question that actually matters. Everything else follows from the answer.

What Off-the-Shelf Gets Right

SaaS and packaged software exist because most business problems aren't unique. Accounting, HR, CRM, project management, email — these are solved problems. The solution isn't always perfect. But it's maintained by someone else, tested against edge cases you haven't encountered yet, and available today.

The case for buying is straightforward:

• Faster to deploy
• Lower initial cost
• Someone else handles the infrastructure, security patches, and uptime
• The product has already survived its awkward early years

Most startups underestimate how good modern SaaS tools are. The reflex to build — especially among technically-minded founders — is strong. Building is more interesting than configuring. It feels like forward motion.

It usually isn't.

If the market has already solved your problem, buying the solution is the right call. Engineering time is expensive. Spend it on what only you can build.

The Signals That Point to Custom

Custom software makes sense when one or more of these conditions are true:

The system is the product. If what you're building is your competitive differentiation — if the logic, the workflow, the user experience is the thing you're selling — you can't outsource that architecture to a packaged solution. You need to own it.

Requirements diverge too far from the generic case. SaaS tools are built for the median use case. The further your requirements sit from that median, the more time you'll spend configuring, hacking, and working around limitations. At some point, the workarounds cost more than a purpose-built system.

You need to own the full stack. Compliance, data sovereignty, security requirements, or audit obligations often demand that you control the infrastructure end to end. This is common in financial services, healthcare, legal, and government-adjacent systems. Off-the-shelf rarely satisfies these requirements cleanly.

You're building for unusual scale characteristics. Some platforms work well at a thousand users and break at a million. If your system has unusual throughput, concurrency, or volume requirements, you may need something designed specifically for those constraints.

Integration complexity is the actual problem. Sometimes the system isn't complex in itself — but it sits between five other systems that all behave differently. When integration logic becomes the product, custom middleware is often the cleanest answer.

A Three-Question Framework

Before commissioning custom software, answer these honestly:

Can you describe exactly what makes your requirements unusual? If you can't articulate what's different about your problem, you don't have a custom software problem. You have a product selection problem. Spend more time evaluating what exists before committing to a build.

What happens if this system doesn't exist in six months? If the answer is "we can't operate," it's core infrastructure — build it, and build it right. If the answer is "we lose some efficiency," it's probably a tool you can buy. Core infrastructure earns the investment. Efficiency tooling usually doesn't.

Are you prepared for the ongoing cost? Custom software is never finished. It needs to be maintained, evolved, and updated as the business changes. The build cost is the beginning. If there's no plan for what happens after go-live — who owns it, who maintains it — you're building technical debt from day one.

The South Africa Context

In South Africa, there's an additional dimension to this decision. Many startups try offshore development first. It looks cheaper. The output is often technically functional but architecturally compromised — built by teams working from tickets rather than from a shared understanding of the business problem.

The result is a system that works until the requirements change, which they always do. Then the rewrite.

Local custom development — with an engineering partner who can have the architecture conversation in real time — costs more upfront. It tends to cost significantly less over three years. The difference is that the decisions get made with full context of what the system needs to become, not just what it needs to do today.

This isn't an argument against offshore development categorically. It's an argument for understanding what you're actually buying when you choose the cheaper option.

The Hidden Cost of the Wrong Call

Getting this wrong is expensive in both directions.

Build when you should have bought: engineering cycles spent on a system that already existed. Delayed investment in what only your company could build. And you now own something that needs maintenance indefinitely. The opportunity cost is invisible until it becomes obvious.

Buy when you should have built: years of workarounds on a system that doesn't fit your problem. The team builds institutional knowledge around the workarounds. Eventually the system becomes the constraint on the company's growth, and the rewrite happens anyway — but now under pressure, with technical debt already baked in.

Thirty years of building production systems produces a consistent observation: companies that rewrite their core systems almost always built them on a wrong architectural assumption at the start. Not a wrong technology choice. A wrong decision about what the system fundamentally needed to be.

That's an architectural error. It happens at the beginning. And it's usually the result of the build-vs-buy decision being made too quickly, without the right question being asked.

Where This Leaves You

Build custom software when the problem is genuinely yours to own: when it's a differentiating capability, when your requirements are far enough from the generic case, when the integration complexity demands it.

Buy everything else.

The discipline is in being honest about which category you're in. Most founders want to build because building is what they do. The question is whether the business actually needs it.

If you're unsure which side you're on, that uncertainty is almost always a signal to keep evaluating what exists before committing to a build. The right answer is usually obvious — once you're asking the right question.