Every growing business eventually hits the same decision: do we buy software off the shelf, or do we build something custom?
It's one of the most consequential technology decisions a company makes — and most get it wrong, usually by defaulting to one answer without thinking clearly about the tradeoffs.
Here's a framework we use with clients to work through it.
Start with the question: is this a commodity function or a competitive differentiator?
If the problem you're solving is the same problem every business in your industry solves the same way, buy. Accounting, payroll, CRM, email — these are commodity functions. Off-the-shelf software exists precisely because the problem is universal and well-understood.
If the problem is specific to how your business operates — your unique workflow, your proprietary data model, your process that gives you an edge — build. No vendor builds software for your specific competitive advantage, because that's yours.
The hidden cost of buying
Software vendors love to show you the per-seat cost. They don't show you:
- The hours your team spends working around the software's limitations
- The cost of data that's locked in a system you don't control
- The time lost to features you'll never use, cluttering the interface
- The vendor dependency you've created — and what happens to your pricing when they know you're locked in
We've seen companies paying $50,000/year for enterprise software that a custom internal tool would have solved for a one-time $15,000 build and near-zero maintenance.
The hidden cost of building
Building isn't free either. Custom software requires:
- Upfront design and development time
- Ongoing maintenance when requirements change
- Someone who understands the codebase well enough to modify it
The maintenance piece is where many custom builds fail. A tool built by a contractor with no documentation becomes a liability the moment that contractor leaves.
This is why documentation and knowledge transfer are non-negotiable for us in every engagement.
A simple decision matrix
| Buy | Build | |
|---|---|---|
| Generic problem | ✓ Strong choice | ✗ Likely over-engineered |
| Unique workflow | ✗ Constant workarounds | ✓ Strong choice |
| High volume / repetitive | Check the API | ✓ Automation opportunity |
| Regulated data | Check compliance | ✓ Control your own stack |
| Fast-changing requirements | ✗ Vendor lag | ✓ You control the roadmap |
The often-overlooked middle ground: integrate
A third option that often gets missed: buy the commodity layer and build the glue.
Use Salesforce for CRM, QuickBooks for accounting — but build the custom pipeline that connects them, the dashboard that surfaces the right data, the automation that eliminates the manual steps between systems.
This hybrid approach often gives you the best of both worlds: proven software for the core functions, custom logic for the parts that differentiate you.
Getting it right
The worst build vs. buy decisions happen when the question gets answered by default rather than by design. "We've always used software for this" is not a strategy. Neither is "we'll just build it" without thinking through maintenance.
If you're at a decision point on internal tooling, we're happy to think through it with you. We have no stake in the outcome — we'll tell you to buy if that's the right answer.