Per-Seat SaaS Is Eating Your Business. AI Just Made the Alternative Real.

Pull up the most recent invoice from any of your major enterprise SaaS vendors and look at two numbers: the seats you committed to, and the seats anyone actually used last month.

For the typical mid-market company we talk to at Clever Solutions, the gap is roughly: you prepaid for 1,000 seats, 750 of them logged in, and of those 750, maybe 200 used the product the way it was designed to be used. The rest opened it once a week to do one thing. You paid the same rate for the heavy user, the casual user, and the seat that hasn't been touched since onboarding. The renewal arrives in eleven months with a double-digit price increase and a new AI bundle "included" whether you asked for it or not.

This isn't a story about $30/user being too much. It's a story about a business model — prepaid, per-seat, escalating, and structurally bloated — that solved real problems twenty years ago and now creates more problems than it solves for most of the work it's used for.

For the last two decades, paying for SaaS was the obviously rational thing to do. Custom software cost six figures, took eighteen months, and broke when the original developer left. Per-seat SaaS shipped in a week and the vendor maintained it forever. That trade was honest then and the next section gives it full credit.

The trade isn't honest anymore. The cost side has gotten worse (you'll see how) and — for the first time — there's a real third option that gives you what SaaS originally promised without the bloat or the prepaid waste.

The data: it's not the per-seat price, it's everything around it

Three numbers that matter more than the headline rate per user:

• The seats you don't use. Productiv's research shows that less than half of licensed employees regularly use the apps they have access to — average engagement runs around 45%. The per-seat model gives you no way to pay only for active usage — you committed at contract signing, and the unused half is gross margin to the vendor.
• The features you don't use. The average enterprise SaaS product now ships with several times the surface area it had five years ago, and feature adoption is brutal: Pendo's Feature Adoption Report — the canonical industry data on this — found the average software feature has just a 6.4% adoption rate, and nearly 80% of features see little or no usage. You are paying for the eighteen integrations, the four reporting modules, the workflow engine, and the marketplace ecosystem that exists for somebody else's industry.
• The escalator. Independent SaaS-pricing trackers report double-digit annual price increases as the new normal — Vertice's 2026 SaaS Inflation Index measured an average 12% jump, well ahead of inflation, now routinely with AI feature bundles stacked on top — Copilot at $30/user/month, Einstein at $50, Slack AI at $10, Notion AI at $8 — for AI features that are, by independent benchmark, the same frontier models the vendor is reselling through their UI.

These are not three independent problems. They are the same structural problem — the per-seat, prepaid, ever-broadening model — observed from three angles. We will get to why every successful SaaS bloats over time, why your seat count never goes down even when your usage does, and what changes when an AI-driven alternative removes both pressures at once.

Is this you?

Before the rest of the analysis, an honest gut check. You probably have a SaaS-replacement opportunity worth looking at if you can answer "yes" to three or more of these:

• You signed a SaaS contract more than 18 months ago and have not seriously audited usage since.
• A major SaaS line item costs you more than $30K/year and the team uses fewer than half the features.
• A vendor raised your price more than 10% at the last renewal, and the "new AI features" justifying the hike are not features your team actually uses.
• The tool requires a workflow your business doesn't actually run — and your team has built spreadsheets, manual processes, or another tool around it just to make it work.
• You have at least one seat-based tool where some seats only log in once or twice a month.
• Switching off this tool would not break a regulated workflow (payroll, identity, payments processing).
• You have wondered, even once, whether you could "just build something that does what we actually need."

If two or fewer apply, the rest of the post is interesting context but not urgent. If five or more apply, the math is probably already against your current setup — keep reading.

What SaaS legitimately solved (and what hasn't gone away)

Before going further, full credit to the model. SaaS won the last twenty years for real reasons, and any honest alternative has to actually solve those reasons — not just be cheaper.

Pre-SaaS custom software had four hard problems:

1. It didn't keep pace. The day you finished building it was the day it started falling behind your competitors, your industry, and your own changing operations. Six months later it was already partly obsolete. Two years later it was holding you back.
2. The bus factor was brutal. The institutional knowledge of how the system actually worked lived in two engineers' heads. They left, got sick, retired, or simply got bored — and your software became unmaintainable overnight. Replacing them cost a year and they were never as fast on it as the originals.
3. The capital expense was unbearable for most businesses. Six figures up front, eighteen months until anything shipped, no idea whether what you built would actually work in practice.
4. Risk was concentrated. Every dollar and every month was your dollar and your month. If the project failed, you ate the entire loss.

SaaS solved all four in one move. The vendor's engineers kept the product current — your software improved every month without you doing anything. The vendor's institutional knowledge was distributed across an entire engineering org, not two people who could quit. The capital expense flattened into a monthly subscription you could budget and cancel. And the risk was spread across thousands of customers paying the vendor to figure things out once.

Those four problems have not disappeared. Anyone telling you to walk away from SaaS without solving them is telling you to walk into the same trap that made SaaS attractive in the first place. The interesting question is not "is SaaS bad?" — it's "is there now a way to get the original SaaS benefits without the prepaid-seat-and-bloat tax?" Hold that question; we come back to it.

Why every successful SaaS bloats over time (and why this hits you, not them)

The per-seat model has a built-in growth ceiling. Every SaaS company eventually saturates the natural market for what it originally did. To keep the revenue line going up — for investors, for the next funding round, for the public-market story — there are only two levers: charge more per seat, or expand the surface area to attract new customers and new use cases.

So that's what they do. Every successful SaaS, without exception, broadens over time:

• A CRM adds a marketing automation module to compete with HubSpot.
• The marketing automation module gets a CMS to compete with Webflow.
• The CMS adds analytics to compete with Mixpanel.
• The analytics get an AI assistant to compete with ChatGPT.
• A customer-success module appears to compete with Gainsight.
• A revenue-intelligence layer arrives to compete with Gong.
• An app marketplace launches because every adjacent SaaS launched one.

Each of those features is built for a different customer than you. Each one has to be designed, built, tested, supported, documented, sold against competing tools, and integrated with the rest of the product. The vendor's engineering org spends an increasing share of its capacity maintaining surface area instead of improving the parts you actually use.

The downstream effects are the ones you feel:

• Innovation in the parts that matter to you slows down. The roadmap meeting now has eleven verticals fighting for the same engineers.
• The product gets harder to use. Every new module adds nav, settings, integrations, and edge cases. The "fast modern UI" gradually becomes the next thing you're complaining about.
• Your specific bug fix or feature request keeps losing. It's competing with requests from customers in industries you don't even share.
• Maintenance gets fragile. A change to the marketing module breaks something in your invoicing flow because the platform underneath them is older than either of them. Your ops lead finds out from a Friday afternoon Slack message.
• The price keeps going up to fund the bloat that isn't for you. The double-digit renewal escalator partly pays for the modules you don't use, sold to customers who aren't you.

This is not a failure of any particular SaaS company. It is the structural endpoint of the per-seat business model interacting with public-market growth expectations. Every successful SaaS bloats. The only question is whether you are paying for your SaaS to bloat past usefulness for your specific business.

The build-side has changed even faster

Here is the part that answers the question we left open: AI inside a structured delivery environment now solves the original problems SaaS solved — keeping pace, surviving staff turnover, low capital expense, distributed risk — without the prepaid-seat-and-bloat tax.

Each of the four legitimate reasons SaaS won has a 2026 answer:

• "It didn't keep pace." Frontier AI inside a structured delivery environment can ship a feature in days that used to be a quarter of internal-engineering work. The bottleneck moves from "how fast can we build?" to "how clearly can we describe what we want?" The vendor's update cadence stops being a competitive advantage.
• "The bus factor was brutal." This is the bigger shift, and it is not what most people expect. The institutional knowledge of how the system works no longer has to live in two engineers' heads — it lives in enforceable rules and contracts the AI environment checks on every change. When the original developer leaves, the next engineer (or the next AI session) inherits a codebase that knows what it is supposed to be. This is exactly what we built CleverADE for, and it's why our deliverables don't become legacy when staff turns over.
• "Capital expense was unbearable." The cost of custom software has compressed by roughly an order of magnitude since 2022. Engagements that would have been six-month projects in 2020 — internal CRM replacement, custom analytics dashboard, mobile companion app — are now four to eight weeks in well-run shops.
• "Risk was concentrated." A delivery model with structured governance, enforceable contracts, AI-enforced patterns, and source-escrow ownership terms (more on those below) spreads the operational risk across the substrate, not just the team. You are no longer betting the project on two engineers staying employed.

Meanwhile, the risk and cost of buying has gone up. SaaS contracts now lock customers into multi-year commitments, with double-digit annual escalators, mid-contract repricing of "AI feature bundles," and a steady erosion of features moved into "premium tiers" the customer did not sign up for. The asymmetric risk has reversed.

And — critically for the post's central point — the agentic alternative breaks the prepaid-seat model entirely. You're not buying 1,000 seats and using 750. You are paying for actual usage: an inference bill that scales with what you actually run, plus an optional retainer if you want a named partner on call. Heavy users and casual users no longer pay the same rate. Idle capacity isn't a line item. And nothing in the product was built for an industry you don't operate in.

When SaaS is still the right answer

Before going further: this post is not anti-SaaS. A serious build-vs-buy analysis has to name the cases where SaaS still wins, and there are several.

• Commodity workflows where you do not differentiate. Payroll, identity (Okta, Auth0), email, calendaring, payments rails (Stripe), basic accounting. The compliance burden is high, the differentiation potential is zero, and the SaaS vendor's cost-per-customer is a tiny fraction of what yours would be running it yourself.
• Specialized vertical tools built by small teams who understand their domain better than you ever will. Linear for engineering project management, Vercel for frontend deployment, Stripe for payments, Cursor for AI-assisted coding — these earn their seat price because the team building them is genuinely 10 years ahead of anything an internal team would build.
• Anything regulated where the SaaS vendor's certifications (SOC 2, HIPAA, PCI-DSS) substantially reduce your audit burden. Replacing a HIPAA-certified scheduling tool to save $30K/year is a poor trade if it costs you $200K and six months of compliance work.
• Anything you use heavily and the pricing scales sensibly with your usage. If 90% of the seats actually log in every day and the renewal escalator is in single digits, the SaaS is doing its job.

The SaaS argument breaks down at the long tail of seat-based tools where you use 8% of the product and pay for 100%, where the renewal escalator is double-digit, where the workflow doesn't fit, and where the differentiation potential is real. That's the part of the SaaS bill that's worth examining.

Why most "let's build it ourselves" attempts still fail

The honest version of this story has to acknowledge that most companies who try to replace a piece of SaaS with a bespoke build still fail. The reasons are well-documented:

1. The 70/30 Agentic Paradox. A foundation model gets you to a working sketch in an afternoon. The remaining 30% is fractal — every push closes 70% of the gap and somehow leaves 30% behind. (We wrote a whole post on this.) Internal teams burn out in the second month, when the prototype that "demoed great" cannot survive contact with real users.
2. No governance. Internal builds done with generic AI assistance accumulate the same drift the rest of the industry is now publicly cataloguing — three error handling patterns, two data models, mixed async approaches. Six months in, the bespoke tool is harder to maintain than the SaaS it replaced.
3. No delivery model for handoff. Even if the build succeeds, the institutional knowledge lives in two engineers' heads. When they leave, the tool becomes legacy.
4. No bundled infrastructure. Internal teams underestimate the operational tax of running their own database, queue, cache, and deployment pipeline. The "we can build it" budget never includes the eighteen months of platform work.

The math, with maintenance honestly included

You do not have to take a position on AI to do this calculation. Here is a worked example for a hypothetical mid-market company on a SaaS contract for 1,000 prepaid seats — of which roughly 750 actually log in each month and 200 use it heavily.

The agentic-build alternative breaks this shape entirely. Costs scale with actual usage — an inference and hosting bill that rises and falls with what you actually run, plus a one-time build cost and an optional maintenance partnership for ongoing changes. Exact range depends on the workflow being replaced; we scope it on the first call.

Three ways to engage Clever

If a SaaS line item has been bothering you — if the renewal email triggers a sigh, if your team has built spreadsheets around it, if the price is going up faster than the value — three places to start, smallest to largest:

1. Free 30-minute conversation. No prep, no tech vocabulary required, no obligation. Send your top 1–3 SaaS line items in advance for a more concrete read. We'll tell you honestly which (if any) are worth replacing, what the engagement would look like in time and cost, what you'd own at the end, and whether Clever is the right team. Book it.
2. Focused workflow replacement. One painful SaaS line item replaced by a tool that fits 100% of your workflow, with the asset on your balance sheet at the end. Typically a matter of weeks.
3. Multi-system replacement or significant migration. Multiple tools consolidated, legacy systems modernized, ownership terms that put the deliverable on your infrastructure and standards in your repo. Typically a matter of months.