Brandur argues that five parallel collapses — Stripe Atlas for incorporation, Stripe Billing for metered pricing, Cloudflare Workers for global deploy, managed Postgres at $0 baseline, and LLMs zeroing out documentation/marketing/support drafting — have pushed the minimum viable unit of saleable software down to a startup cost denominated in hundreds of dollars. His essay reframes the smallest sellable artifact not as a learning vehicle (MVP) but as a commerce vehicle that actually produces reve
The editorial draws a sharp line between Ries's MVP (smallest artifact that validates a hypothesis, can be a landing page) and Brandur's MVUSS (smallest artifact that produces non-embarrassing revenue, has to actually do the work). Treating them as the same concept conflates a learning vehicle with a commerce vehicle, and the two produce fundamentally different artifacts.
Practitioners shipping single-purpose tools at $5–$29/month said Brandur is describing what they already do. For them, unit economics aren't a constraint to escape but a live tuning signal, and the post simply names a pattern that's been running quietly for years.
The pushback from the venture-oriented side is that low-ARPU products structurally can't support payroll, can't compound into category leaders, and can't return a fund. Celebrating the lowered floor mistakes a viable lifestyle artifact for a viable company.
Brandur Leach — the Stripe-alum engineer whose long-form posts on Postgres, Go, and craft have anchored brandur.org for the better part of a decade — published *The Minimum Viable Unit of Saleable Software* and rode it to 145 points on Hacker News. The essay isn't a how-to. It's a meditation on a question most product people skip past: what is the *smallest* artifact a stranger will pay you money for, and why is that floor lower than it was five years ago?
The framing is deliberately not MVP. MVP, as Eric Ries originally defined it, was a learning vehicle — the smallest thing that lets you validate a hypothesis. Brandur's MVUSS is a commerce vehicle: the smallest thing that produces revenue without making you embarrassed. Those are very different artifacts. An MVP can be a landing page. An MVUSS has to do the work.
The HN comment thread split predictably along practitioner lines. Indie hackers nodded along — most of them are already shipping single-purpose tools at $5–$29/month and treating the unit economics as a tuning signal. The VC-adjacent contingent pushed back: a sub-$10 ARPU product can't fund a team, can't compound, can't return a fund. Both are right. They're optimizing for different functions.
The interesting part of Brandur's argument isn't that small software exists — Pieter Levels has been screaming this into the void since 2016. It's that the floor has moved. Five things collapsed in parallel: Stripe Atlas made incorporation a checkout flow, Stripe Billing made metered pricing a JSON object, Cloudflare Workers made global deployment a `wrangler publish`, Postgres-as-a-service made the database a $0 line item up to real traffic, and — the one nobody's modeled yet — large language models made the documentation, marketing copy, and customer-support first draft a sunk cost of roughly zero.
Add it up and the question 'what's the smallest unit of software I can sell' now has an answer denominated in hundreds of lines of code, not tens of thousands. A single API endpoint that converts something to something else, wrapped in auth and Stripe, is a real business if 200 people need it badly enough. The Twitter-thumbnail generator. The OFX-to-CSV converter for accountants. The CRON-string-to-English translator with a Slack integration. These are not jokes. They are revenue.
What Brandur is implicitly pushing against is the SaaS-as-platform mindset that dominated 2015–2022: every product is supposed to expand its surface area until it eats the adjacent category. Notion eats docs, then wikis, then project management, then databases. The expansionist logic was funded by ZIRP and the assumption that CAC could be amortized over a 7-year LTV. In a 5% interest-rate world, with AI commoditizing copy-pasted feature work, the expansionist playbook has gotten genuinely expensive while the focused-tool playbook has gotten cheaper.
The HN commenter who put it best wrote: *"I built a thing that does one query against one table and emails the result. It pays for my Postgres and my coffee. It took a weekend. I am never building a 'platform' again."* This is not a failure mode. This is what the curve looks like when distribution is free and infrastructure is cheap.
There's a more uncomfortable corollary the essay gestures at without naming. If MVUSS is small enough to ship in a weekend, the moat is no longer code — there isn't enough code for there to be a moat. The moat is distribution, taste, and the willingness to keep showing up after the launch tweet stops getting likes. That is a craft problem, not an engineering problem, and most engineers are bad at it. That's also why these tools cluster around people like Brandur and Levels — operators who can write *and* code *and* talk to customers without flinching.
If you're a senior IC reading this between standups, the practical version is: you almost certainly have a single function in your head right now that could be a $5/month product, and the only thing stopping you is the assumption that it's not enough. It's enough. Ship it on Cloudflare Workers, put Stripe Checkout in front of it, write one launch post, and watch what the unit economics tell you.
The stack to actually do this in 2026 has converged: Workers or Fly for compute, Neon or Supabase for Postgres, Stripe for billing, Resend for transactional email, a static landing page on Vercel, and Plausible or self-hosted Umami for analytics. Total monthly cost at zero traffic: roughly $0. Total monthly cost at 200 paying customers: roughly $40. Gross margin: roughly 95%. There is no other category of business in the economy with these numbers, and the reason indie SaaS doesn't dominate everything is purely that distribution is hard and most engineers won't do the marketing work.
For teams inside larger companies, the read is different but related. The expansionist roadmap — "this quarter we ship the integration platform" — is increasingly competing against a dozen MVUSS-shaped tools that each do one slice of it for $9/month. Your enterprise sales cycle is 9 months. Theirs is a Stripe redirect. The asymmetry isn't going to resolve in favor of the enterprise platform unless the platform offers something genuinely impossible to replicate at the single-feature level — usually that means data network effects, regulatory cover, or deep ecosystem integration. Everything else is a question of when, not if, the unbundlers arrive.
The arc Brandur is describing isn't new — it's the same one that turned monolithic enterprise software into SaaS in 2008 and SaaS into APIs in 2015. Each turn shrinks the saleable unit and expands the addressable population of builders. The next turn, the one happening right now, is shrinking it again: from product to feature, from feature to endpoint, from endpoint to prompt. The builders who internalize this and ship accordingly — small, focused, profitable from week three — will look up in 2028 and find they've quietly built portfolios of six tools each grossing $30k/year, which is a $180k business with a one-person headcount. Whether that's a lifestyle or a launchpad is up to them. Either way, it's no longer a fringe pattern. It's the median outcome for the engineers who actually ship.
I feel like the build threshold discussed is _extremely_ optimistic?> But does that always hold true? Let’s take the other side for a second by examining a much higher-priced SaaS product. Gemini reports that the price of a fully loaded Salesforce seat is ~$500/mo. Say you need 50 seats, tha
I like that you point out that the cost to build software is still not 0. And in my expirence it’s further from 0 than I would expect. I often find myself thinking I can rebuild a project (or usually improve upon an existing one) in just a few days. And yet when it comes down to making anything well
“Build vs buy” assumes that there are only two parties. If it’s easier to build internally, then it’s easier for a 3rd party competitor to enter the market and bid the price down. I think the "zone of viability" is real, it just narrows and shifts downward.The author hints at this in a foo
I wouldn't underestimate the community effect of software. There are plenty of features that get shipped because a small but important minority requested them, only to benefit the long tail of users who never knew to ask for such a feature but now find it indispensable. If everyone is building
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I have multiple side projects that I would never have contemplated building before but whose utility now exceeds the much lower cost to build.I got a few weeks in to each and then stalled on all of them because the effort and motivation required to extend beyond the crazed early days _is_ still more