The answer seems straightforward in theory: if something off-the-shelf does what you need, buy it, and if nothing fits, build it. In practice however, the decision is rarely so clean. Off-the-shelf tools have limitations and often come with far more features than you'll ever use, while custom solutions have hidden costs that aren't always obvious upfront. The difference between "good enough" and "not quite right" is surprisingly hard to evaluate until you're already committed.

Most businesses get this decision wrong at least once, either building when they should have bought and creating a maintenance burden that outlasts the original problem, or buying when they should have built and forcing their operations into the shape of someone else's assumptions about how work should flow.

A clear framework won't give you a formula that spits out an answer, but it can help you think through the trade-offs in a way that reveals what you're actually choosing between.

The seduction of bespoke

Custom software has genuine appeal, and it's not hard to see why. You get exactly what you need, designed around your specific processes, with no features you'll never use and no compromises forced by someone else's product decisions. The interface reflects your terminology, your workflow, your priorities.

This appeal is strongest when you've been burned by off-the-shelf tools. You've tried three project management systems and none of them quite work. Your CRM does 80% of what you need but the missing 20% creates daily friction. The enterprise platform you're evaluating has hundreds of features, but the complexity makes simple tasks feel cumbersome and training new staff takes weeks instead of hours. The temptation to say "let's just build exactly what we need" becomes almost irresistible.

The problem is that this framing can obscure the real costs, particularly for larger systems. When you buy software, the vendor handles updates, security patches, compatibility with other systems, documentation and support, but when you build, all of that becomes your responsibility for as long as you use the system.

The maintenance burden of custom software scales with its scope and complexity. A small, focused tool that solves one specific problem might need minimal ongoing attention, but a comprehensive system that touches multiple parts of your operation is a different matter entirely, requiring sustained investment in updates, fixes and adaptation as your business evolves.

The hidden costs of building

For anything beyond a simple, narrowly-scoped tool, the initial build is usually the smallest part of the total cost, and what follows is what catches people off guard.

Maintenance. Software doesn't sit still, and neither do the systems it connects to: security vulnerabilities get discovered, dependencies need updating, and users find bugs that need fixing. Someone has to address these things, which means either keeping a developer on retainer or scrambling to find one when something breaks, and the more complex the system, the more frequently these issues arise.

Knowledge dependency. The person who built your system understands it in ways that documentation rarely captures, and when they leave or become unavailable, that knowledge leaves with them. You become dependent on someone's continued availability and goodwill, and finding a replacement who can get up to speed quickly isn't always straightforward, especially for systems with limited documentation or unusual architecture.

Opportunity cost. Every hour spent maintaining custom software is an hour not spent on something else, and for small teams this matters enormously. The system that saved you time initially can become the thing that consumes it, particularly if you didn't anticipate the ongoing demands when you made the decision.

Evolution. Your business will change, and the process that made perfect sense when you commissioned the software will need to adapt. Every change requires development work, which requires time and money and someone who understands the existing system well enough to modify it safely.

None of this means building is wrong, but the decision should account for these ongoing costs and weigh them proportionately to the size and complexity of what you're considering. A focused utility that automates one repetitive task is a different proposition from a system that becomes central to your operations.

When buying makes sense

Most of the time, for most businesses, buying is the right choice. This isn't because custom software is bad, but because the conditions that genuinely justify building are rarer than people assume.

The problem is common. If thousands of other businesses have the same need, someone has probably built a product to address it. Project management, invoicing, customer relationship management, email marketing: these are solved problems, and while the existing tools might not be perfect, they're good enough. The gap between "good enough" and "perfect" rarely justifies the cost of building.

The workflow can adapt. Sometimes the friction you feel with off-the-shelf software comes from trying to preserve a process that doesn't need preserving. The tool isn't wrong; your workflow is just different. Adapting your process to fit well-designed software is often easier than building software to fit your existing process, especially when the tool embodies best practices you might benefit from adopting.

Speed matters more than perfection. You can start using bought software today, while custom software takes months to build and more months to refine. If time-to-value is a priority, buying usually wins.

You don't have technical capacity. Building software requires ongoing technical involvement, and if you don't have developers in-house and don't want to manage an ongoing relationship with an agency or contractor, buying removes a category of problems you'd otherwise need to solve.

When building makes sense

That said, there are genuine cases where custom software is the right answer.

Your process is your competitive advantage. If the way you do something is genuinely unique and that uniqueness creates value, forcing it into a generic tool might erode exactly what makes you effective. A logistics company with a proprietary routing approach, a financial services firm with unusual risk models, a manufacturer with distinctive quality control: these might justify custom systems that preserve and enhance what differentiates them.

Off-the-shelf options are bloated or overcomplicated. Enterprise software often tries to serve every possible use case, resulting in cluttered interfaces and steep learning curves. If your team spends more time navigating features they don't need than doing actual work, a focused custom tool that does exactly what you require, and nothing more, might genuinely be simpler to use and cheaper to operate in the long run.

No adequate solution exists. Sometimes you're operating in a space where the existing tools genuinely don't work, particularly in niche industries or at the intersection of multiple domains where no single product covers the territory. This is rarer than people think, but it does happen.

Integration is the core problem. If your main challenge is connecting multiple systems and making them work together, custom development might be the only practical path. Middleware and integration platforms help, but complex integration scenarios often require bespoke work to handle the specific logic your business requires.

You've outgrown the off-the-shelf options. At a certain scale, the constraints of generic tools become genuinely limiting, and what worked for a team of five might not work for a team of fifty. This is usually a good problem to have, though it's worth being honest about whether you're actually at this point or just anticipating it prematurely.

The hybrid path

The choice isn't always binary, and many businesses find a middle ground by using off-the-shelf tools for most of their needs while building custom components where it genuinely matters.

This might mean using a standard CRM but building a custom integration that syncs it with your proprietary systems, or using a project management tool for 90% of your workflow while building a small custom application for the 10% that requires something specific. The key is recognising that not every problem requires the same solution, and mixing approaches can give you the best of both worlds.

The hybrid approach works when you're disciplined about what genuinely requires custom work, but it fails when every small frustration becomes a reason to build and you end up with a fragmented landscape of half-integrated custom systems that nobody fully understands.

Questions to ask before deciding

Before committing to building, work through these questions honestly.

What happens if the person who built this leaves? If the answer is "we'd be in trouble," that's a significant risk that you need to be prepared to manage, whether through documentation, knowledge sharing, or accepting the ongoing cost of external support.

What's the ongoing cost, not just the upfront cost? Ask your developer or agency to estimate not just the build, but a year of maintenance, updates and small changes. If they can't give you a realistic figure, that's a warning sign; if the system is small and focused, ongoing costs might be minimal, but you should understand what you're signing up for either way.

Have we genuinely tried the alternatives? "We looked at a few options and they didn't quite work" isn't sufficient due diligence. Have you spoken to the vendors about your specific needs, explored customisation options within the existing tools, or tried adapting your process? The grass is always greener when you haven't fully explored the garden you're already in.

Is our current frustration proportionate to the investment we're considering? Sometimes the pain of an imperfect tool feels larger than it is, and a £50,000 custom build to solve a problem that costs you two hours of admin per week might not be the best use of resources, no matter how annoying those two hours feel.

What's our exit strategy? If the custom software becomes a burden, how would you migrate away from it? If there's no realistic path, you're betting heavily on getting the decision right the first time.

The decision is about trade-offs

There's no universally correct answer to the build vs. buy question: building gives you control and focus but demands investment proportionate to what you're creating, while buying gives you convenience and shared maintenance costs but requires compromise on how things work.

What matters is making the decision deliberately, with a clear view of what you're trading off. The worst outcomes come from building because you haven't properly evaluated the alternatives, or buying because you underestimated what you actually need.

Take the time to understand the real costs on both sides, and talk to businesses that have made similar decisions, both those who built and those who bought. Be honest about your technical capacity and your willingness to maintain something over the long term. The right answer depends on your specific situation, and it's worth getting it right.