Why Do SaaS Tools Hit a Wall at Scale and When Should You Build Your Own?

A Series B SaaS company in the Nordics doubled its headcount in eighteen months. Their project management tool billed per seat. Their CRM charged by contact tier. Their data warehouse solution throttled API requests past a certain query volume, which made real-time reporting impossible at the scale they were now operating at.

Nobody had predicted this. At 30 people, the stack worked. At 80, it had quietly become a liability, costing more, covering less, and generating workarounds that swallowed engineering hours nobody had budgeted for.

This is the SaaS ceiling. Not a product failure, but a structural feature of how subscription software is built and priced: for acquisition, not for growth.

The build vs buy software question used to feel philosophical. For a growing number of companies, it is now urgent.

The SaaS Promise vs the SaaS Reality

SaaS won the 2010s on a straightforward argument: skip the infrastructure, avoid the upfront licence fee, get continuous updates without a procurement cycle. For companies at a certain size, that was a genuinely good deal. Faster to deploy than custom-built alternatives, easier to maintain, cheaper to start.

What the model was never designed for was a company that grows fast and develops its own operational complexity along the way.

Most SaaS pricing and architecture decisions reflect an idealised customer: steady headcount, predictable workflows, moderate data volumes. The product was built around the median. If you have grown past the median, you are now paying for a product that fits someone else.

A SaaS scalability ceiling is where that gap becomes expensive. The platform's standardised feature set, pricing model, or data architecture no longer matches how the business actually runs. That mismatch compounds quietly until it becomes visible as a budget problem, an engineering problem, or both at once.

The Five Ceiling Triggers

These are the forms it most commonly takes. One trigger alone is manageable. Three or four arriving together is when teams start asking whether there is a better way.

• Per-seat pricing bloat

At 50 users, the per-head cost is an acceptable line item. At 200, it has usually become a meaningful constraint on hiring decisions, which means the software is now influencing how the company grows.

• API rate limits

Platforms throttle requests, and the limits are designed around typical usage patterns, not yours. When your data pipelines hit those ceilings, the choice is pay for a higher tier or engineer around it. Both cost more than they should.

• Data portability lock-in

Operational data accumulates in the vendor's proprietary schema. Moving it out is technically possible but rarely straightforward, and often expensive. The longer you stay, the harder it gets.

• Workflow rigidity

Off-the-shelf tools are built for a representative customer. If your processes are specific to your market, your regulatory environment, or how your team works, the software will eventually ask you to change your process to match it rather than the other way around.

• Compliance gaps

Audit trails, data residency requirements, and granular access controls mean regulated industries need customisation that most SaaS vendors either cannot provide or charge heavily for. The standard configuration is rarely the compliant one.

The Klarna Signal

In 2024, Klarna dropped Salesforce and Workday. The Swedish fintech cited the cost and complexity of maintaining SaaS dependencies at its scale, and built internal tooling instead, consolidating its customer service operation onto a proprietary platform that the company reported had handled work previously done by around 700 contract agents, saving approximately $40 million annually.

Worth noting: the transition was more nuanced than the headlines made it sound. Some tools were swapped for other SaaS products, not custom builds. But the direction of travel was clear enough. When a company reaches a certain scale, the economics of owning your software start to beat the economics of renting someone else's.

Where SaaS Starts to Cost More Than It Saves

The subscription fee is rarely the actual cost. Most organisations discover this during a renewal conversation, when someone finally tries to add up what the tool actually costs to run.

The Real Pricing Maths

Take Salesforce Enterprise for a 25-person team: around $49,500 per year in licence fees. Add implementation, typically $5,000 to $50,000 for a mid-size deployment, a dedicated admin at $80,000 to $120,000 annually in most markets, and premium support tiers. The real cost of that single CRM routinely runs 30 to 40 per cent above the sticker price. And that is for 25 people.

Now consider that most organisations run 15 to 40 SaaS tools simultaneously. Few have ever modelled the aggregate cost of that stack against the cost of custom software development built around their specific workflows. The per-tool comparison is the wrong frame. The problem is the stack as a whole.

The Invisible Engineering Cost

Then there is everything that does not appear on any invoice. When SaaS tools fail to integrate cleanly, engineers write the connective tissue themselves: custom scripts, middleware layers, automation flows that break the next time a vendor updates their schema. This is bespoke software by stealth: built without a proper brief, maintained without clear ownership, and never counted on the balance sheet.

By the time the cost is visible, it has typically been accumulating for a year or more. Teams are so embedded in the workaround that the workaround has become the system.

The Signals That It Is Time to Build

There is no single trigger. What usually happens is that several things go wrong at the same time, and someone finally asks whether the stack is serving the business or the business is serving the stack. That question is the beginning of the custom software development conversation.

Here are four signals worth paying attention to.

Signal 1: You Are Paying for Seats, Not Value

Headcount decisions are being shaped by the per-user fee structure. A delayed hire, a reorganised team, a workaround built to avoid adding another licence, each is a small signal. Together, they mean the pricing model has become an operational constraint. The software is not just a tool at this point; it is influencing how the organisation is designed.

Signal 2: Your Workflows Are Shaped by the Tool Rather Than the Business

Someone on the product or operations team explains that a process works a certain way "because of the system." The system was supposed to serve the process. When it starts directing it instead, the inversion has happened. It rarely gets corrected from inside the SaaS relationship.

Signal 3: You Have Built More Integrations Than You Planned

Unplanned integrations are evidence that no single tool covers the actual use case. A few are fine. But once the integration layer grows complex enough to need its own maintenance, custom scripts, webhook chains, fragile middleware, you are already operating a bespoke system. A properly designed web application or business process automation layer would have been cleaner and cheaper to maintain at this point.

Signal 4: Your Data Cannot Leave Cleanly

Ask your engineering team what it would take to migrate away from your primary SaaS vendor. If the answer involves months of work, high cost, and material risk to operations, you are locked in. Data migration from a proprietary schema is almost always more involved than teams expect until they actually start scoping it.

When three or more of these are present simultaneously, the conventional wisdom, "SaaS is cheaper than building", deserves a harder look. It may have been true when you started. It may no longer be.

A Practical Build-vs-Buy Framework

The decision is rarely a clean either/or. Most organisations land somewhere on a spectrum, and the honest answer is usually "build some things, keep buying others." Five dimensions help make that assessment concrete.

Dimension 1: User Count and Growth Trajectory

At under 50 users, SaaS almost always wins. Faster to start, lower upfront cost, less risk. The comparison gets genuinely close somewhere in the 50-to-200 range, depending on the tool and the use case. Past 200 users or when headcount is growing fast enough that the per-seat bill is becoming a line item people argue over the cost structure starts working against you.

Dimension 2: Workflow Uniqueness

If your processes map cleanly onto what a SaaS tool does, custom development is probably not the right call. But most teams discover, once they start configuring, that the fit is 80 per cent. The remaining 20 per cent gets handled with workarounds. The question is whether that 20 per cent is peripheral or operationally central, because if it is the latter, the workarounds become load-bearing.

Dimension 3: Data Sensitivity and Compliance Requirements

Established SaaS vendors typically hold SOC 2 and ISO 27001 certifications. For low to moderate data sensitivity, that is usually sufficient. Where it breaks down is in regulated industries, where the specific controls go beyond what a standard configuration can deliver. GDPR consulting and cybersecurity considerations should enter this analysis early, not once implementation has already started.

A note on regulated sectors

Fintech and healthcare businesses run into this repeatedly. The push toward custom builds in those sectors is about being able to architect around compliance obligations from the start, rather than retrofitting a general-purpose platform to meet requirements it was not designed for.

Dimension 4: Integration Complexity

One to three connected tools is manageable in any stack. Four to ten is where maintenance burden starts to accumulate. Above ten integrations, or where proprietary legacy systems are involved, the integration layer becomes its own engineering problem, and a well-designed custom application is often simpler to maintain than the web of connectors holding the SaaS tools together.

Dimension 5: Five-Year Total Cost of Ownership

This is the dimension most organisations skip. SaaS starts cheap and gets more expensive as usage, headcount, and feature requirements grow. Custom software requires a larger upfront commitment and costs significantly less to run over time. Those curves cross at a point that varies by organisation, but for companies past a certain scale, custom is almost always cheaper by year three or four.

A useful rule of thumb: build what differentiates you, buy what does not. Commodity functions (email, payroll, basic HR) rarely justify the investment. Operationally critical workflows that are specific to how your business runs often do.

The Cost Question Nobody Asks Correctly

What does custom software development cost? It is the most common question in any build vs buy software analysis, and it is almost always framed incorrectly.

The right question is: what is the five-year total cost of each option?

Not the year-one cost. Not the licence fee versus project fee comparison. Custom software carries a higher upfront investment and a substantially lower ongoing cost. SaaS carries a low barrier to entry and a cost that rises with usage, headcount, and feature requirements. At some scale, different for every organisation, those two curves cross.

Why Business Analysis Changes the Outcome

The scoping and discovery phase is where the five-year cost comparison becomes credible rather than speculative. A structured business analysis engagement produces a detailed scope, a delivery estimate, and a maintenance model, the inputs needed to build a real comparison against the SaaS alternative.

Getting that framing right before the procurement conversation begins changes the outcome of the conversation.

What the EU Data Act Changes for SaaS Buyers

For companies operating within the EU, the calculus shifted further in September 2025.

The EU Data Act took effect on 12 September 2025. It requires SaaS and cloud vendors to remove contractual and technical barriers to switching, enable customers to export their data in machine-readable formats, and support transitions to competitors or in-house environments within 30 days. Contracts must include a maximum two-month cancellation period. From January 2027, fees for data transfers and reformatting must be phased out entirely.

What This Means for the Build vs Buy Decision

Data portability lock-in, one of the five ceiling triggers described above, is now legally constrained for EU-based buyers. Vendors cannot hold your data hostage the way they once could, and the contractual terms that made switching expensive are subject to the Act's requirements. The practical cost of moving away from an incumbent SaaS vendor has dropped.

For companies in the Netherlands, Sweden, and Denmark, this is worth factoring into any contract renewal conversation. The worst-case exit scenario from a SaaS vendor is now bounded by law. That changes the risk side of the build-vs-buy calculation.

How to Start Without Betting Everything

The main objection to building custom software is risk. A SaaS subscription is reversible. A poorly scoped custom software project is not.

This objection is real, but it overstates the choice on offer.

Start With One Workflow

Nobody is suggesting you decommission your entire SaaS stack in six months. The practical path starts with a single workflow, the part of your operation where the SaaS ceiling is most costly, where the workarounds are most labour-intensive, or where the data sensitivity is highest.

Commission a discovery session to scope what a custom build would actually require and what it would cost. Build an MVP against that single workflow. Measure the result. Extend from there.

What good CI/CD changes about ongoing cost

Maintenance cost is the objection that surfaces most often once teams get past the upfront investment question. It is a fair concern; poorly structured custom software is expensive to maintain. But a well-designed CI/CD pipeline from the start keeps deployment and ongoing costs much lower than most teams expect. You are not commissioning a monolith. You are building one well-scoped module, with the architecture already in place to extend it as requirements evolve.

The Dedicated Team Model

One route that reduces risk further is working with a dedicated development team rather than a fixed-scope project engagement. Dedicated teams adapt as requirements become clearer, which they always do. The flexibility that model provides is particularly valuable for companies making the transition from SaaS to custom for the first time.

The goal is not to replace SaaS everywhere. It is to stop letting standardised software set the ceiling for what your organisation can do.

Key Takeaways

The SaaS vs custom software question resolves differently depending on where you are in your growth curve. At low scale, SaaS wins on speed and upfront cost. At higher scale, the structural limits of standardised platforms become operational constraints that compound over time.

Four markers suggest the ceiling is close: per-seat pricing becoming an operational factor, workflows shaped by the tool rather than the business, unplanned integration proliferation, and data that cannot migrate cleanly. The EU Data Act has also reduced one of the traditional arguments for staying put, lock-in is now legally constrained for EU-based buyers.

The build vs buy software pros and cons debate resolves not with a general answer but with a five-year cost model specific to your stack and your scale. If any of the signals above are already visible, running that analysis now, before the next renewal cycle, is time well spent.

Talk to our engineers about where a custom build makes sense in your architecture.