The ROI Test Just Died
hatch
For thirty years, the first question before building anything was “will this be worth it?” That question is dead. I killed a small piece of it on a Saturday morning, on my deck, with a cup of coffee and one sentence typed into my phone.
I wanted a clean read on the World Cup schedule dashboard. Game times, teams, location, which streaming service had each match (with live updates as a bonus and only client-side - no backend). That information existed everywhere and nowhere — scattered across a dozen pages, none of them showing me the one thing I actually wanted in one glance. So I opened the Claude app on my phone, typed a simple short prompt describing what I wanted, and hit go. About ten minutes later I had https://www.hatch.org/world-cup/ — a clean, shareable schedule that did exactly one thing. I sent it to family and friends. It will be useful for about a month. Then the tournament will end and so will the app’s reason to exist (for maybe another 4 years).
Now here’s the thing. I’ve been building software since I was a kid. I could have built that schedule the old way — hand-coded, deployed, the works. I just never would have. A one-month shelf life never cleared the bar. The effort never penciled out. What changed isn’t my ability. What changed is the math.
Quick roadmap:
- The ROI gate that decided what got built for three decades — and why it just collapsed.
- The flip: I always could build it. The news is that I finally would — and so can anyone, builder or not.
- The honest “but”: disposable in intent is not the same as disposable in consequence.
- The new literacy: knowing the difference between disposable-safe and disposable-reckless.
The ROI gate that governed building for thirty years (and why it’s gone)
Every piece of software you’ve ever used cleared a gate. Someone, somewhere, asked: is this worth building? Worth maintaining? Worth the years of patches, dependencies, and on-call pages it will demand for the rest of its life?
I ran an org at Amazon/AWS scale where that question was sacred. Every line of code was a long-lived liability. You didn’t write something unless you were prepared to own it for years — because durable software is durable maintenance, and durable maintenance is durable cost. That calculus is the most reliable law I know in this industry. Build-versus-buy, in-house-versus-vendor, ship-versus-skip — every one of those decisions ran through the same filter: amortize the effort over the lifespan, and if the lifespan is short, don’t bother.
That filter assumed one thing above all: building is expensive. It always was. So the only software that got built was software worth keeping.
Now building a single-purpose app costs ten minutes and one good prompt. Andrej Karpathy described it as software on a tap — bespoke, single-use apps you summon when you need them. a16z gave the category a name, “disposable software.” When the cost of building drops to near zero, the lifespan stops mattering. A one-month app pencils out. A one-afternoon app pencils out. The gate that protected us from wasting effort on short-lived things has nothing left to protect, because there’s no effort left to waste.
Translation: durability used to be the price of admission. Now it’s optional.
The math that flipped: I could build it; the point is I finally would (and so can anyone)
There’s a tempting version of this story where the hero couldn’t code and now miraculously can. That’s not my story. The Verge ran a piece where the author confessed, “I am not, by any traditional measure, a developer,” and then shipped an app anyway. Great hook — but it’s the wrong frame for what actually shifted, and it’s not me.
I’m a developer. I’ve always leaned toward building. So when I tell you the change isn’t about capability, I’m telling you from the side of the line that already had the skill. The change is about justification. The World Cup dashboard didn’t get built because I suddenly learned something. It got built because, for the first time, a thing with a one-month shelf life was worth the ten minutes.
And here’s the genuinely big part: the skill floor dropped out from under the whole thing. Claude can ship artifacts as shareable apps — no API keys, no deploy pipeline, working from a phone. So the unlock isn’t that I can now build disposable software. It’s that anyone can. The economics flipped for the people who could already build, and the door swung open for the people who never could.
That’s the whole point. Not “look what I can do.” Look what just became worth doing — for everyone.
The honest “but”: disposable in intent ≠ disposable in consequence
Now the part where I argue against my own enthusiasm, because a builder who only sells you the upside is selling you something.
The app is throwaway. The data it touches is not. And the early evidence is already ugly.
A vibe-coded app on Lovable leaked 18,697 records through inverted authentication — the kind of bug that takes one wrong prompt to introduce and a real person’s data to expose. The Cloud Security Alliance logged AI-generated-code CVE disclosures surging from 6 to 15 to 35 across January, February, and March of this year. Vercel’s Tom Occhino calls the wave of disposable apps “the world’s largest shadow IT problem.” He’s not wrong.
And there’s a sharper objection worth steel-manning. Andreas Kirsch argues in “The Flawed Ephemeral Software Hypothesis” that cheap generation doesn’t actually make software ephemeral — it just relocates the cost. The cost doesn’t vanish; it moves to validation, to integration, to keeping interfaces stable over time. Generating the code was never the expensive part. Being sure it’s correct is.
I think Kirsch is right, and I think that’s exactly the resolution. Disposable is correct precisely where being wrong doesn’t matter. My World Cup dashboard is read-only, holds no one’s data, and the worst-case failure is a wrong kickoff time I’d notice and fix in a prompt. Disposable is reckless precisely where being wrong does matter — anything authenticating users, anything touching money, anything holding data that belongs to someone other than you.
What’s actually worth keeping (the new literacy: telling disposable-safe from not)
The old skill was building. The new skill is judgment about what’s safe to throw away.
For thirty years we didn’t have to develop that muscle, because the ROI gate did the sorting for us. If something wasn’t worth keeping, it never got built, so it never got the chance to leak, break, or rot in production. The gate was a crude filter, but it was a filter. Now it’s gone, and the sorting falls to us.
So here’s the test I run now, and the one I’d hand to anyone:
- Does it hold anyone else’s data? If yes, it’s not disposable — no matter how short its intended life. Build it like it’ll outlive you, or don’t build it.
- What’s the worst-case failure? A wrong kickoff time is an annoyance. A leaked record is a person harmed. Those are different universes.
- Would I be embarrassed if this ran forever? Disposable apps have a way of not dying. If “forever” scares you, treat it as durable from day one.
Pass all three and you’re in the zone where disposable isn’t just acceptable, it’s optimal — where spending durability you don’t need is the actual waste.
The ROI test that governed building for a generation is dead. Good. It was always a tax on imagination, a toll booth in front of every small useful idea that didn’t quite justify the drive. What replaces it isn’t “build everything.” It’s something harder and more interesting: build freely, and know — in your gut, in one glance — which of those throwaway things you’re actually allowed to throw away.
I built a World Cup dashboard over coffee and may delete it from my mind a month later. That’s not the impressive part. The impressive part is that the question “was it worth it?” never came up. For the first time in thirty years, it didn’t have to.
BTW, I also open sourced the dashboard if anyone wants to update/fork it: world-cup-2026-dashboard