The conventional wisdom is clear: buy off-the-shelf software whenever you can. Building custom is expensive, risky, and slow. SaaS is the modern way.
Except when it isn't.
The build vs buy calculation has shifted. SaaS costs have exploded. Integration complexity has multiplied. And the "quick win" of buying often becomes the slow bleed of workarounds, limitations, and vendor lock-in.
Here's how to actually evaluate the decision—and why custom software wins more often than most people assume.
The Hidden Costs of Buying
When you evaluate SaaS, you see the subscription price. What you don't see is everything else.
The subscription that never stops
A $2,000/month platform seems reasonable. That's $24,000 a year. Over five years, it's $120,000—and that assumes no price increases.
SaaS vendors raise prices. Regularly. You're locked in, your data is in their system, and switching costs are high. So you pay the increase. And the next one.
That $24,000/year platform is $30,000 by year three and $40,000 by year five. Your five-year cost isn't $120,000—it's $160,000 or more.
And you still don't own anything.
Per-seat pricing that scales against you
Many platforms charge per user. Great when you have 10 users. Painful when you have 50. Brutal when you have 200.
Your software costs grow with your headcount, even when the software itself doesn't change. You're penalised for success.
Some vendors cap seats or offer enterprise pricing—but that negotiation happens from a position of weakness. They know you're locked in. They know switching is expensive. They price accordingly.
The features you're paying for (but not using)
Enterprise SaaS is built for everyone, which means it's optimised for no one.
You're paying for modules you'll never enable. Features designed for different industries. Integrations with systems you don't use. Compliance certifications you don't need.
That bloat isn't free. It's built into your subscription. You're subsidising features for other customers while getting a fraction of the platform's capability.
Implementation and customisation
The subscription is just the start. Then comes implementation.
"Professional services" to configure the platform for your business. Custom development to build the integrations they don't offer. Training to teach your team a system that doesn't match your workflow.
Implementation often costs 50-100% of the first year's subscription. For enterprise platforms, it can be multiples of the annual cost.
And when requirements change? More professional services. More custom development. More cost.
Integration hell
You don't use one platform. You use ten.
Your ERP doesn't talk to your CRM. Your CRM doesn't talk to your ecommerce. Your ecommerce doesn't talk to your warehouse. Each system has its own data model, its own API quirks, its own limitations.
So you buy middleware. Or you build custom integrations. Or you hire someone to move data manually. Each approach costs money and creates fragility.
The "best of breed" strategy—buying the best tool for each job—sounds smart until you're spending more on integration than on the tools themselves. And when something breaks, nobody owns the problem.
Vendor lock-in
Your data lives in their system. Your workflows are built around their assumptions. Your team knows their interface.
Switching means migrating data (if they let you export it properly). Retraining staff. Rebuilding integrations. Months of parallel running.
The vendor knows this. That's why they raise prices confidently. That's why feature requests go ignored. That's why the roadmap serves their interests, not yours.
You're not a customer—you're a captive.
When Off-the-Shelf Makes Sense
Let's be fair. Sometimes buying is absolutely the right choice.
Commodity functions
Email. Calendar. Basic accounting. Document storage. Video conferencing.
These are solved problems. Gmail, Xero, Dropbox, Zoom—they work, they're cheap, and there's no competitive advantage in building your own.
If a function is the same for every business, buy it.
Regulated complexity
Payroll. Superannuation. Tax compliance. Payment processing.
These involve regulations that change constantly. Building your own means maintaining compliance forever. Platforms like Employment Hero, Stripe, and Xero invest heavily in staying compliant so you don't have to.
If the complexity is regulatory rather than business-specific, buy it.
Early-stage exploration
You're not sure what you need yet. You're testing a market. You're validating an idea.
Buying lets you move fast and learn cheap. You can always build later once you know what actually matters.
If you're building an MVP, use existing tools wherever possible. Build custom only for your unique value proposition. Once you've validated the concept, that's when the build vs buy question gets real.
Genuine best-of-breed excellence
Some platforms are genuinely exceptional. Shopify for simple ecommerce. Salesforce for complex enterprise sales. Microsoft Fabric for data and analytics.
If a platform is dramatically better than anything you could build—and your use case matches their sweet spot—buy it.
The key phrase: "matches their sweet spot." Most businesses assume they fit when they don't.
When Custom Wins
Custom software makes sense more often than the conventional wisdom suggests. Here's when building beats buying.
Your process is your advantage
If how you do something is what makes you competitive, you shouldn't force that into someone else's assumptions.
A wholesale ordering portal that matches your exact pricing logic, your exact customer workflows, your exact ERP integration. A operations dashboard that reflects how your business actually works, not how a vendor thinks businesses should work.
When the software IS the competitive advantage, build it.
Integration is the whole problem
If your challenge is connecting systems—making your ERP, CRM, and logistics work together—buying another disconnected platform doesn't help.
What you need is integration logic. Business rules applied across systems. A unified view of operations. That's inherently custom work, whether you call it "custom software" or "integration layer."
Sometimes the right answer isn't a new platform—it's glue between existing platforms.
Off-the-shelf doesn't fit
You've tried the platforms. None of them handle your pricing model. Or your approval workflows. Or your customer hierarchy. Or your compliance requirements.
You're looking at 60% fit with 40% workarounds. Those workarounds will haunt you forever.
If no off-the-shelf solution fits without significant compromise, you're choosing between bad fit and custom build. Bad fit loses.
You've outgrown generic
You started with a simple tool. It worked when you were small. Now you're bigger, more complex, and fighting the platform constantly.
Every workaround creates more workarounds. Every limitation costs hours per week. The team hates the system. Customers feel the friction.
Sometimes you need to graduate from tools built for everyone to something built for you.
The TCO favours building
Add it up honestly:
Buying:
- 5 years of subscriptions (with increases)
- Implementation and training
- Ongoing customisation and professional services
- Integration costs
- Workaround costs (manual processes, errors, inefficiency)
- Switching costs when it eventually fails you
Building:
- Development cost
- Hosting and maintenance
- Iterations and improvements
- Full ownership forever
For many businesses, especially those with specific requirements and long time horizons, the numbers favour building.
A $150,000 custom build that you own forever versus $50,000/year in subscriptions that never stop. By year four, building was cheaper. By year ten, it's not even close.
How to Evaluate Build vs Buy
Here's a framework for making the decision honestly.
1. Define the actual requirement
Not "we need a CRM" but "we need to track customer interactions, manage opportunities, and integrate with our ERP for order history."
Specific requirements reveal whether off-the-shelf solutions actually fit—or whether you're assuming fit that doesn't exist.
2. Calculate true TCO
For the buy option:
- 5-year subscription cost (assume 10% annual increases)
- Implementation and customisation
- Training
- Integration development
- Ongoing professional services
- Manual workarounds (hours × cost × 5 years)
For the build option:
- Development cost (get real quotes, not guesses)
- Hosting and infrastructure
- Ongoing maintenance and support
- Future enhancement budget
Compare honestly. The build number is usually more predictable than people assume. The buy number is usually higher than people expect.
3. Assess fit honestly
For each potential platform:
- What percentage of requirements does it meet natively?
- What requires configuration or customisation?
- What can't be done at all?
If native fit is below 70%, you're buying a platform to fight with. Below 50%, you're buying someone else's technical debt.
4. Evaluate lock-in risk
- Can you export your data completely?
- How hard is migration to an alternative?
- What happens if the vendor is acquired, pivots, or raises prices dramatically?
- How much leverage do you have in the relationship?
High lock-in plus critical function equals significant risk. Factor that in.
5. Consider the long game
Where will you be in five years? Ten years?
A growing business will have more users, more data, more complex requirements. Does the buy option scale gracefully, or does it become more expensive and more limiting?
A custom solution scales with your needs because it's built for your needs.
The Hybrid Approach
The best answer often isn't pure build or pure buy. It's strategic combination.
Buy commodities. Email, accounting, basic infrastructure. Don't build what's already solved.
Build differentiators. The systems that make your business unique. The integrations that tie everything together. The customer experiences that set you apart.
Integrate intentionally. Not every system needs to connect to every other system. Identify the critical data flows and build those properly. Accept that some systems will stay siloed.
This approach gives you the efficiency of platforms where they make sense and the fit of custom where it matters.
Making the Decision
Before your next software decision:
-
Resist the default. "Just buy something" isn't a strategy. Neither is "build everything ourselves."
-
Do the real math. Not the vendor's ROI calculator. Your actual costs, your actual requirements, your actual timeline.
-
Talk to references. Not the vendor's hand-picked success stories. Find businesses like yours who've implemented the solution. Ask what it really cost. Ask what they'd do differently.
-
Get a build estimate. Even if you're leaning toward buying, understand what custom would cost. You might be surprised.
-
Think in decades. Software decisions persist. The system you choose today will be running in 2030, 2035, 2040. Choose accordingly.
The right answer depends on your specific situation. But the answer is "build" more often than most people think—and the gap is widening.
Evaluating a build vs buy decision? Book a call with our team. We'll help you assess the options honestly—even if the right answer is off-the-shelf.
