An argued position · product economics
Utility, not SaaS.
Software should complete a useful job at a fair price, remain inexpensive to run and be easy to leave. The subscription is not the problem. Building the customer around the vendor’s revenue model is.
What we reject
Start with the job. Not the pricing ladder.
SaaS began as a sensible way to deliver and maintain software. Too often, its commercial machinery now dictates the product: split the work into tiers, charge for every collaborator, hold necessary capability for an upgrade and call the missing pieces a roadmap.
Anti-SaaS reverses that logic. We define the recognisable job first, build enough product to complete it and set a price proportionate to the value delivered. Recurring payment is reasonable where the product keeps operating, improving and carrying cost. Recurring rent for deliberate incompleteness is not.
Two product logics
The difference appears in the decisions.
- Product boundary
- Launch the easiest slice and sell the omissions later.
- Complete the bounded job, including its awkward middle.
- Price
- Optimise tiers, seats and limits for expansion revenue.
- Charge a fair, legible amount for the value delivered.
- Retention
- Make cancellation, export or replacement painful.
- Make leaving possible and staying worthwhile.
- Operations
- Add people and process as the customer count grows.
- Remove support toil and standing cost by design.
A clear product boundary
Finish the job you sell.
A demonstration can prove that one path works. A product has to survive the exceptions, hand-offs, permissions, records, recovery and reporting that make the real job difficult.
That does not mean an infinite feature list. It means a firm boundary and no knowingly missing middle inside it. The product either completes the agreed job or it is not ready to ship.
Cheap, not free.
We cannot out-price £0, and do not try. A paid utility earns its small price by handling the complicated, regulated and cross-role cases that simple free tools avoid. Cheap means the cost is an easy decision beside the work it removes.
Easy to leave. Not worth leaving.
A Zero Drift utility should make exit legible: export the data, end the contract and take the operating knowledge. Retention should come from configured workflows, accumulated evidence, saved effort and trust earned in use—not from a hostage situation.
Why the cost floor is different
Low prices require low operating cost.
- 01
Agents multiply implementation.
Experienced technical judgement directs more building work without recreating a conventional delivery team around every product.
- 02
Shared foundations remove repetition.
Products reuse a secure, observable operating substrate instead of paying to reinvent hosting, identity, deployment and evidence each time.
- 03
Self-service removes human toil.
Onboarding, recovery and ordinary operation must work without a growing support organisation standing behind the screen.
- 04
Architecture keeps winners viable.
A low initial price is only honest if the system can carry increased use without a cost explosion or a rescue rewrite.
The honest pressure test
The thesis still has to survive contact with customers.
Activation
If a buyer cannot reach first value without help, the low-touch cost model is fiction.
Completion
If the difficult cases remain outside the product, cheap merely means incomplete.
Renewal
Every renewal is a new decision. Accrued value must remain greater than the price and effort of staying.
Support
Minutes of recurring human help are a cost signal. The product must absorb what repeats.
These are measurements, not articles of faith. Time to first value, support effort, renewal and the reasons customers leave decide whether Anti-SaaS works.
The product designs make the distinction concrete. ClarityCrowd starts with a complete Resource HR job, then adds development and alignment as different jobs. TenantTidy includes its features across property-count tiers. Those choices illustrate the discipline; demonstration deployments do not yet establish renewal, support costs or profitable adoption.
The practical test
Does the software serve the customer before it serves the revenue model?
- Can a buyer understand the whole job it completes?
- Is the price clear before a sales conversation?
- Can the product be adopted without an implementation project?
- Does it remain inexpensive to operate as use grows?
- Can the customer leave without losing control of their work?
If those answers are not clear, the product is still hiding part of its contract.