The first thing most people do when they consider replacing a SaaS product is open its pricing page and start a spreadsheet. Two columns: what it does, whether we can do it. One hundred and forty rows later, the project is obviously impossible and everyone goes back to work.
That spreadsheet is measuring the wrong thing. A pricing page is not a description of a product. It is a sales artefact, accumulated over a decade, in which every bullet exists because a prospect once said no and a product manager made sure they would not say no again. Nobody uses all of it. Nobody uses most of it. The vendor knows this, which is why the list is on the page rather than in the product.
The distribution is always the same shape
Every usage audit we have run has produced a curve of the same shape. A small number of capabilities carry almost all of the work. Then there is a shoulder of features used by one team, for one process, that they would genuinely miss. Then a long tail where each individual feature is touched by well under one percent of users, most of them administrators evaluating whether to turn it on.
The tail is not evidence that the product is bloated. It is evidence that the product serves thousands of organisations and you are one of them. You are not buying the tail. You are paying for it, which is a different sentence.
How to get the numbers
This is unglamorous and takes about a week. Do it before you talk to anyone about replacement, including us.
- Export ninety days of audit or activity log. Most enterprise tiers expose this; if yours does not, that is itself a finding, and it belongs in the risk register rather than in a footnote.
- Count distinct active users, not licensed users. Then count distinct users who did anything beyond read.
- Group events by capability, not by endpoint. "Created an automation" is a capability. "POST /v2/rules" is not, and grouping by endpoint will make an API integration look like a power user.
- For each capability, record the number of distinct humans and the number of distinct teams. A feature used heavily by one team is a different risk from one used lightly by twelve.
- Then interview the top three teams by usage and ask them what they do in a week. The log tells you what happened. Only people tell you what it was for.
The output is not a report. It is a ranked list of capabilities with a headcount against each, and it is the only input that matters to the scope of the build.
Three kinds of feature
Load-bearing
Used weekly, by many people, in a process that would stop without it. Boards and views in a work management tool. Escalation policies in a pager. Ticket routing in a service desk. These get built, tested and migrated, and they are where the estimate lives.
Decorative
On the pricing page, in the demo, in nobody's week. Sentiment analysis on ticket text that no one has read the output of. A goals module that was configured once at a kickoff. Reporting dashboards last opened eleven months ago. These do not get built. They get listed, in writing, as not built, so that no one discovers the decision in month four.
Hostage
One capability, used by one team, which is genuinely load-bearing for that team and disproportionately expensive to rebuild. A certified payroll calculation. A court-tested signature audit trail. An integration with a supplier network that only that vendor has. The hostage feature deserves its own decision, made deliberately and early, and there are only three honest answers: build it and pay for it, keep a small licence alongside the owned system, or change the process. Pretending it is a detail is how replacements fail.
Why parity is the wrong target even when it is achievable
Parity means "as good as". It sets your ceiling at the incumbent, and it spends your entire budget getting there. It also imports the incumbent's compromises, most of which exist because of their business model rather than yours.
Per-seat pricing is the clearest example. Work management products separate viewers from contributors because charging for both is how they make money. When the system runs in your own account, that distinction is a boolean on a row, and the correct number of viewer seats is everyone. Build for parity and you will faithfully reproduce a licence tier that exists to bill you.
The right target is narrower and more useful: the workflow completes, with fewer steps, for the people who actually do it. That is measurable in the audit log you already pulled, and it gives you permission to build things the incumbent does not have — slip detection on a dependency graph, an alert route that survives your own outage, a report your finance team can join against the general ledger because both live in the same database.
Say no in writing, early, and in the same document
Every application in Techtons ships with a parity matrix containing at least two rows where the honest answer is no. That is a rule, not an accident. A parity table with no "no" rows is a marketing document, and the reader knows it.
The rows marked no are the ones worth reading. If one of them is the reason you bought the product, the correct decision is to keep paying the vendor, and it costs everyone far less to establish that on the first call than in the fifth month of a build.
A parity table with no "no" rows is not a parity table. It is a brochure with a grid on it.
What a two-week scoping exercise actually contains
Week one is measurement. Audit log export, capability ranking, invoice reconciliation against the licence console, and interviews with the three heaviest teams. No architecture, no opinions about technology.
Week two is arithmetic and refusal. The capability list is split into load-bearing, decorative and hostage. The load-bearing set is costed as a build with a date. The hostage items get an explicit decision each. The infrastructure is priced against your own cloud account rather than a generic estimate. And the parity matrix is written with its "no" rows filled in first, because those are the rows that determine whether the project should exist.
The deliverable is short. Roughly: here is what your people use, here is what we would build, here is what we would not, here is what it costs to build and to run, here is the payback, and here is the case in which you should not do this.
The size of the lever
Scope discipline is not a project-management nicety in this work. It is the difference between an eight-week build and a two-quarter one, and since the build is the largest single number in the payback calculation, it is usually the difference between a replacement that pays back inside fourteen months and one that never does.
Which means the most valuable week of a SaaS replacement is the one before anyone writes code, spent counting what people actually do. It is also the week that is easiest to skip, because the pricing page is right there and the spreadsheet fills itself.
Prices quoted here are vendor list prices with the date we checked them. If a figure has gone stale, tell us and we will correct it — support@conseiltek.com.