The 80% You Don't Use: The Per-Seat SaaS Trap
Per-seat SaaS taxes every hire and bills you for features you'll never touch. The build-vs-buy math just quietly flipped for the long tail of internal tools.
Per-seat SaaS pricing taxes the two things a growing company does most: hire people and add tools. You pay for every employee whether they use the product daily or twice a quarter, and you pay the same monthly rate for software where your team touches maybe 20% of the features. For commodity systems—email, payroll, the CRM everyone already knows—that trade is worth it. For the long tail of tools that encode how your org specifically works, it has quietly stopped being worth it. The build-vs-buy calculus for internal software has flipped, and most companies are still budgeting as if it hasn’t.
Generic SaaS won the last two decades by default, not because it fit. It won because building was too expensive to be a real alternative. That constraint is the thing that changed.
TL;DR
- Per-seat pricing charges you for headcount, not value: every hire raises the bill on tools they may barely open, so growth itself becomes a recurring tax.
- Most teams use a small fraction of any given SaaS product, yet pay the full per-seat rate for the other 80%—features built for a composite customer who isn’t you.
- The reason generic SaaS won was economic: building used to cost more than buying for almost everything, so off-the-shelf tools became the default even when they fit no one well.
- The right move for commodity systems is still to buy—nobody should build their own payroll engine—but the long tail of org-specific internal tools is a different calculation.
- That long tail never got built because the per-tool cost of custom software—engineers, timelines, maintenance—dwarfed a SaaS subscription, so it stayed in spreadsheets or got forced onto a tool that almost fit.
- When describing an app in plain language and compiling it makes a working full-stack tool cost roughly the price of a single SaaS seat for one month, the long tail of “build what’s yours” finally pencils out.
- The winning org doesn’t rip out its commodity SaaS; it buys the commodity and builds what’s specific to it, stopping the per-seat tax on the tools only it would ever use.
Why does per-seat pricing punish growing companies?
Per-seat pricing ties your software bill to your org chart instead of to the value you get. Add a salesperson, add a seat. Onboard a contractor for a quarter, add a seat. The vendor’s revenue scales with your headcount, which is exactly the variable a growing company least wants to make more expensive. You’re taxed for hiring—the one activity that’s supposed to be a sign of health.
The waste compounds because seats and usage rarely match. A license bought for a role that does the work twice a month costs the same as one used eight hours a day. Across a portfolio, this adds up fast: Zylo’s 2025 SaaS Management Index pegs average SaaS spend at $4,830 per employee, up 21.9% year over year, and finds organizations wasting an average of $21 million annually on licenses nobody uses. That waste isn’t a procurement failure. It’s the pricing model working as designed—you commit to seats in advance, and reality never matches the forecast.
There’s a second tax stacked on the first: the feature tax. You pay for the whole product even though your team lives in one corner of it. Which brings up the deeper problem with buying generic software for specific work.
What’s the real cost of paying for the 80% you don’t use?
Every SaaS product is built for a composite customer—an average of thousands of companies, none of which is yours. To sell to all of them, the product has to include every feature any meaningful segment might want. So you buy a tool with ten capabilities, use two, and configure around the other eight. The unused 80% isn’t free padding. It’s complexity your team navigates around, settings someone has to govern, and surface area that shapes your workflow to fit the tool instead of the reverse.
This is the part the invoice never shows. The visible cost is the per-seat line item. The hidden cost is the fit gap—the daily friction of running your specific process through software designed for a generic one. Your ops team builds a shadow spreadsheet to bridge what the tool won’t do. Your RevOps lead wires three apps together with an automation to recreate one workflow the vendor didn’t anticipate. The work gets done, but you’re now maintaining the gap between how the software works and how your company actually works.
For commodity functions, that gap is small and the trade is obviously worth it. For the tools that encode something specific about your org—your approval chain, your inventory logic, your onboarding sequence—the gap is the whole point, and buying generic guarantees you’ll never close it.
When should you buy, and when should you build?
The honest answer is a split, not a slogan. Some software you should never build, and some you increasingly should. The line falls on whether the tool is a commodity or whether it encodes something specific to how your organization runs.
| Buy the commodity | Build what’s yours |
|---|---|
| Payroll, email, accounting, core CRM | The approval flow that’s unique to your org |
| Regulated or security-critical systems | Trackers, internal portals, request queues |
| Anything an entire industry does identically | The spreadsheet five people depend on daily |
| Software where the vendor’s scale is the value | Tools shaped around one team’s specific workflow |
| Categories with deep, mature ecosystems | The long tail no vendor will ever build for you |
The left column is genuinely better bought. A vendor amortizing a payroll engine across ten thousand customers will always beat your in-house version, and the compliance surface alone makes building it reckless. Buy it, pay per seat, move on.
The right column is where per-seat SaaS has always been a poor fit and a worse value—because these tools are specific by definition. No vendor builds the tool that matches your exact process, so you either force your process onto a generic product or you don’t build it at all and it lives in a spreadsheet. The long tail of internal tools is enormous, and historically almost none of it got built.
Why didn’t companies just build the long tail themselves?
Because the per-tool economics were brutal. Building custom software meant a developer, a timeline measured in months, and a maintenance burden that never ended. Against a $15-a-seat subscription that worked today, a six-month internal build that you’d then own forever was an easy no. So the long tail stayed unbuilt. Teams either bent their process to fit a generic tool, stitched several together, or ran the whole thing out of a spreadsheet and hoped the analyst who built it never left.
This is the quiet reason generic SaaS dominates. It wasn’t that off-the-shelf software fit better—it usually fit worse. It’s that building was so expensive that buying won almost every comparison, even the ones it should have lost. The default wasn’t a verdict on quality. It was a verdict on cost.
Which means the entire build-vs-buy framework rests on one assumption: that building is the expensive option. Loosen that assumption and the whole calculation moves. Half of business technologists already build technology used beyond their own department, according to Gartner—the demand to build was always there. What was missing was a way to build that didn’t require routing every idea through an engineering queue.
What flips the build-vs-buy decision?
The decision flips when the cost of producing a real, working tool drops far enough that the long tail finally pencils out. Not a prototype, not a no-code toy that breaks at the first real requirement—a genuine full-stack application with a backend, a database, auth, and a live URL, built fast enough and cheap enough to compete with a subscription you’d otherwise renew forever.
For most of computing history, the obvious way to chase that was to make engineers faster. That’s what an AI coding assistant does—Cursor, GitHub Copilot, Claude Code are excellent at it. But they operate at the code layer and assume engineering skill, so handing one to a finance analyst or an ops lead doesn’t remove the barrier; it relocates it. You still need an engineer to drive the tool, which means you’re still in the queue you were trying to escape. Making engineers faster doesn’t reach the long tail, because the long tail was never engineering’s to build—it belongs to the people who own the workflow.
What reaches the long tail is letting those people describe what they need and getting a real app back. That’s a different category of tool, operating at a different layer—and it’s what makes the rest of this argument actionable.
A product agent is an AI tool that takes a plain-language description of an application and compiles it into a real, deployed full-stack app—backend, database, authentication, frontend, and deployment—rather than a screenshot or a frontend you keep re-prompting. Today the most advanced one is Remy. You describe the tool your team needs; it drafts a plain-language plan; that plan compiles into a working app with real server-side auth, real data, and a live URL—at roughly $30–40 of inference per build, about what one SaaS seat costs for a single month. The plan is the source of truth, so changing the tool means editing the plan and recompiling, not maintaining code by hand.
That cost is the number that moves the calculation. When a working internal tool costs about the same as one month of one seat, the long tail of “build what’s yours” stops being a six-month project you’ll never approve and becomes a Tuesday-afternoon decision. You still buy the commodity—payroll, email, the core CRM. But the approval flow, the tracker, the request queue, the spreadsheet five people depend on—the things no vendor will ever build for your org specifically—you build, and you stop paying per seat, forever, for software you only ever needed one copy of.
One honest boundary: product agents are in open alpha, and enterprise needs like SSO and SAML aren’t there yet, so the commodity systems that demand them stay bought for now. That’s consistent with the argument—buy the commodity, build the long tail. The shift isn’t ripping out your SaaS stack. It’s refusing to keep renting the 80% you’ll never use on the tools only you would ever need.
FAQ
What is per-seat SaaS pricing? Per-seat pricing charges a recurring fee for every individual user with access to a software product, regardless of how much each user actually uses it. The total bill scales with headcount, so adding employees or contractors raises the cost even when their usage is minimal.
Why is per-seat pricing considered a tax on growth? Because the cost grows with the org chart rather than with the value delivered. Every hire adds seats across multiple tools, and most of those seats are underused—Zylo’s research puts average annual unused-license waste at around $21 million per organization—so scaling the team automatically scales the waste.
Does this mean companies should stop buying SaaS? No. Commodity systems—payroll, email, accounting, core CRM, anything regulated or industry-standard—are still better bought, because a vendor’s scale and compliance investment beat anything built in-house. The shift applies to the long tail of org-specific internal tools, not the commodity stack.
What’s the difference between buying the commodity and building what’s yours? Commodity software does something every company does identically, where a vendor’s scale is the value. “What’s yours” is software that encodes a process specific to your organization—an approval chain, a tracker, an internal portal—that no vendor builds for you, so generic SaaS always fits poorly.
Why didn’t companies build their own internal tools before? Because building meant engineers, multi-month timelines, and permanent maintenance, which dwarfed a monthly subscription. Buying won almost every comparison purely on cost, even when the off-the-shelf tool fit the org’s actual workflow badly.
What changed in the build-vs-buy decision? The cost of producing a real, working full-stack tool dropped sharply. When describing an app and compiling it costs roughly one SaaS seat for one month, the long tail of internal tools that never justified an engineering project suddenly does.
One coffee. One working app.
You bring the idea. Remy manages the project.
Can’t an AI coding assistant build these tools? Coding assistants like Cursor, Copilot, and Claude Code are excellent for engineers, but they work at the code layer and assume engineering skill. Handing one to a non-engineer relocates the barrier rather than removing it—you still need a developer, so you’re still in the engineering queue.
The bottom line
Per-seat SaaS won because building used to be the expensive option, so buying generic software—and paying for the 80% you don’t use, on every seat, forever—was the rational default. That default rested entirely on the cost of building. Once describing a tool in plain language and compiling it costs about a single seat for a single month, the long tail of org-specific software flips from “never worth it” to “obviously worth it.” Buy the commodity; build what’s yours.
To see what building what’s yours looks like in practice, explore Remy →. For more on why fragmented tools cost more than their invoice, read the real cost of SaaS sprawl and what the winning org looks like.
