The real cost comparison starts in year three
Most founders compare year-one costs and call it analysis. That is where the SaaS pitch wins every time, because the sticker price is engineered to look cheap against a development quote. The actual decision lives in years three to five, and it looks very different.
Why sticker price is the wrong starting point
Gartner's TCO work finds that organisations routinely miss 50 to 70 per cent of total software costs when calculating ownership expenses. The subscription is the visible portion. The rest is configuration, migration, training, integration middleware, idle licences, support overhead and eventual exit costs.
A worked example from the LMS sector makes the gap concrete. Plume Studio's analysis puts the five-year SaaS spend at roughly $1.6M for 10,000 users, against about $250k for an equivalent custom platform. That is not a marginal difference. It is a structural one, driven by per-user pricing scaling linearly while custom maintenance stays largely flat.
Where SaaS TCO quietly compounds
Three forces compound year on year, and none of them appear on the first quote:
- Price increases. SaaS pricing rose by an average of 11.4% in 2025, and some vendors raised fees by more than 300% after acquisitions. These increases are not tied to new value. They reflect an industry shoring up profitability.
- AI-feature surcharges. Enterprise SaaS TCO now runs 2.5x to 4x the advertised sticker, with AI-feature add-ons driving costs up by an average of 34% since 2024.
- Idle seats. Zylo's 2025 SaaS Management Index puts unused licences at 53%, costing an average enterprise around US$21 million annually.
The fair counter-argument
Custom software's TCO advantage assumes you can retain competent engineering support. If you cannot, personnel costs to maintain self-hosted systems can become the single largest TCO line item. Custom only wins when the maintenance discipline is real.
PwC's maintenance figures back this up: custom software typically runs 15 to 20 per cent of initial development annually, against 22 to 25 per cent for heavily customised off-the-shelf software. That customisation tax on commercial products is real and rarely budgeted.
The commodity vs. competitive advantage test
The clearest decision rule we use sounds almost too simple: buy commodity, build moat. Gartner calls the resulting approach composable architecture. A McKinsey study (cited via Techvinta) found companies adopting it were 2.5x more likely to sit in the top quartile of financial performance.
What to buy without hesitation
If a category has a mature SaaS market and the function does not differentiate your business, buy it. Email, video conferencing, project management, HR information systems, accounting, payroll, payments, monitoring, basic CRM. Building any of these from scratch is an expensive way to recreate what a 500-person product team already ships every quarter.
What to build when the workflow is your moat
Custom belongs to the layer where your business actually competes: your core product, customer-facing workflows, proprietary data, pricing engines, the operations that would be painful to standardise into someone else's UI.
The reframe that helped us most comes from Horizon's analysis: the decision is not about company size, it is about data volume and business model. A $2M company processing 50,000 transactions daily can outgrow QuickBooks, while a $40M services firm runs perfectly well on standard ERPs. The inflection point hits when data operations become the competitive advantage.
When clients are wrestling with where to draw that line, we typically frame it as a digital strategy consulting exercise before any code is scoped. Getting the boundary right is worth more than any framework choice that follows.
Integration debt: the cost nobody budgets for
This is where SaaS economics quietly fall apart. MuleSoft's 2025 Connectivity Benchmark found the average business runs 897 apps, with only 29 per cent of them integrated. The rest are stranded islands of data.
The cost of bridging those islands rarely appears on anyone's roadmap. A figure cited by Horizon (sourced to Stack Overflow's 2024 survey) puts 68.3 per cent of companies at $125,000+ annually just trying to make off-the-shelf tools talk to each other. Treat that specific figure with caution, but the pattern is undeniable to anyone who has spent a quarter debugging Zapier chains.
Pendo's feature-adoption work (2019, but still widely cited) found 80 per cent of SaaS features go unused. You are paying full price for a fraction of the product, and the fraction you actually need rarely lines up cleanly between vendors.
The risk of using off-the-shelf is not the tool itself. It is forcing it to a job it was not designed for.
The composable model handles this with a deliberate integration layer: thin middleware, often custom, sometimes iPaaS, connecting your SaaS commodities to your custom core. Done well, it gives you the buying efficiency without surrendering the workflows you depend on.
Vendor lock-in, roadmap control and what it costs at exit
When you buy SaaS, your vendor controls the roadmap. Updates, deprecations, pricing changes and platform decisions all sit with them. You adapt. That is fine for commodity functions where switching costs are low. It becomes existential for the systems your business actually runs on.
Edana documents a Swiss logistics company that spent 250,000 CHF migrating off a SaaS platform after five years, when the product had grown too rigid for their operation. The migration added six months to the timeline. Exit costs, in their analysis, can exceed 25 per cent of a project's initial budget.
There is also an angle most founders miss: acquirers care. Buyers discount businesses with cost structures that expand unpredictably or depend on external pricing decisions. A custom platform does not guarantee a higher multiple, but it removes one of the standard reasons companies stay anchored in the three to five times EBITDA range. If you are five years from an exit, your SaaS stack is a valuation question, not just an operations one.
For regulated industries the calculus tilts further. European fintechs facing PSD2 and GDPR benefit from database-level encryption and EU-only hosting baked into the code itself. BetterCloud's 2024 SaaSOps data suggests firms pay around 20 per cent less on cyber-insurance premiums when running self-hosted, hard-segmented apps, though we would verify that figure against the primary source before quoting it to a board.
Get plain-English guides like this in your inbox.
One short email a month. WordPress, Shopify, SEO, no fluff. Unsubscribe in one click.
We never share your email.
When custom software fails
Custom software fails often enough that any article advocating for it without naming the failure modes is selling you something.
The cautionary CRM story
Techvinta documents a company that spent $480,000 and fourteen months building a custom CRM from scratch, with custom fields, custom workflows, custom dashboards, and ended up with a worse version of HubSpot, no mobile app, and one developer who understood the codebase. That is the archetypal failure.
BCG's research on large-scale technology programmes finds more than two-thirds of enterprise software projects miss time, budget or scope. Custom development amplifies these challenges because nobody is shipping fixes to your product on a public release schedule.
The conditions that make custom work
In our experience, custom software succeeds when three things are true:
- The problem is genuinely differentiated. You are not rebuilding HubSpot. You are building something that does not exist commercially because it encodes your specific operation.
- The scope is small and modular at the start. Ship the workflow that hurts most, integrate it with SaaS for everything else, and only expand when usage proves it out.
- You have, or can credibly retain, the engineering discipline to maintain it. That means versioning, observability, tests, documentation and a team (internal or partnered) that will still be around in three years.
If any of those is shaky, buy. The CRM-from-scratch story is what happens when none of them are true.
How the economics of building have shifted
The build side of the equation has changed materially in the last few years, and the change is genuinely under-appreciated.
Modern frameworks have collapsed the cost of standing up a real application. Next.js, Supabase, modern hosting, typed APIs and component libraries mean you are not writing the things you used to write. A practitioner estimate from Horizon puts custom development at roughly half the 2019 cost, which sounds aggressive until you have shipped a few projects on the current stack.
AI-assisted development has compressed the build side again. We use it daily for scaffolding, tests, migrations and refactors. The leverage is real, though the headline claims you see online are usually inflated.
Gartner (via Precedence Research, 2025) expects 70 per cent of new SME apps will include low-code modules by 2026. Platforms like OutSystems, Mendix and Microsoft Power Apps occupy a useful middle ground for internal tools where you want custom logic without a full engineering investment. They are not the answer for your core product, but they are often the right call for the operations layer behind it.
If you are weighing AI features specifically, we covered the practical version of that decision in adding AI features to your product without the hype.
Making the call: a practical decision framework
Run each system through five questions. Four or five "build" answers, consider custom. Three or fewer, buy.
- Is this workflow part of your moat, or commodity? Moat leans build. Commodity leans buy.
- Will per-user or per-transaction pricing outpace your growth in three years? If yes, the SaaS line will compound past any build cost.
- How many integrations does it need, and how brittle are they? High integration count with poor native connectors pushes towards custom or a custom integration layer.
- What does exit look like? If migrating off costs more than 25 per cent of the original spend, you are locked in. Build, or pick a vendor with serious export tooling.
- Do you have the maintenance discipline? If you cannot honestly say yes for the next three years, buy and revisit later.
Build custom software and SaaS development where the answers stack in its favour. Buy everywhere else. The mistake is choosing one philosophy and applying it uniformly. The composable approach is harder because it forces a per-system decision. That is exactly why it works.
If you want to see how we approach this in practice, the patterns repeat across every client engagement: a thin custom core, a curated SaaS layer, and integration middleware deliberately designed rather than accumulated by accident.
