The Minimum Viable Unit of Saleable Software
Someone on LinkedIn posted about replacing their company's Jira subscription — $400/month — with a Claude-built clone. A few days of work. The clone does what Jira did for their team. They canceled the subscription.
Brandur Leach, the engineer behind the Go job queue library River, read that post and wrote The Minimum Viable Unit of Saleable Software — a short framework about the minimum viable unit threshold where customers keep paying instead of building their own. In a world where LLMs keep cutting the cost of building software, it's the most useful mental model in indie SaaS right now.
It's worth understanding in full. Not because it's depressing — but because it tells you exactly what kind of software is worth building and how to price it to survive.
What "Minimum Viable Unit" Actually Means
The concept is simple: every piece of software has a price floor below which customers are better off building it themselves than paying you.
That floor isn't just about initial build cost. It's about the full ongoing cost of building and maintaining a custom alternative — debugging edge cases, keeping integrations alive, adapting to API changes, handling the stuff that breaks at 2am. LLMs have dramatically lowered the first part of that equation. They haven't touched the second.
Which means the floor is lower than it used to be. Not gone. Lower.
Brandur's baseline: a $200k/year software engineer costs roughly $96 per hour. That's the unit of measurement. How much engineer time does a customer have to spend — every month, indefinitely — to replicate what you're selling? That's the number that determines whether your product is below the minimum viable unit or above it.
The Math That Reframes Everything
Here's the framework with real numbers:
Jira at $400/month. A team builds a functional Jira clone with AI assistance in a few days. Generous estimate: 2 hours of ongoing maintenance per month. That's $192/month in engineer time. Below the $400 subscription. The rebuild looks like it pencils out — until you account for all the integration depth, edge case handling, and 20 years of institutional knowledge Jira carries. Even so, the economic case for canceling is closer than it's ever been. The rebuild pays back the initial time investment in 37 months.
Salesforce at $25,000/month (50 seats). At that price, you're spending $300k/year on software. A dedicated engineer costs $200k/year. Salesforce is now mathematically justifiable to rebuild with 1.5 full-time engineers. The economics are completely different.
| Product | Monthly Cost | Monthly Engineer Cost to Maintain Alternative | Rebuild Pays Back In |
|---|---|---|---|
| Jira | $400 | ~$192 (2 hrs) | 37 months |
| Mid-tier SaaS ($300–500/mo) | $400 | Depends on novelty | Increasingly risky |
| Salesforce (50 seats) | $25,000 | ~$16,000 (1.5 engineers) | Immediate |
| River Pro (20 devs) | $125 | High — API + perf complexity | Never worth it |
| Cron job monitor ($25/mo) | $25 | High — alerting infra, on-call | Never worth it |
The critical shift: LLMs have pushed the minimum viable unit upward. Software that was safely priced at $400/month in 2020 might now be uncomfortably close to the rebuild threshold. The customers who read that Jira LinkedIn post — and started doing their own math — are your customers.
The Zone of Viability
Brandur describes two conditions that keep software inside what he calls the "zone of viability" — where customers keep paying instead of building:
Condition 1: Sufficient novelty. The rebuild-by-LLM must be non-trivial, with meaningful ongoing maintenance burden. If someone can clone your product in a weekend and it mostly stays working, your moat is already gone. The novelty isn't about cleverness. It's about the kind of complexity that accumulates through running software in production at scale.
Condition 2: Pricing that keeps the math pointing toward buy. Your price needs to stay below the point where a customer's team seriously considers replacing you. Not just technically capable of replacing you — actually motivated to do the math.
River, Brandur's own product, is the worked example. A job queue for Go and Postgres sounds like something any senior engineer could replicate. But the specific API design choices, the performance characteristics, the reliability under production load — that's not a weekend rebuild. And at $125/month for up to 20 developers, no team is doing that math seriously. The maintenance burden of a production job queue alone exceeds that subscription.
That's deliberate positioning, not luck.
Where Micro SaaS Lives in This Framework
Here's the part that flips conventional wisdom: cheap software is often more defensible than expensive software under this model.
At $19/month, the rebuild calculation almost never gets made. No engineer lead authorizes spending even 3 hours per month to eliminate a $19 subscription. The product survives by being below the price where anyone runs the analysis seriously.
At $299/month, you're in a different situation. A team with Claude, Cursor, and internal engineering capacity starts running the math. If your product has low novelty — if it's a thin wrapper over data the customer already owns, or a dashboard over APIs they already pay for — you're one internal hackathon away from losing that customer.
The product categories that stay defensible:
- Deep integration complexity — tools that connect 6+ third-party services and maintain those connections through API changes. Every integration breaks. Someone has to own it. At $49/month, that's never worth doing internally.
- Operational depth — monitoring tools, queue systems, error trackers. The code is simple. The years of edge case handling under production load is not.
- Domain-specific nuance — vertical software built around one industry's specific workflows. Healthcare, construction, legal — the regulatory and workflow complexity is hard to replicate with generic AI tooling.
- Data moats — products where the value is in aggregate data (benchmarks, pricing history, anonymized trends) that only comes from running the product across many customers for years. No LLM can fake that.
The categories getting squeezed:
- Thin AI wrappers over public APIs
- Basic form builders and survey tools
- Dashboard tools where the underlying data lives in a system the customer already controls
- Single-integration tools where the "value" is one webhook call
If you're building in the UGC and creator tools space, this framework helps identify which direction to push your product. Generic video reformatting: squeezed. Vertical-specific creator tooling with accumulated performance data: defensible.
List Your Micro SaaS on SaaSCity
SaaSCity.io is the premier directory for indie software, micro SaaS, and developer tools. Every listing gets a permanent, indexed page — and your product is visualized as a building in our interactive 3D digital city.
- Free listing: No cost to submit. List your product in under 2 minutes.
- Earn dofollow backlinks: Every listing earns high-quality backlinks that compound over time. Our guide to domain rating covers why this matters for early-stage SEO.
- 3D city map presence: Your product gets a building in the SaaSCity map — visible to founders, engineers, and buyers actively looking for tools to adopt.
- High-intent discovery: Customers who find you in a directory are actively comparison-shopping. Higher purchase intent than social traffic.
Applying This When You Scope Your Product
The minimum viable unit framework is a scoping tool, not a warning label.
Before you build, run the math. Take your planned monthly price. Divide by $96. That's the number of hours per month a customer would need to maintain their own version before paying you makes financial sense. If the number is under 4 hours, your product needs either:
- More novelty (hard to replicate even with strong AI tooling), or
- Lower pricing (so the calculation never tempts anyone)
For micro SaaS ideas worth building right now, this is the lens that separates the durable from the fragile. A generic project tracker at $29/month has low novelty — building one is a weekend exercise. A project tracker purpose-built for construction teams with permit tracking, lien waiver automation, and subcontractor compliance management? High novelty. The domain complexity is real. The rebuild cost is high.
Niche isn't just a distribution tactic. It's how you create novelty in software.
The practical moves this suggests:
Go deeper on your core workflow, not broader. Every feature you add that takes you an afternoon to ship takes your customer's engineer an afternoon to copy. The durable features are the ones that require operational maturity — years of running the product, accumulated edge case handling, reliability that comes from production exposure.
Build the data moat from day one. If your product will eventually generate valuable aggregate data — usage patterns, performance benchmarks, anonymized comparisons across customers — design the data schema for that before you need it. Retrofitting a data moat is hard.
Price with the build-vs-buy math in mind. Not just "what will customers pay" but "at this price, would a smart engineer team ever seriously consider replacing us?" If the answer is yes, either the price needs to drop or the novelty needs to increase.
This is also why boring software keeps printing revenue while flashy AI wrappers die. A receipt extractor at $29/month solving a messy inbox-based workflow is annoying to rebuild and barely worth the calculation. A "ChatGPT for X" at $199/month is one well-prompted Claude conversation away from redundant.
The Part That Goes Unsaid
Brandur's framework implies something he doesn't quite say directly: the minimum viable unit isn't fixed. LLMs keep improving. The cost of building keeps falling. Things that were safely priced in 2022 will fall below the threshold in 2027.
This is the real argument for building software where the value compounds through use — not through code. Network effects, aggregate data, operational reliability at scale, accumulated institutional knowledge about a specific vertical. These things grow more valuable as the product runs longer. The code is just the entry point.
The indie founders who hit $10K MRR and stay there aren't necessarily the ones who built the most sophisticated software. They're the ones who built something useful enough that the math never pushes their customers toward rebuilding it — and defensible enough that even if someone tried, the result would be worse.
That's the minimum viable unit of saleable software. It's not a number. It's a position.
SaaSCity.io covers micro SaaS, indie products, and the tools founders ship. Explore the SaaSCity directory to discover what's shipping right now — or list your own product.
Get your SaaS in front of founders
List your product on the SaaSCity live city map — a permanent listing, real discovery, and a backlink from a high-DR directory. Free to start; upgrade for a dofollow link and a building on the map.
