Build vs Buy: The Spreadsheet That Tells the Truth
Every growing business hits this question eventually. You’ve outgrown your current tools. You need something better. The vendors are calling with shiny demos. But someone on your team says, “Why don’t we just build it ourselves?”
Both paths can work. Both can also be expensive disasters.
Here’s how to figure out which one makes sense for your situation.
The Buy Bias
Let’s start with my bias: most SMBs should buy, not build.
Building software is expensive, slow, and risky. Off-the-shelf tools are mature, supported, and designed by people who think about your problem full-time. Unless you have a genuine competitive advantage locked up in custom software, buying is usually the right answer.
But not always.
When Building Actually Makes Sense
Custom development makes sense in specific situations:
Your process is genuinely unique. Not “unique” because you’ve done it this way for twenty years. Unique because your industry or business model requires things that don’t exist in commercial software.
The gap directly affects revenue or competitive position. If better software would let you charge more, win more deals, or operate with margins others can’t match, custom work might pay off.
Off-the-shelf options are genuinely inadequate. Not “imperfect” or “requires workarounds.” Inadequate. If existing tools fundamentally can’t solve your problem, you might need to build.
You have access to ongoing development capacity. Software isn’t built once. It needs maintenance, updates, and iteration. Without ongoing developer access, your custom solution becomes technical debt.
The Real Cost of Building
When someone proposes building custom software, they always underestimate the cost. Always.
Here’s what they quote:
- Initial development: $50,000
Here’s what they actually spend:
- Initial development: $80,000 (it always runs over)
- Testing and bug fixes: $15,000
- Integration work: $10,000
- Training and documentation: $5,000
- Year 1 maintenance and changes: $20,000
- Year 2 maintenance: $20,000
- Year 3 maintenance: $20,000
- Three-year total: $170,000
Meanwhile, off-the-shelf software at $500/month costs $18,000 over three years. With support included. And updates. And the vendor worrying about security.
The numbers rarely favor building.
When Buying Goes Wrong
Buying isn’t automatically right either. I’ve seen companies buy enterprise platforms that crushed them under weight of complexity. Or paid for features they never used. Or got locked into vendors who raised prices after migration.
Buying goes wrong when:
You buy for future needs, not current ones. That enterprise platform you’ll “grow into” costs enterprise money today.
You ignore implementation costs. The software license is 30% of the real cost. Implementation, training, customization, and integration are the other 70%.
You don’t involve actual users. Executives pick tools, then wonder why staff won’t use them.
You underestimate switching costs. Getting out of a bad decision costs more than making a good one initially.
The Decision Framework
I use a simple spreadsheet to work through build vs buy decisions. Here’s the structure:
Total Cost of Buying (3-Year View)
| Item | Cost |
|---|---|
| Software licensing (annual x 3) | $ |
| Implementation / setup | $ |
| Customization | $ |
| Integration with existing systems | $ |
| Training | $ |
| Ongoing support costs | $ |
| Total | $ |
Total Cost of Building (3-Year View)
| Item | Cost |
|---|---|
| Initial development | $ |
| Overrun buffer (50%) | $ |
| Testing and QA | $ |
| Integration work | $ |
| Documentation and training | $ |
| Year 1 maintenance (20% of build) | $ |
| Year 2 maintenance (20% of build) | $ |
| Year 3 maintenance (20% of build) | $ |
| Total | $ |
Capability Comparison
| Factor | Buy (1-5) | Build (1-5) |
|---|---|---|
| Meets current requirements | ||
| Meets likely future needs | ||
| Time to deployment | ||
| Risk level | ||
| Flexibility to change | ||
| Vendor/developer reliability |
Run these numbers honestly. Add a 50% buffer to any custom development estimate, because that’s how wrong estimates typically are.
The Hybrid Option
Sometimes the answer is both.
Buy the core platform. Build integrations or custom modules. This gives you the stability of commercial software with the flexibility to fill gaps.
Most modern SaaS platforms have APIs. A skilled developer can extend them without rebuilding the core functionality. You get the vendor’s security, uptime, and ongoing development while solving your unique needs.
This is often the sweet spot.
Questions to Ask Vendors
Before buying, ask:
- What’s the total first-year cost, including implementation?
- What’s included in the base price vs add-ons?
- What’s the pricing model as we grow?
- How do customers your size typically implement?
- What integrations exist for our other tools?
- What happens if we need to leave?
Ask to speak with reference customers your size. Not their largest logos. Companies with your employee count and complexity.
Questions to Ask Developers
Before building, ask:
- What similar projects have you delivered?
- What’s your honest estimate plus buffer?
- How will ongoing maintenance work?
- What technology choices make this easier to maintain long-term?
- What happens if you’re unavailable in year two?
If a developer promises a fixed price with no overruns, they’re either naive or lying. Software projects almost always find unexpected complexity.
My Decision Rule
Here’s my shortcut. If you can’t immediately articulate why your needs are too unique for commercial software, they probably aren’t. Buy.
If your operations people are describing workflows that make vendors’ heads spin, and you’ve evaluated three or more platforms that can’t handle it, maybe you need to build.
But even then, start small. Build a proof of concept. Validate that custom software actually solves the problem before committing to a full project.
The Bottom Line
Building software is expensive, slow, and creates ongoing obligations. Buying software is faster, cheaper, but requires compromise.
Most SMBs should buy. Not because building is bad, but because their resources are better spent on their actual business. Building custom software makes sense when it’s directly tied to competitive advantage, not just preference.
Do the math. Be honest about costs. Make the decision that fits your situation.