← Back to news

The Minimum Viable Unit of Saleable Software

brandur.org|21 points|3 comments|by brandur|Jun 21, 2026

The Minimum Viable Unit of Saleable Software

Originally published May 31, 2026, in Berlin by @brandur.

Recently, I shared my decision to depart from Stainless to focus on transforming my side project, River, into a lean, sustainable enterprise. This announcement prompted several skeptics to question my sanity given the current AI climate.

"Are you out of your mind? In the age of LLMs, anything you release can be instantly cloned by a company using an internal AI-generated package!"

As someone who has fully embraced the power of Large Language Models, I find this critique entirely valid. I may indeed be delusional, but let me walk you through the logic of my position.

The "Build" Delusion on LinkedIn

While scrolling through LinkedIn—that infamous hub of engagement farming and fabricated anecdotes—I encountered a post from a user claiming victory over Atlassian. His company was paying $400/month for Jira, a cost he found offensive. To solve this, he tasked his team with using Claude to build a bespoke internal task tracker.

The result? Jira was scrapped, the $400 monthly expense vanished, and they now possess a custom tool that can be iteratively refined by an LLM to meet their exact needs.

Historically, the "build vs. buy" debate in software had a clear answer. Building was prohibitively expensive due to high engineering salaries and the rarity of top-tier talent. The risks were well-known:

  • Massive upfront capital requirements.
  • Chronic schedule slippage.
  • The "rabbit hole" effect of scope creep.

The standard advice was to focus engineering resources strictly on your core domain and ignore peripheral tools until the company was large enough that these distractions were absorbed by massive margins.

Why Cheap \neq Zero

LLMs have drastically lowered the barrier to entry, but they haven't made software production free. A high-quality, AI-generated system still requires a human-in-the-loop feedback cycle:

  1. Operator prompts the model.
  2. Results are analyzed and tested.
  3. Adjustments are requested.
  4. The process repeats dozens of times to reach an acceptable compromise between speed and quality.

Even for simple tools, there is a perpetual stream of bugs to squash and features to add. The most expensive component isn't the tokens; it's the human labor required to oversee and verify the output.

The Math of the "Free" Jira Clone

Let's analyze the $400/month Jira replacement. Even with AI, building a functional task tracker takes a few weeks of focused effort. Let's quantify the cost using a standard engineer's salary.

TimeframeCost
Annual Salary$200,000.00
Monthly$16,666.67
Weekly$3,846.15
Hourly$96.15

To see the logic in code:

salary = 200_000.0
costs = {
  month: salary / 12,
  week: salary / 52,
  hour: salary / 52 / 40,
}
costs.each { |k, v| puts "#{k}: $#{'%.2f' % v}" }
# Output:
# month: $16666.67
# week: $3846.15
# hour: $96.15

To offset a 400/monthsubscription,theengineercanspendnomorethan400/month subscription, the engineer can spend no more than \frac{400}{96} \approx 4.16$ hours per month on maintenance, updates, and database management—excluding the mental cost of context switching.

If we are generous and assume maintenance only takes 2 hours a month, the break-even point after an initial two-week build is:

Months to Break Even=2×3846.15400(2×96.15)37 months\text{Months to Break Even} = \frac{2 \times 3846.15}{400 - (2 \times 96.15)} \approx 37 \text{ months}

While I personally despise Jira, the economics of building a replacement simply do not add up.

The High-End Exception

Conversely, consider a high-ticket SaaS product. Gemini suggests a fully loaded Salesforce seat costs roughly 500/month.Atthatpricepoint,themathshifts.Youcouldessentiallyfund1.5fulltimeengineers(500/month. At that price point, the math shifts. You could essentially fund 1.5 full-time engineers (\frac{25}{16.7}$ relative to the previous example) just to build a clone. For a larger firm, building a CRM becomes a viable strategic decision. (Interestingly, Salesforce's 30% YTD drop suggests the market is starting to realize this).

Software Economics Concept

The Zone of Viability

I believe there exists a "Zone of Viability" for software. If a product is priced reasonably, it remains more logical to buy it than to build it, even with LLMs.

To stay in this zone, a product must meet these criteria:

  • Sufficient Novelty: The software must be complex enough that an LLM cannot rebuild it trivially, and it must require ongoing expert maintenance.
  • Reasonable Pricing: The cost must not be so high that it incentivizes the customer to build their own version.

As long as the licensing fee is lower than the cumulative cost of the initial AI-prompting push and the long-term human oversight, the software remains saleable.

The "Minimum Viable Unit of Saleable Software" is the floor of this zone; below this threshold, the product is too simple to be sold because the cost of building it with AI is lower than the cost of buying it.