Every SaaS Tool Is Built for a Company That Isn't Yours
Generic SaaS is designed for the average company, so it fits no one exactly. The orgs that win stop bending their work to fit the tool—and build the fit themselves.
Every SaaS product your org buys was designed for a company that doesn’t exist: the average one. The vendor studied a thousand customers, found the median workflow, and shipped the tool that fits that median. Your company isn’t the median. So the tool fits you the way an off-the-rack suit fits—close enough to wear, wrong in the places that matter. The winning org stops treating that gap as the cost of doing business and starts closing it, because the economics of building the missing fit just changed.
That’s the quiet tax most leadership teams never name. The license fee is visible. The fit gap—the workarounds, the exported spreadsheets, the three tools duct-taped together to do what one tool should—is invisible, and it’s the larger cost.
TL;DR
- Generic SaaS is built for the statistical average of its market, which means it fits every individual company imperfectly—and the more specific your workflow, the worse the fit.
- The real cost of that mismatch isn’t the subscription; it’s the layer of human workarounds your teams build on top to make a near-fit tool actually match how the work is done.
- Organizations respond by either bending their process to fit the tool or paying to over-customize a generic platform—both of which trade away the thing that made the process theirs.
- More than half of businesses don’t fully use the software they pay for, because vendors ship breadth to win the average buyer, not depth for any one buyer’s real workflow.
- Buying still makes sense for commodities—email, payroll, video calls—but for the workflows that are specific to how your company runs, generic tools structurally can’t fit.
- The orgs pulling ahead let the people closest to a workflow describe the tool they actually need instead of filing a request and waiting two quarters for an approximation.
- What changed is the cost of building: when a custom internal tool costs tens of dollars instead of a six-month project, the build-vs-buy math flips for the long tail of work that no vendor will ever serve.
Why does generic SaaS fit no one exactly?
Because a SaaS vendor sells to a market, not to you. To win the most customers, the product has to serve the widest plausible set of workflows, so it’s engineered around the median use case and padded with configuration options for everyone on either side of that median. The result is a tool that is broadly acceptable to thousands of companies and precisely right for none of them. Your approval flow has four steps and a conditional exception the vendor’s two-step template doesn’t model. Your inventory has a category that doesn’t map to any field they offer. So your team improvises in the margins.
This isn’t a knock on the vendors. Building for the average is the only rational strategy when you’re selling one product to a whole market—depth for one customer’s exact workflow doesn’t sell to the next thousand. The mismatch is structural, baked into the business model of selling the same software to everyone. It’s why more than 50% of businesses don’t fully use the software they pay for, per JumpCloud’s analysis: the breadth that wins the average buyer is exactly the breadth no single buyer needs. It’s also why per-seat SaaS pricing has become a tax on the 80% you don’t use—you pay the full rate for features built for someone else’s workflow.
And the tools keep multiplying. Organizations now run an average of 106 SaaS applications, down only slightly from 112 the year before, per BetterCloud’s 2025 State of SaaS report. Each one was bought to close a fit gap the last one left open. The sprawl isn’t a buying mistake—it’s what happens when you try to assemble a company-shaped solution out of market-shaped parts.
What does the fit gap actually cost?
The subscription line item is the cheap part. The expensive part is the human layer your org builds to compensate for the gap between what the tool does and what the work requires.
Picture an operations lead who runs vendor onboarding. The procurement SaaS handles purchase orders, but it has no concept of the security review their company requires before a vendor goes live. So the ops lead keeps a side spreadsheet, copies data between the two, chases approvals over email, and stitches the real process together by hand. They’ve done this four hundred times. They know exactly where it breaks. The tool didn’t automate their workflow—it automated a generic workflow next to theirs, and left them to bridge the difference manually, forever.
Multiply that across departments and the cost compounds in three ways:
| Cost of the fit gap | What it looks like | Who pays it |
|---|---|---|
| Manual workarounds | Side spreadsheets, copy-paste between tools, email chains the tool can’t see | The people doing the work, every day |
| Process distortion | The team changes how it actually works to match what the tool allows | The org—it loses what made the process its own |
| Tool sprawl | A new SaaS purchase to patch each gap the last tool left | IT budget and the org’s ability to see across its own stack |
None of these show up on the invoice. All of them are real. The fit gap is paid in time, in workarounds, and in the slow erosion of processes that used to be a company’s edge until they got flattened to fit a vendor’s template.
Can’t you just customize the generic tool?
To a point. Most enterprise SaaS ships configuration, custom fields, and an integration marketplace precisely because vendors know one size won’t fit. But configuration has a ceiling. You can rename a field; you can’t add a workflow stage the data model doesn’t support. You can wire two tools together with an automation; you can’t make them share one source of truth. Past a certain depth of specificity, “customize the platform” becomes “hire a consultant to bend the platform,” and the customization itself becomes a thing to maintain, document, and re-do at the next upgrade.
This is the trap that swallowed the low-code era. The pitch was right—let the people who understand the workflow shape the software. Gartner projected that by 2025, 70% of new applications would use low-code or no-code technology, up from less than 25% in 2020, with much of that work done outside formal IT. But low-code customization still ran inside someone else’s platform, with that platform’s data model, limits, and lock-in. You got a faster way to approximate the fit—not the fit. The approximation was better than the off-the-rack tool. It still wasn’t yours.
When should you build instead of buy?
The line is commodity versus core. Some software is genuinely a commodity: email, payroll, video conferencing, accounting ledgers. The workflow is the same at every company, so the average-built tool is the right-built tool. Buying is correct—building your own email server would be a waste.
But every org also runs a long tail of workflows that are specific to how that company operates: its onboarding sequence, its approval chains, its inventory quirks, the report its CFO actually reads. No vendor will ever serve those, because there’s no market of a thousand identical buyers for your exact process. Historically you bought the closest generic tool anyway and paid the fit gap, because the alternative—commissioning custom software—meant a six-month engineering project with a price tag that only penciled out for the biggest workflows.
| Commodity work | Core, company-specific work | |
|---|---|---|
| Examples | Email, payroll, video calls | Your onboarding flow, approval chains, the report your CFO reads |
| Does generic SaaS fit? | Yes—the workflow is the same everywhere | No—it’s specific to how your company runs |
| Historical default | Buy it | Buy the closest tool, pay the fit gap |
| What changed | Still buy it | Building the exact fit is now cheap enough to do |
So the build-vs-buy decision was never really binary. It was a budget calculation. Buy the commodity; for the core, buy the closest approximation because building the real thing cost too much. The interesting question isn’t whether to build the fit—it’s what happens to that calculation when building gets cheap.
What changes when the people closest to the work can build the fit
Here’s the failed status quo most orgs are living in right now. They felt the fit gap, so they did one of two things. They bought more SaaS—another 106 tools, each closing one gap and opening two. Or they handed their teams an AI coding assistant—Claude Code, Cursor, GitHub Copilot—and hoped non-engineers would build the missing tools themselves. Those coding assistants are excellent, but they operate at the code layer and assume engineering skill. Point one at a finance analyst—someone who could otherwise build the apps their finance team needs—and you haven’t removed the barrier to building; you’ve relocated it from “wait for IT” to “learn to code.” The person who understands the workflow still can’t produce the tool.
The shift that flips build-vs-buy is a different category of AI, operating one layer up. A product agent lets someone describe the application they need in plain language and get back a real, deployed full-stack app—backend, database, authentication, frontend, and deployment—not a prototype or a screenshot. Today the most advanced one is Remy. The ops lead describes the vendor-onboarding tool they’ve been faking in a spreadsheet for years—the four steps, the conditional security review, who approves what. Remy drafts that description into a plain-language spec, the spec compiles into a working app with real server-side auth and roles, and it ships to a live URL. The spec is the source of truth, so changing the tool means editing the description and recompiling—not maintaining code.
The reason this changes the build-vs-buy math is cost. A typical full-stack build runs roughly $30–40 in inference—not a six-month project. At that price, the long tail of company-specific workflows that no vendor would ever serve, and that never justified a custom-software budget, suddenly becomes worth building exactly to fit. The org stops bending its work to match the average tool and starts producing tools that match the work. Buy the commodity; build the fit. This is still early—product agents are in open alpha, and enterprise needs like SSO are on the way—but the economics have already moved, and the orgs that notice first stop paying the fit gap.
FAQ
Why doesn’t SaaS software fit my company’s exact workflow? Because it was built for the statistical average of its market, not for you. To sell one product to thousands of customers, vendors engineer around the median workflow and add configuration for everyone else—which makes the tool broadly acceptable but precisely right for no single company.
What is the real cost of generic SaaS that doesn’t fit? The subscription fee is the visible cost; the larger one is the human layer of workarounds—side spreadsheets, copy-paste between tools, manual approval chains—that teams build to bridge the gap between what the tool does and what the work actually requires.
Should my company build software or buy it? Buy commodities where the workflow is identical at every company—email, payroll, video calls. Build for the core workflows specific to how your company operates, where no vendor’s average-built tool can fit. The line is commodity versus core.
Why did low-code platforms fail to close the fit gap? They let non-engineers customize faster, but the work still ran inside another vendor’s platform, with its data model, limits, and lock-in. You got a better approximation of the fit, not the fit itself, and the customization became one more thing to maintain.
Why can’t I just give my team an AI coding assistant to build internal tools? Coding assistants like Cursor or GitHub Copilot operate at the code layer and assume engineering skill. Handing one to a non-engineer relocates the barrier from “wait for IT” to “learn to code” rather than removing it. A product agent works one layer up, from a plain-language description.
What is a product agent? A product agent is a category of AI tool that compiles a plain-language description of an application into a real, deployed full-stack app—backend, database, auth, frontend, and deployment—so the person who understands a workflow can build the tool for it without writing code.
How much does it cost to build a custom internal tool now? With a product agent, a typical full-stack build runs roughly $30–40 in inference—orders of magnitude below the six-month engineering project that custom software used to require, which is what flips the build-vs-buy math for the long tail of company-specific work.
The bottom line
Generic SaaS isn’t broken—it’s built for the average company, which is no company. For commodity work, the average tool is the right tool, and you should buy it. For the workflows that are specific to how your company actually runs, the average tool never fit, and for decades you paid the gap because building the real thing cost too much. That’s the part that changed. When the people closest to a workflow can describe the tool they need and get a real full-stack app for the price of a lunch, the org stops contorting its work to fit the software and starts shaping software to fit its work.
If you want to see what describing a tool and getting a real one looks like, explore Remy →. For the bigger picture, read what the winning org looks like and why your best engineers don’t work in engineering.
