The SaaS Ceiling: 5 Signals That Tell You a Tool Has Stopped Paying for Itself

What is the SaaS ceiling, and why does a cost comparison miss it?

The SaaS ceiling is the point where a tool stops being cheaper than building, not because its price rose, but because your business outgrew the shape of its data model. Cost comparisons miss it because the trigger is almost never the subscription line. It is the workaround labour underneath it.

Every build-versus-buy spreadsheet we have been shown compares a monthly subscription against a one-off development quote. That framing is wrong in both directions. It understates SaaS by ignoring the hours operators spend reconciling, re-keying, and patching around the tool's assumptions, and it overstates custom by treating the build as a single event rather than a system with a maintenance line.

The useful question is not what does each cost. It is which signals indicate the crossover has already happened. Below are the five we watch for. Each one is a condition you can check this week against your own tools, and each has a threshold that tells you whether you are approaching the ceiling or already through it.

Signal 1: per-seat pricing crosses your headcount curve

The first signal is per-seat pricing scaling with people who each use one feature. When a tool charges a full seat for someone who logs in twice a week to mark attendance or approve a request, and headcount is growing faster than revenue per head, the per-seat line becomes a tax on hiring rather than a cost of software.

The break is rarely a price increase. It is the moment a whole category of staff needs write access rather than read access. Shift leads, warehouse staff, field technicians, part-time coordinators: people who perform one or two actions and then close the tab. Each of them means another seat in the scheduling tool, another in the payments dashboard, and a shared-login workaround for anyone the budget cannot cover. Shared logins are the real tell. The moment your team starts sharing credentials to avoid a seat charge, you have already priced the tool above what it is worth to you, and you have created an audit problem at the same time.

The diagnostic is simple. Plot seats against the next twelve months of hiring, then split those seats by how many distinct actions each person actually performs. If a large share of your seats exist for one or two workflows, those workflows are candidates for a purpose-built, role-scoped screen inside a system you own, with the expensive SaaS retained only for the handful of power users who genuinely need its full surface.

• • Count seats where the user performs fewer than three distinct actions per week
• • Check whether shared logins exist and what they hide from your audit trail
• • Project the seat line against your hiring plan, not against last year's spend
• • Compare that projection to the cost of one custom role-scoped screen

Signal 2: your business logic does not fit the platform's data model

The second signal is when a core business rule can only be expressed as a workaround. If your product is a kit containing components with batch numbers and expiry dates, with a lab result attached downstream, and your commerce platform thinks a product is a SKU with a stock count, no app will close that gap permanently.

Off-the-shelf platforms model the transaction well. What they usually do not model is the chain of states that follows it: which batch of consumables went into a unit, when it shipped, when it was received, which run processed it, who was authorised to release the outcome. Approximating that with a stack of apps gets brittle fast, and each app is a separate vendor with a separate upgrade cycle and a separate place your data lives. Every one of those boundaries is a place where two systems can disagree about the same fact.

The tell here is not a price. It is a sentence someone says in a meeting: "we just have to remember to also update the other sheet." Any rule enforced by human memory rather than by the system is a rule you do not actually have. In a regulated context that is worse than inefficient, it is a compliance gap, which is why traceability belongs in the schema rather than bolted on afterwards.

Signal 3: you are paying for capacity units instead of value

The third signal is usage-metered pricing on rows, records, automation runs, or API calls, where the metered unit has no relationship to the value you get. When you start deleting old records to stay under a cap, or batching automations to conserve runs, the tool is shaping your operations instead of serving them.

The pattern that breaks metered pricing is fan-out. A marketplace order is one commercial event, but it produces line items, allocations, route stops, notifications, stock decrements, and status changes. The record count grows superlinearly against the thing you actually sell. Automation runs behave identically: one order can trigger four or five downstream actions, so a pricing tier sized against order volume is silently sized against something several times larger.

The diagnostic question is whether your record growth is linear or fan-out. Linear growth is survivable on metered pricing for a long time. Fan-out growth means you will hit the next tier sooner than your revenue supports, and the tier after that sooner still. The other symptom is archival: if the answer to "how did this order actually get delivered in March" requires an export you no longer keep, the tool has stopped being your system of record and nobody decided that on purpose.

• • Is your record count growing linearly with orders, or fanning out per order?
• • Are operators deleting or archiving data to stay under a cap?
• • Are automations being batched or disabled to conserve runs?
• • Can you answer a historical operational question without a manual export?

Signal 4: the export and API tax of getting your data back out

The fourth signal is discovering that your data is retrievable but not usable. Most tools will export. Fewer expose the relationships, the change history, or the fields that only exist inside their UI. The gap between an export and a migratable dataset is measured in engineer-days, and it grows every month you wait.

This is the cost that never appears in a build-versus-buy comparison, because it is only paid once and only at the moment you leave. It typically includes three things: writing an extraction layer against an API designed for integrations rather than bulk reads and therefore rate-limited, reconstructing relationships the platform stored implicitly, and recovering history that was never modelled as events in the first place. That last one is the expensive one. If a tool stored current state only, the transition history that made your business explicable is simply gone, and you either accept the gap or reconstruct it from emails and invoices.

Two practical mitigations. First, run a test export from every core tool now, while you are not migrating, and check whether the file contains identifiers you can join on. Second, price the exit at the point you buy, not at the point you leave. A tool that will cost twenty engineer-days to escape is more expensive than its monthly line suggests, and that number belongs in the decision.

Signal 5: the workaround headcount, and how to run the check on yourself

The fifth signal is the clearest and the most ignored: a person, or a meaningful fraction of one, exists to move data between tools. When copy-paste, reconciliation, and "checking both systems match" are recurring named tasks on someone's week, you are already funding a custom integration. You are just funding it with salary instead of software.

This is where the economics actually flip, because that labour is recurring, compounding, and error-prone, while a build is a fixed cost with a maintenance tail. Our rule of thumb is to count the hours, not the frustration. Log the recurring manual tasks for two weeks, attach a duration and a frequency to each, and convert to an annual hours figure. Then ask which of those hours would still exist if the two systems shared a database. Some would. Judgement calls, exception handling, and anything requiring a phone call do not disappear because you built software.

Run all five checks together, because one signal alone rarely justifies a build. Two or more, sustained across a quarter, usually does. The order matters too: the cheapest fix is almost never a full replacement. Often the right move is to keep the SaaS that handles a commodity function well, such as payments or email, and build only the layer that encodes rules nobody else can express for you.

• • Seats: are you paying full price for single-action users, or sharing logins?
• • Model fit: is a core rule enforced by human memory rather than the system?
• • Metering: is your record or run growth fanning out rather than growing linearly?
• • Exit: how many engineer-days to extract joinable data with history intact?
• • Labour: how many annual hours go to moving data between tools?

If you have already decided the ceiling is behind you, the mechanics of the move are in our spreadsheets-to-internal-system migration playbook, which covers auditing hidden business rules, cleaning dirty history, and running both systems in parallel.