SaaS vs Custom Software: The Decision Your CFO and CTO Keep Fighting Over

Direct answer: SaaS wins for standard, non-core work: payroll, email, video calls, generic CRM for a small team. Custom software wins when a process is a genuine competitive edge, when data ownership is non-negotiable, or when per-seat licensing would cost more over five years than a one-time build. Most companies need a deliberate mix, not an all-or-nothing bet.

Why This Decision Keeps Landing on the CFO's Desk

The fight isn't really about software. It's about which failure mode each side is trying to avoid. The CFO watches a recurring-cost line that multiplies every renewal, one more department signs up for one more $30-a-seat tool, and wants a number that stops climbing on its own. The CTO watches the team bend a real workflow to fit a product built for the average customer, and worries about a system with no ceiling other than the vendor's roadmap.

Neither instinct is wrong on its own. It becomes a problem when the decision defaults to habit instead of math: buying another module because the company already has a vendor relationship, or building in-house because engineers are on staff and building feels like "not paying for it." The rest of this guide is the math that should be settling the argument instead.

This is a portfolio-level question, not a single-app one. If the decision in front of you is which path fits one specific tool, our build-vs-buy-vs-no-code framework covers that 8-criteria comparison directly. This guide is one level up: how a company should think about its entire software stack, and when the answer for a given function should flip from subscribe to build.

What SaaS Sprawl Actually Costs a Company

How many SaaS tools does the average company actually run, and how much of that spend goes to waste? Somewhere between 305 and 342 applications, depending on whose benchmark you read, with roughly a third to over half of purchased licenses sitting unused. That range itself is the point: nobody, including the vendors selling SaaS-management tools, has a precise handle on what a company's stack contains.

• App count. Zylo's 2026 SaaS Management Index puts the average company at 305 SaaS applications; Productiv's most recent benchmark counts 342 apps, down slightly from 374 the year before (source: Zylo, 175+ SaaS Statistics for 2026; Productiv, IT SaaS Statistics).
• Unused licenses. Zylo's 2026 index reports organizations leave an average of 36% of SaaS licenses unused; other industry surveys, using different sample sets, put license waste as high as 43–55% (source: Zylo, 2026 SaaS Management Index).
• Spend per employee. Zylo's 2026 data puts median SaaS spend per employee at $9,455; Productiv's own figure runs lower, at $5,607 per employee (source: Zylo, 2026 SaaS Management Index; Productiv, IT SaaS Statistics).
• Who's buying it. Business units now control roughly 81% of SaaS spending, with IT directly overseeing just 15%, which is the mechanism behind sprawl: most new tools never pass through a single point of review (source: Zylo, 2026 SaaS Management Index).

None of this makes SaaS a bad deal. It means SaaS spend behaves like a utility bill that nobody is reading closely, and it keeps climbing by default unless someone owns the job of saying no to the fifth overlapping tool.

Where the Per-Seat Math Breaks as You Scale

Where the Per-Seat Math Breaks as You Scale (AI-generated illustration)

Why does software cost climb exactly when a company is succeeding, growing headcount? Per-seat pricing charges by user count, not by how much value a company gets per user, so a tool's bill scales with headcount even when the tenth support rep or the two-hundredth salesperson isn't using meaningfully more of the product than the first one did.

Run the arithmetic on a single tool. A support platform priced at $40 per seat per month costs $24,000 a year at 50 seats. Grow to 500 seats and the same tool costs $240,000 a year, a 10x jump that tracks headcount, not the tool's usefulness to any one of those 500 people. Multiply that across the 300-plus tools a mid-size company already runs (see the sprawl figures above) and the SaaS line item becomes a real cost center with no natural ceiling.

The market has started to notice. Gartner forecasts that agentic AI and outcome-based pricing will put roughly 20% of enterprise SaaS spending, an estimated $234 billion, at risk of shifting away from per-seat licensing by 2030, as buyers push back on paying by headcount for work software increasingly does on its own (source: Gartner, as reported by CIO). A custom build sidesteps this: engineering cost doesn't multiply by seat count, so its cost curve flattens right where the SaaS curve keeps climbing.

When SaaS Wins Outright

When does SaaS beat building custom, with no real argument on the other side? SaaS wins when the function is non-core, standardized across the industry, and speed to value matters more than a perfect process fit, because a mainstream product's shared R&D and compliance work would be expensive to rebuild for a marginal fit improvement. The table below covers both directions at a glance; the sections after it go deeper on the custom side.

If the decision in front of you is about one specific tool rather than a whole function, the 8-criteria comparison in our build-vs-buy-vs-no-code guide walks through process fit, cost, and ownership side by side for that narrower call.

When Custom Software Wins

When does the math flip toward building instead of subscribing? Custom software wins when the process itself is a competitive advantage, when data ownership or compliance requires control a shared platform can't offer, or when the five-year cost of per-seat licenses would exceed the cost of a one-time build plus maintenance, the three rows the table above is really pointing at.

The process is the differentiator, not the software category. Amazon's internal fulfillment and inventory systems aren't commercially available anywhere; the logic is inseparable from how Amazon runs its warehouses, which is precisely why it isn't for sale (source: ERP Perspective, How Amazon Quietly Built One of the Most Efficient ERPs in History). The pattern holds below enterprise scale too: if a pricing model or fulfillment sequence is genuinely how a company wins deals competitors don't, encoding it into software every competitor can also buy erases the advantage instead of protecting it.

The five-year seat math no longer favors renting. Take an 80-seat CRM at $150 per user per month: $144,000 a year, or $720,000 over five years, growing as headcount does. A custom CRM built around the same workflow, with no per-seat fee, often lands well under that five-year total once built and maintained. Our custom software development cost guide has dollar ranges by project type to run this comparison against real numbers.

Companies that get this right tend to treat software investment as deliberate, not habitual: McKinsey research found that companies with high-performing technology functions, the kind that make an active build-or-buy call instead of defaulting to whatever's fastest to provision, see up to 35% higher revenue growth and 10% higher profit margins than peers (source: McKinsey, How High Performers Optimize IT Productivity for Revenue Growth).

The Hybrid Model Most Companies Actually Run

The Hybrid Model Most Companies Actually Run (AI-generated illustration)

Do most companies really pick one path for their entire software stack? No. The pattern that shows up repeatedly in practice is a SaaS core for standardized systems of record (accounting, HRIS, communication) with a custom layer of glue and automation built on top, wiring those SaaS tools together to match how the business actually operates rather than how any one vendor imagined it.

This works because SaaS and custom software answer different questions inside the same stack. The SaaS core answers "what's the industry-standard way to run payroll, book-keeping, or email," and there's no reason to reinvent that. The custom layer answers "how does data move between these tools the way our business actually needs it to," which is connective logic no vendor building for thousands of other customers will ever prioritize for one company's edge case. A distributor might run SaaS inventory and SaaS accounting, then commission a custom middleware layer that reconciles the two in real time instead of someone exporting spreadsheets every Friday.

That connective layer, workflow automation, custom integrations, and internal tools sitting between SaaS systems, is exactly the kind of work covered in our business process automation services. It's usually a smaller, faster investment than replacing the SaaS core outright, and it's often where the real ROI sits: not ripping out the accounting platform, but stopping someone from re-typing the same invoice into three systems every week.

What Leaving a SaaS Platform Actually Costs

What happens when a company decides it's finally time to leave a SaaS platform it has run for years? It's rarely a weekend project. Expect months of extracting historical data, rebuilding every integration the old platform touched, retraining staff, and running both systems in parallel until the migration is proven safe, before the new tool earns back what the transition cost.

Data migration is the top-cited obstacle: 47% of enterprises name it a significant barrier to switching platforms, more than any other factor, because moving historical data cleanly and rebuilding integrations takes real effort regardless of how good the new tool is (source: Flexera 2023 State of the Cloud Report, as cited in Savi, Vendor Lock-In Is Draining Your Budget). A platform expensive to leave has less pressure to compete on price at renewal, which is why "we'll deal with the exit if we ever need to" is the wrong default. Three things make it cheaper later: negotiate a data-export clause into the contract before signing, not after deciding to leave; document every integration touching the platform as you build it; and avoid letting one SaaS tool become the single source of truth for data you'll need outside it.

Custom software doesn't make this risk disappear, a poorly documented internal system creates its own lock-in with whoever built it, but a company that owns its code and data model at least controls the migration path on its own terms.

How to Make the Call: A Framework for CFOs and CTOs

Is there a reliable way to make this call without it turning into a political argument? Score each major software function, not each individual tool, against five questions. A lopsided scorecard points clearly at one path; a mixed one usually means a function belongs in the hybrid model above rather than an all-in bet either way.

1. Is this function how we compete, or how everyone in the industry runs the same process? Competitive edge points toward custom; commodity points toward SaaS.
2. What does the bill look like in year five, not year one? Run the seat-count math forward at realistic headcount growth before comparing it to a build estimate.
3. Does this data need to live somewhere we fully control? For compliance, security, or contractual reasons, that alone can outweigh every other factor.
4. How fast is headcount growing in the team that uses this function? Fast growth against per-seat pricing is where the math breaks earliest.
5. Could a custom automation layer on top of the existing SaaS core solve this, instead of replacing the whole system? Often the real fix is gluing what's already there together properly.

Mostly commodity, slow-growth answers point to staying on SaaS. Mostly competitive-edge, fast-growth, or data-control answers point to a custom build. A mixed scorecard is the hybrid model, and that's the conversation worth having before signing another annual contract or greenlighting another internal build.

MONA's 200+ staff have been building the custom side of this equation, CRM, ERP, inventory, booking, portals, and the automation layers connecting them to existing SaaS tools, since 2016, delivering 14,000+ projects for companies that ran this exact math. If your team is somewhere in that scorecard right now, a free discovery call starts with an honest read on which functions are worth building and which aren't.

Frequently Asked Questions

Is SaaS or custom software cheaper?

It depends on the time horizon and the function. SaaS is almost always cheaper in year one. Custom software often wins on total cost by year two to five for functions with growing headcount, because per-seat fees compound while a custom build's cost curve flattens after launch. Commodity functions usually stay cheaper on SaaS indefinitely.

When should a company switch from SaaS to custom software?

Switch when a workflow is a genuine competitive differentiator, when compliance or data-residency rules require full control, or when the five-year projected SaaS bill for a function exceeds a realistic custom build and maintenance cost. Fast headcount growth in a per-seat tool is usually the earliest warning sign.

What is SaaS sprawl and why does it matter?

SaaS sprawl is the unmanaged accumulation of subscription tools across departments, now averaging 305–342 apps per company with roughly a third to over half of licenses sitting unused. It matters because most of that spend gets approved outside IT, one tool at a time, with nobody reviewing the total.

Can SaaS and custom software work together in one company?

Yes, and it's the most common real-world pattern: SaaS for standardized systems of record like accounting and HRIS, with a custom layer of automation and integration on top connecting those tools to how the business actually operates. Most companies need both, not one or the other.

How do I know if a workflow is a competitive advantage worth building custom?

Ask whether a competitor buying the same off-the-shelf tool your team uses would erase your edge in that process. If the answer is yes, the workflow is a commodity best left on SaaS. If a competitor couldn't replicate the advantage just by subscribing to the same software, it's worth owning.

What's the biggest hidden cost of leaving a SaaS platform?

Data migration. It's the most cited barrier to switching platforms, cited by nearly half of enterprises, because moving historical data cleanly and rebuilding every integration point takes real time regardless of how much better the new platform is. Negotiating data-export rights before signing avoids the worst of it.