Per-user and per-unit pricing models have become so standard in enterprise software that their fundamental design flaw often goes unexamined. That flaw is straightforward: the pricing model charges customers more money at precisely the moment they are doing best.
The math
Consider a pool service operator using software priced at $2 per pool per month. At 100 pools, they pay $200 per month. The software covers route management, chemistry logging, customer communication, and compliance records. At 200 pools, they pay $400. At 500 pools, they pay $1,000. At 1,000 pools — a successful regional operation — they pay $2,000 per month, or $24,000 per year.
What changed between 100 pools and 1,000 pools in terms of what the software provides? The route optimization algorithm runs on the same infrastructure. The chemistry logging form is identical. The compliance report template did not get better. The customer communication system sent more emails, but email costs fractions of a cent per message at any scale. The software company's cost to serve this operator increased modestly — perhaps twenty percent more compute and storage. Their revenue from this operator increased one thousand percent.
That gap between cost increase and revenue increase is not a margin improvement. It is value extraction. The software company is charging for the operator's growth, not for anything the software company built or improved. The operator's success became the software company's revenue model.
Now run the same math for a lawn care operator on per-technician pricing at $50 per month per technician. At 5 technicians, they pay $250 per month. At 10 technicians, they pay $500. At 20 technicians, they pay $1,000. At 50 technicians — a substantial regional operation — they pay $2,500 per month, or $30,000 per year. Every time they hire someone, their software cost increases. Every time they expand into a new service area, their software cost increases. The per-unit model has made their software a variable cost that scales with every growth decision they make.
The behavior it creates
The per-unit growth tax does not just extract revenue — it changes operator behavior in ways that harm the operator's business. Operators who understand their pricing model — and most eventually do — begin optimizing for software cost rather than business efficiency. They delay hiring because each new hire triggers a price increase. They cap the number of customers they service on a given platform tier because the next tier is not worth the jump. They run manual workarounds for workflows that their software supports because the features they need are locked behind a more expensive plan.
This is not hypothetical. Every operator who has grown past their software's base tier has done the calculation. Some of them made the right decision and paid for the upgrade because the software was genuinely valuable enough to justify it. Many of them made the decision to cap their growth at a number that kept their software costs manageable. Some of them decided that the software was no longer worth the price at scale and started shopping for alternatives.
The irony is that per-unit pricing creates maximum pain at exactly the moment when operators are doing best. An operator at five technicians who grows to twenty technicians is a successful operator. They should be celebrating their growth. Instead, they are negotiating with their software vendor about pricing tiers and calculating whether the cost of migrating to a cheaper alternative is less than the cost of staying. The software company has created a moment of maximum friction at the moment of maximum customer success. That is structurally backwards.
Why per-unit churn is structural, not operational
When operators churn from per-unit software at growth stages, the software company often attributes it to product failures. The product was not good enough. The onboarding was insufficient. The support let them down. Sometimes this is true. But in fragmented markets, a significant portion of growth-stage churn is structural — the product worked fine, and the operator left because the pricing model became untenable at their scale.
This creates a specific and damaging pattern: the software company's most successful customers become their most likely churners. The operator who started small, used the software effectively, grew their business, and then hit a pricing inflection point did not have a product failure. They had a pricing failure. The software company served them well until the pricing model made serving them expensive. And then those customers — the ones who proved the product worked by growing their business while using it — became the ones most likely to leave.
This is not a retention problem that better customer success can fix. It is a pricing architecture problem. The model selects against retention of growing customers. No amount of onboarding investment or customer success outreach changes the fundamental math for an operator who is paying $2,500 per month for software that they could replace with a flat-rate alternative at $299 per month.
How flat rate aligns incentives
Flat rate pricing does something that per-unit pricing cannot: it aligns the software company's incentives with the operator's success rather than against it. When a flat rate software company's revenue does not grow with the operator's headcount or customer count, the only way the software company grows is by retaining customers and acquiring new ones. The only way to retain customers is to build software that genuinely improves their operations. The only way to acquire new ones is to have a product so good that existing customers recommend it.
This creates a different kind of software company — one that has to earn its retention every month by being genuinely valuable, rather than one that retains customers through pricing lock-in and switching cost. Flat rate software companies cannot coast. They have to keep building. They have to keep improving the product because if the product stops improving, customers will leave. There is no pricing mechanism that makes it too expensive to leave.
This is not charity. It is a business model that produces better software because it has to.
The counterargument
The standard objection to flat rate pricing is that it leaves money on the table. The largest customers — the ones using the software most intensively — should pay more because they are getting more value. This argument is intuitive and wrong.
The LTV of a flat rate customer who stays for three years is almost always greater than the LTV of a per-unit customer who churns at their growth stage. A pool service operator paying $299 per month for three years generates $10,764 in lifetime value. A pool service operator paying $200 per month for the first year, $400 per month for the second year as they grow, and then churning in year three because the price doubled again generates about $7,200 — less than the flat rate customer who never had a reason to leave.
The math shifts more dramatically when you account for acquisition cost. Acquiring a new customer in a fragmented vertical requires significant outreach, onboarding, and early support investment. When a customer churns at scale and gets replaced by a new customer who goes through the same acquisition cycle, the customer lifetime value calculation looks worse with every replacement cycle. Flat rate pricing retains customers through growth stages and reduces the churn-and-replace cycle that makes per-unit models look profitable on a per-customer basis but costly on a portfolio basis.
The market opportunity
Every per-unit software company in a fragmented market is actively creating a switching incentive for every customer who is growing. Every price increase that a PE-owned legacy vendor implements sends a signal to their customer base that the growth tax just got more expensive. Every operator who gets hit with a renewal quote that is forty percent higher than last year's is actively calculating whether the cost of switching is lower than the cost of staying.
For a flat rate product with a demonstrably better mobile experience and purpose-built industry workflows, the calculation is not close. The question is not whether the operator wants to switch. The question is whether the switching friction is low enough that they will. The job of a vertical SaaS company with flat rate pricing is to make that friction as low as possible. Reduce the migration burden. Offer data imports. Make onboarding fast. Make the first week of use clearly better than the last week with the incumbent. Do that, and the per-unit incumbent's growth tax becomes your most effective sales tool.