When “Build It With an LLM” No Longer Beats Buying It
After leaving Stainless to focus on turning his side project, River, into a sustainable business, Brandur was met with a familiar refrain: “Anything you ship can be instantly displaced by an internal package built by an LLM.” It’s a fair challenge. LLMs have undeniably collapsed the cost of producing software, potentially shifting the classic buy-versus-build calculus. An anecdote from LinkedIn—where a company replaced a $400/mo Jira subscription with a bespoke task tracker built via Claude—illustrates the temptation. Yet, a closer look at the economics suggests that “cheap” and “free” are very different things, and that there remains a profitable middle ground for commercial software.
The Real Cost of the Build
LLM-assisted development is not zero-cost. Producing a good system still requires an operator to run many iterative loops, refine output, and verify results. Maintenance remains a persistent, ongoing expense, especially as bugs surface and features are requested. The most expensive element in this equation isn’t the model—it’s the human time spent supervising the output.
Using the LinkedIn example: an engineer earning $200k/year costs roughly $96/hour. To beat Atlassian’s $400/mo, that engineer can spend no more than 4 hours per month on the project just to break even. That time has to cover not just prompting features, but also database upkeep and other operational overhead. Even being wildly optimistic and assuming a 2-hour monthly maintenance load, the initial development time—a charitable estimate of two weeks—would take 37 months to recoup. The math simply doesn’t pencil out for replacing a tool with a custom build, no matter how much you dislike Jira.
The calculus shifts, however, as the price of the commercial product climbs. At roughly $500/mo per seat for a fully loaded Salesforce license, a 50-seat deployment costs $25k/mo. For that sum, you could fund 1.5 full-time engineering equivalents to build and maintain a clone. While a CRM is a complex system, this price point is close enough to a “build” decision that even smaller companies might reasonably consider it.
The Zone of Viability
The key insight is that there is a zone of viability for commercial software. A product sits in this zone when it meets two criteria:
- Sufficient novelty: Rebuilding it with an LLM is non-trivial and carries a significant ongoing maintenance burden.
- Reasonable pricing: The licensing cost is low enough that it doesn’t strongly encourage a rebuild attempt.
Within this zone, the total licensing fees paid are less than the cumulative cost of prompting the initial build and sustaining the software over time. The lower boundary of this zone defines the minimum viable unit of saleable software: a price point below which the effort of building and maintaining an in-house version is less than the cost and friction of purchasing a third-party product.
River’s Position
Brandur’s bet is that River, an open-source job queue for Go and Postgres, sits firmly in this viable zone. The project offers most job-related features for free but reserves advanced functionality—like workflows, sequential jobs, and concurrency limits—for a paid Pro version. The argument is that an LLM could technically reproduce these features, but the thoughtful API design and performance characteristics would take significant work to replicate with any fidelity. This provides the necessary novelty.
On price, River uses a sublinear, team-based model rather than per-seat billing. It starts at $125/mo for up to 20 developers, which is the all-in cost for a small or medium team. For a product of this complexity, that price point is designed to sit comfortably below the total cost of an LLM-driven internal build, giving customers a clear economic reason to buy rather than build.
Whether this strategy succeeds is an open question. But for now, the economics of the modern software landscape suggest that even with powerful LLMs, a well-priced, genuinely novel product still has a clear path to viability.
