The Minimum Viable Unit of Saleable Software in the Age of AI

The Impact of LLMs on the "Buy vs. Build" Calculus

Large Language Models (LLMs) have fundamentally shifted the cost of producing software, making it possible to generate substantial pieces of code quickly. This has led to a renewed debate over whether companies should continue to pay for SaaS products or simply use AI to build internal clones. However, while the cost to build has decreased, it has not dropped to zero.

Building a functional system with an LLM still requires a human-in-the-loop feedback cycle—prompting, adjusting, and refining—often taking dozens of iterations to reach a satisfactory quality. Furthermore, maintenance remains a constant cost. Every bug fix or feature request requires human oversight and verification, meaning the long-term expense of a homegrown tool is often underestimated.

Quantifying the Cost of Homegrown Software

To determine if building an internal tool is financially sound, one must compare the monthly SaaS fee against the cost of engineering time required for initial development and ongoing maintenance.

For example, consider a company spending $400/month on Jira. If an engineer earns $200,000/year (approximately $96/hour), the company can afford no more than 4.2 hours of that engineer's time per month to break even on the subscription cost. When accounting for the initial build effort—estimated at a few weeks—and the inevitable maintenance, the "break-even" point for a homegrown task tracker can take years to achieve, making the purchase the more rational financial choice.

Conversely, for high-priced enterprise software like Salesforce, where costs can reach $25,000/month for 50 seats, the math shifts. At this price point, the cost of the software exceeds the cost of several full-time engineers, making a "build" decision more plausible even for smaller organizations.

The Zone of Viability

There exists a zone of viability for software products—a sweet spot where it makes more sense to buy a product than to build it, even with AI assistance. Software falls into this zone when it meets two conditions:

1. Sufficient Novelty: The product is complex enough that an LLM-driven rebuild is non-trivial and carries a meaningful maintenance burden.
2. Reasonable Pricing: The cost is not so exorbitant that it incentivizes a company to invest in a custom build.

Below this zone lies the minimum viable unit of saleable software. If a product's complexity is too low or its price too high, it falls outside this zone, and a rebuild becomes the more cost-effective or attractive option.

Application to River: A Case Study

River, a job queue for Go and Postgres, attempts to position itself within this zone of viability. By offering core features for free via open source and charging for advanced features (such as workflows and sequential jobs) in a Pro version starting at $125/month for up to 20 developers, River aims to remain below the threshold that would trigger a "build" response while providing enough architectural fidelity and API design that a quick AI clone would be inferior.

Community Perspectives and Counterpoints

Industry practitioners provide several critical nuances to the "buy vs. build" framework:

The "Enterprise Layer" and Hidden Costs

Many argue that the core functionality of SaaS is often simple, but the value lies in the "enterprise layer"—features like SSO, multi-tenancy, audit logs, and compliance (GDPR/CCPA).

"Most enterprise software could be replaced with simple scripts and command line tools if they had this enterprise layer. I'd wager tons of SaaS is just simple open-source software and libraries behind a management layer."

The Risk of "Brain Space" and Maintenance

Building internal tools consumes precious engineering focus. Maintaining a custom CRM or task tracker creates a long-term dependency that requires a minimum number of people to understand the system to ensure sustainability. Using a commodity product, even an expensive one, reduces the risk of project failure and avoids the "political cost" of managing an internal roadmap.

The Community Effect

Commercial software benefits from a positive externality: features requested by a small minority of users often end up benefiting the entire user base. Internal tools lack this community-driven evolution, limiting them to the specific needs of the organization at the time of build.

The "Agentic" Shift

Some suggest that AI's real impact may not be the total replacement of SaaS, but the reduction of seat counts. If AI agents can automate data entry and recurring tasks, a company might reduce its Salesforce seat count by 50%, effectively lowering the cost of the software without needing to build a replacement.