Every business I work with eventually hits the same question: should we buy an off-the-shelf tool, or build something custom?
It sounds simple, but getting it wrong is expensive. Buy when you should build, and you'll spend years fighting a tool that doesn't fit. Build when you should buy, and you'll burn budget solving problems that someone else already solved better.
Here's the framework I use with clients.
When to buy
Off-the-shelf software wins when:
- The problem is generic. Payroll, email marketing, basic CRM, project management — these are solved problems. The tools are mature, well-supported, and cheaper than building your own.
- You don't need deep customization. If 80% of the features work and the other 20% are nice-to-haves, just buy it.
- Speed matters more than fit. If you need something running next week, buying beats building every time.
- Compliance is a factor. Payment processing, HIPAA, SOC 2 — buying from a vendor who already handles compliance is almost always the right call.
When to build
Custom software wins when:
- Your workflow is your competitive advantage. If the way you do things is what makes your business different, cramming that into generic software will sand off the edges that make you competitive.
- You've outgrown the tool. When you're spending more time working around your software than working with it, that's a signal.
- Integration is the core problem. If you need three tools to talk to each other in ways they weren't designed to, a custom integration layer is often cheaper than switching platforms.
- The math works. When the annual cost of SaaS licenses for your team exceeds what it would cost to build and maintain a custom tool, the breakeven math starts to favor building.
The hybrid approach
Most of the time, the best answer isn't purely build or purely buy. It's buy the commodity parts, build the differentiating parts.
Use Shopify for your storefront, but build a custom inventory sync that handles your specific warehouse logic. Use a standard CRM, but build a custom dashboard that surfaces the metrics your team actually cares about. Use off-the-shelf accounting software, but build the integration that connects it to your proprietary quoting system.
This approach gives you the reliability and speed of proven tools where it matters, and the flexibility of custom software where it counts.
Questions I ask clients
Before we write a single line of code, I work through these questions:
- What are you solving for? Speed, cost, control, or competitive differentiation?
- What's the total cost of ownership? Include licensing, implementation, training, and the cost of workarounds for missing features.
- How likely is this to change? If requirements are stable, buy. If they're evolving fast, build.
- Who maintains it? Custom software needs ongoing support. If you don't have the capacity for that, factor it into the cost.
- What's the exit plan? If you buy and it doesn't work out, how hard is it to switch? If you build and priorities change, how modular is the codebase?
The expensive mistake
The most common mistake I see is building custom software for a problem that didn't need a custom solution. The second most common is buying software and then spending more on customization and workarounds than it would have cost to build from scratch.
Both come from skipping the analysis and jumping straight to a solution. Take the time to understand the problem first. The right answer usually becomes obvious.
Not sure which direction to go? My strategy and consulting services are designed to help you figure that out before spending anything on development. Or check out my web development services if you already know you need to build.