You walked into the restaurant and were served an incredible meal.
The room was full. Orders flowed smoothly from kitchen to table. The waiter explained how everything scaled effortlessly, how every dish came from the same well-designed system, how this was what running a modern business looked like when everything finally lived in one place.
That was the demo.
After you signed the contract, you came back.
The space was real, but it was empty. No staff. No food. No menus. Just a pristine kitchen and rows of unused tables. If you wanted a meal, you needed to hire cooks, source ingredients, design recipes, and figure out how everything moved through the space.
What you bought wasn’t dinner — it was a lease.
That gap between what was shown and what was delivered defined the SaaS era.
For a long time, companies accepted it because they had to. Building the restaurant yourself was too expensive, too complicated, and too risky. Buying the whole kitchen — even an empty one — was often the only way to get started at all.
What’s changing now isn’t taste or preference. It’s feasibility.
The cost of building and deploying software has collapsed. Infrastructure fades into the background. AI reduces the effort required to turn intent into working systems. And once those constraints fall away, paying rent for a kitchen you barely use starts to feel less like leverage and more like inertia.
This isn’t a story about one platform or one vendor.
It’s about why the tradeoffs that made SaaS inevitable are quietly breaking — and why the restaurant model that once unlocked progress is starting to hold it back.
How We Got Here: Why This Made Sense
It’s easy to look at an empty restaurant and wonder why anyone agreed to this arrangement in the first place.
But for a long time, buying the whole building wasn’t indulgent — it was the only viable option.
Early on, building software wasn’t just about writing code. You had to manage servers, deployments, databases, scaling, backups, security, and uptime. Even small applications required specialized expertise and constant operational attention. For most teams, the alternative to buying a platform wasn’t a better solution — it was not building anything at all.
That’s the context SaaS emerged in.
Platforms weren’t selling great meals. They were selling the ability to cook. You didn’t have to install anything, provision hardware, or assemble an operations team just to get started. The kitchen existed, the power was on, and you could begin shaping your workflow instead of spending months making the space usable.
That mattered more than elegance.
The same pattern played out across the industry. Publishing platforms made it possible to have a website without understanding hosting. CRMs made it possible to track customers without building a system from scratch. Support tools made it possible to manage tickets without inventing a workflow engine. These platforms didn’t eliminate work — they made work possible.
Because the kitchen itself was the hard part, everything else became secondary.
It was acceptable that onboarding took months, because the alternative was never going live. It was acceptable that systems required heavy customization, because customization was the price of having a system at all. It was acceptable that consultants were needed, because the platform was still cheaper than building and operating the infrastructure it replaced.
The decision wasn’t driven by preference. It was driven by constraint.
As long as standing up a reliable kitchen required deep expertise and sustained effort, renting one — even an oversized, empty one — was a rational tradeoff.
That logic held for a long time.
The problem isn’t that SaaS failed.
It’s that the constraint it solved quietly moved.
The Industrial Kitchen Problem
Once the restaurant was open, a different problem became impossible to ignore.
The kitchen was enormous.
It was designed for banquets — hundreds of guests, complex menus, multiple courses running in parallel. There were stations you’d never use, appliances you didn’t need, and controls so flexible that changing one thing often required adjusting several others. On paper, this was power. In practice, it was friction.
Most teams weren’t trying to run a catering business.
They were trying to serve a small, focused menu. A handful of workflows. A narrow set of outcomes. But the kitchen they bought assumed scale first and specificity later. Everything was possible, but nothing was simple.
Doing basic things took ceremony. Adding a field meant updating workflows. Changing a process meant retraining staff. Small adjustments rippled outward because the system was built to support edge cases most teams would never hit.
You bought an industrial kitchen, but you only use the fridge.
Teams didn’t underuse these platforms because they lacked ambition. They underused them because the cost of using more of the kitchen outweighed the benefit. When every change carries risk and overhead, the safest move is to keep usage minimal.
Once workflows were configured, reports wired, and permissions locked down, the system resisted change. It was flexible in theory, but brittle in practice. Every modification felt like a renovation instead of a tweak. The platform became something teams worked around rather than worked with.
This is why onboarding never really ends.
Not because teams are slow, but because the kitchen was built for a future version of the restaurant — one with more guests, more staff, and more complexity than most businesses actually needed.
The problem isn’t that these platforms were overbuilt.
It’s that they were built for a moment when building anything smaller wasn’t feasible. Once that stops being true, the industrial setup stops looking like leverage and starts looking like overhead.
The Escape: Tool Sprawl, Fragmentation, and Folding Tables
When the main kitchen became too heavy to work in, teams did what they always do: they found another place to cook.
Instead of forcing every meal through an industrial setup, they opened smaller, purpose-built kitchens. One for support. One for marketing. One for analytics. Each was designed around a specific dish, not a hypothetical banquet. You didn’t have to design the workflow — you used it. The appliances were already in the right place.
This was a rational move.
It was faster to rent a kitchen that already knew how to make the meal than to reconfigure the main one. Training was simpler. Outcomes arrived sooner. For teams under pressure to deliver, specialization beat flexibility.
But the moment you open more than one kitchen, a new problem appears.
Ingredients stop living in one place.
Customer data sits in support. Engagement data lives in marketing tools. Revenue data lives somewhere else. Each kitchen has its own pantry, labels, and definitions. If you want to understand what’s really happening end to end, you’re no longer cooking — you’re walking between buildings with a clipboard, trying to reconcile inventories by hand.
Integration quietly becomes the real system.
Every connection has to be built, monitored, and maintained. When one kitchen changes how it labels an ingredient, another breaks. Definitions drift. Sync jobs fail silently. Over time, the effort required to keep everything aligned grows faster than the value it produces.
Costs rise, and control gets harder.
Each kitchen charges rent. Each prices by seats, storage, or volume. Individually, the contracts look reasonable. Together, they form a fixed-cost structure that expands without a clear link to outcomes. At the same time, security and compliance turn brittle. Deleting customer data becomes a scavenger hunt. Access rules diverge. Audits drag on.
Eventually, teams stop trying to “fix” the restaurant.
They pull out folding tables.
Spreadsheets become the prep surface of last resort — not because they scale, but because they’re immediate. You can lay everything out, change your mind, and see the mess all at once. When systems are fragmented and rigid, a flat surface restores visibility.
This is the loop teams fall into:
platforms → specialty tools → fragmentation → spreadsheets.
It isn’t a failure of discipline.
It’s a predictable response to systems that are either too heavy to adapt or too scattered to trust.
Why the SaaS Cost Model Breaks After the Shift
For years, SaaS pricing felt like the cost of doing business.
You paid rent because owning the building was the hard part. Access was scarce. Reliability was expensive. If the kitchen already existed and worked, a recurring fee was easier to justify than trying to build one yourself.
That logic only holds as long as the building is the bottleneck.
Once deployment becomes routine and infrastructure fades into the background, the pricing model starts to look misaligned. The cost didn’t change — the justification did.
Most SaaS platforms don’t charge for how much cooking actually happens. They charge for the right to be in the building. Whether the stove is on or off, whether you use one appliance or fifty, the rent is the same.
Large platforms accumulate features over time, but most teams touch only a small fraction of them. Capabilities are added to satisfy edge cases or large customers, and everyone else inherits the complexity. You end up paying to maintain appliances you never turn on.
Overpayment becomes structural.
You don’t pay less because you need less. You don’t pay more because you grow carefully. You just pay. And when tool sprawl enters the picture, that fixed cost multiplies across systems without any clear link to outcomes.
Then there’s the cost no one budgets for.
Most platforms rely on humans to manufacture data.
Deals don’t progress unless someone updates a field. Tickets don’t exist unless someone opens them. Status only changes when someone remembers to narrate reality after it already happened. The platform isn’t integrated with how work actually runs — it depends on people to keep it believable.
That turns labor into infrastructure.
Sales reps become ingestion pipelines. Support agents become event streams. Managers become reconciliation jobs. Analytics look precise, but they’re built on data that was manually reconstructed under pressure.
You pay twice.
You pay the subscription to access the kitchen. Then you pay in labor to keep pretending it’s integrated.
Customization makes this worse.
To make these platforms usable, teams invest heavily in tailoring workflows, fields, automations, and permissions. Over time, the platform stops being software and starts being your software — except you don’t own it. Any new tool or process now has to bend around existing configuration.
The more you customize, the harder it is to leave.
What began as flexibility turns into lock-in. Processes calcify. Experimentation slows. Adopting something new becomes a migration project instead of a decision.
This is why SaaS costs rarely go down.
The rent doesn’t adjust when the work becomes easier. The longer you stay, the more expensive it becomes to imagine anything else.
You’re no longer paying for leverage.
You’re paying for inertia.
Where This Is Headed: From Platforms to Flexible Systems
The shift underway isn’t away from software.
It’s away from rented workflows.
In the age of AI, the most valuable asset isn’t the application — it’s the data. Where it lives, how it’s structured, and how easily it can move matter more than the interface wrapped around it.
For a long time, logic was the expensive part. Encoding business rules, maintaining workflows, and translating intent into exact system behavior required sustained engineering effort. That’s why platforms bundled logic and charged rent for access to it.
AI changes that equation.
The cost of logic drops dramatically when systems can translate intent into implementation with far less human effort. Writing, modifying, and extending behavior is no longer the bottleneck it once was.
What doesn’t get cheaper is ownership.
Data still needs a home. Interfaces still need to be defined. Systems still need to be understandable and auditable. But once logic becomes fluid, the value shifts toward flexible storage and clean boundaries rather than rigid workflows.
This is where data engineers are uniquely positioned.
Homegrown solutions used to be hard because teams had to own everything — infrastructure, logic, and data. Now, much of the logic can be offloaded. The work becomes about designing systems that can evolve without being rebuilt every time requirements change.
The future looks less like a single restaurant you rent forever and more like a set of kitchens you can rearrange as the menu changes.
You don’t need fewer tools.
You need systems that don’t fight you when you change your mind.
A Small, Concrete Example
For years, my personal site lived on WordPress.
I was paying around twenty dollars a month for something that looked nothing like the templates that sold me on it. Every attempt to customize it led to the same place: pay for another plugin, discover it doesn’t quite work, then realize it conflicts with something else. Even simple things — subtle animations, layout changes, small interactive touches — were either brittle or out of reach.
The site wasn’t broken. It was just flat.
The problem wasn’t effort. It was constraint. WordPress optimized for serving everyone, which meant meaningful customization always lived just past another paywall.
Recently, I rebuilt the site as a small Next.js app. With agent-assisted workflows and a modern frontend stack, things that felt “advanced” in WordPress — animations, layout control, interaction — became straightforward. Not because I suddenly became a better developer, but because the platform stopped getting in the way.
I now pay roughly a dollar a month to host it.
More importantly, I own the structure. I’m no longer negotiating with templates or plugins to express something simple. The logic was never the hard part. The friction was.
That’s the shift in miniature. When capability becomes cheaper than constraint, renting the restaurant stops making sense — even for things that used to live comfortably inside SaaS.
Devil’s Advocate: Haven’t We Tried Homegrown Before?
Yes. Almost every company has.
At some point, someone built a rough internal tool. A basic customer tracker. A lightweight ticketing system. It worked when the company was small.
Then the business grew.
Those systems didn’t fail because they were naïve. They failed because they demanded the same level of care as production software. Every change required engineering time. Every edge case competed with the core product for attention. Eventually, the internal tool became technical debt the team couldn’t justify maintaining.
So companies outsourced the problem.
That decision made sense when internal systems required constant hands-on effort. Non-core software still needed full-time care, and that care pulled resources away from what actually differentiated the business.
That logic used to be correct.
What’s changed isn’t ambition or discipline. It’s leverage.
Non-core systems no longer need the same level of attention as core applications. Much of the mechanical work — implementing rules, wiring logic, adapting workflows — can now be handled with far less direct engineering effort.
Instead of hiring teams to build and maintain internal software, small groups can supervise systems that handle most of the repetitive work themselves.
For the first time, building exactly what you need doesn’t mean starving the core product to do it.
Conclusion: Stop Renting the Restaurant
SaaS didn’t fail.
It solved the hardest problems of its era, when infrastructure was scarce, deployment was slow, and building anything from scratch required specialized teams and long timelines.
But the conditions that made those tradeoffs rational are gone.
Infrastructure is no longer the constraint. Logic is no longer the bottleneck. Data is the asset.
What teams are reacting against isn’t software — it’s renting workflows they don’t control, paying fixed costs for unused capacity, and relying on people to glue systems together after the fact.
The restaurant model unlocked progress when owning a kitchen was unrealistic.
Now it just keeps you paying rent.
The next generation of systems won’t be bought as platforms and customized into submission. They’ll be assembled around owned data, flexible logic, and interfaces that can change without permission.
The future isn’t about finding a better kitchen to rent.
It’s about realizing you don’t need to rent the restaurant at all.