The SaaS Squeeze: Build the Simple Software You Used to Rent

The subscription model for simple software rested on a single assumption

I am Madhuranjan Kumar, and that assumption was that building software was hard enough that it made sense to rent it. The premise was reasonable for most of the past two decades. If a gym needed software to handle class sign-ups, waivers, and member check-ins, building that software required hiring a developer, specifying the requirements, waiting months for delivery, and then maintaining the codebase over time. The total cost of building, even for something modest, was reliably in the range of tens of thousands of dollars. Renting at $150 per month was obviously the right call.

The SaaS pricing model for simple software was built on this asymmetry. Software companies knew that a gym, a yoga studio, a barber shop, or a pet grooming service could never practically build the tool they were selling, so the pricing reflected the monopoly position that creation complexity granted. The gym owner could either pay the subscription or go without, and going without a class sign-up system was not actually an option for a modern fitness business. The SaaS company captured the full surplus because the alternative was not a cheaper product. It was no product at all.

What changed about the creation equation

What has changed is not the complexity of the software problem. A class sign-up and waiver system for a gym is not a simpler problem than it was in 2020. What has changed is the difficulty of translating a clear requirement into working code. A gym owner who can clearly describe what they need, who can walk through the user flow, identify the edge cases, and specify the exceptions, now has a realistic path to having something built rather than renting it.

The change is specifically in the interaction between an intelligent system and a person who understands their own requirements deeply. A gym owner who has been running sign-ups and waivers for eight years understands what the software needs to do better than any software company's product manager who surveyed many gyms and built something that works adequately for all of them and excellently for none of them. The domain expertise was always there. The path to translating that expertise into a working system was not.

This is the mechanism behind the SaaS squeeze. The SaaS companies that are vulnerable are not the ones solving genuinely hard engineering problems. They are the ones whose product can be precisely specified by someone who uses it every day. Software that serves a well-understood, stable, bounded domain operated by someone with deep operational knowledge is exactly the category where build-versus-rent is now a live decision rather than a settled one.

The bounded domain is the key condition

Not all software is affected equally by this shift. The SaaS squeeze applies specifically to software with bounded domains: a defined set of users, a defined set of actions those users need to take, a defined set of states the data can be in, and outputs that have clear success criteria. The class sign-up, waiver, and check-in system for a gym is bounded. The number of possible actions is limited. The edge cases are known and enumerable by someone who has operated the system for years.

Unbounded domain software is not affected in the same way. A CRM for a large enterprise sales organization is not bounded in the same sense: the variety of deal structures, the range of integrations required, the complexity of the permission model across a large organization, the depth of reporting required by finance and sales leadership, all combine into a scope that grows faster than the capability to specify and build it. The SaaS squeeze does not apply here because the requirements are genuinely difficult to specify completely.

The gym example is instructive precisely because it sits clearly in the bounded category. The gym owner knows every scenario: a new member signing up, an existing member canceling, a guest pass being used, a class at capacity with a waitlist, an injury waiver being collected for a specific class type, a membership payment failing and the member's access needing to be suspended temporarily while giving them a window to update their payment method. These are not vague requirements. They are the specific events that happen every week and that the owner knows from direct experience.

What the build process actually looks like in the bounded domain

The gym example became concrete when an owner who had been paying $195 per month for a standard fitness management platform decided to test whether building was viable. The platform had functionality the gym did not use, interfaces the staff found confusing, and a price increase that had arrived without corresponding feature improvements. The owner's dissatisfaction created the motivation, but what made the experiment practical was having a clear sense of exactly what the system needed to do.

The owner spent three sessions across a week describing the requirements. Not in technical terms: in operational terms. This is what happens when a new member joins. This is what the staff sees on their screen when they check someone in. This is what the member receives when they cancel a class reservation with less than two hours notice. This is what happens when a waiver expires and needs to be collected again before the member can attend a class type that requires it.

Each session produced working components. By the end of the week the owner had a working system that handled member registration, class scheduling with capacity limits and waitlists, digital waiver collection and storage, and check-in confirmation. The owner spent one additional session adding a payment retry reminder sequence for failed charges, because that had been a source of administrative friction in the prior system and the owner knew exactly how it should work from having dealt with it manually in the months before the previous system was installed.

The final system handled the gym's actual operational requirements more precisely than the SaaS platform had, because it was built to the gym's specific edge cases rather than to a generic structure the SaaS company had designed to satisfy most of its customers partially. The waiver collection logic, for example, was built to the gym's exact policy rather than to a generic structure the SaaS company had designed to work adequately for many gyms at once.

The categories of SaaS that are under real pressure

Understanding which SaaS categories face genuine pressure from this shift requires applying the bounded domain condition systematically. The categories most at risk are ones where the primary users are operators with deep domain knowledge, the use case is stable and well-understood, the volume of users per customer is small enough that scaling complexity is not the challenge, and the integration requirements with external systems are minimal or well-documented.

Scheduling and booking software for service businesses fits this profile precisely: appointment booking for a hair salon, class scheduling for a yoga studio, reservation management for a small restaurant. The operator knows the use case better than any product manager. The domain is stable. The users per instance are a small team. The integrations needed are typically payment processing and calendar sync, both of which have well-documented APIs.

Point-of-sale systems for simple retail operations face similar pressure. A boutique with a defined product catalog, a straightforward return policy, and a small team that handles transactions is a bounded domain. The operator's knowledge of their own inventory management rules, their discount structure, and their approach to gift cards and store credit is more precise than any SaaS vendor's generalized implementation of those features.

Inventory tracking for specialized businesses is another category. A specialty supplier with a defined set of products, defined reorder points, and a specific set of suppliers has requirements that can be precisely specified. The system they need is not complex from a software standpoint. It is specific from a domain standpoint, and specificity is now buildable.

What remains out of reach for the build path

The honest framing of the SaaS squeeze requires acknowledging what is not affected. Enterprise resource planning for organizations with complex multi-department dependencies, data pipelines at scale requiring significant infrastructure expertise, security-sensitive systems where compliance requirements demand certified implementations and ongoing audit trails, and platforms that derive their value from network effects or aggregated data rather than from core software functionality are all categories where the build path is not practical in the same way.

The SaaS squeeze is also not a permanent condition for every bounded domain. Software companies in the affected categories will adapt: they will lower prices to reflect the new alternatives, they will add depth and integration that makes the SaaS option preferable to a custom build even for sophisticated operators, and they will target the cases where ongoing maintenance, updates, and compliance burden make ownership less attractive than it appears. The businesses that have built custom solutions will face maintenance costs over time that the SaaS subscription was implicitly covering.

The shift is real and is changing the calculation for a meaningful share of the SaaS market. For simple, bounded-domain software operated by people who know their requirements precisely, the rent-versus-build question is genuinely open in a way it was not three years ago. The gym owner who built the class management system did not pay a developer, did not wait months, and now owns a system that fits the business exactly. The economics that sustained the SaaS pricing model in that category have structurally changed, and the change is not temporary.