A Product Is a Promise

This is going to come off as grumpy, but it needs to be said: Stop showing people your junk. Everyone can build junk with AI now. Nobody else wants to see your junk. We’re not kindred spirits just because we both build junk. Play with your junk strictly in private. Thank you.

—Steve Yegge

It’s 1:30 a.m. and your clankers are still chewing through three parallel work sessions. The tasks are endless; there’s always one more tweak, one more idea to try, one quirk in the UI that feels grating. You ask the agents to look for obvious code smells. To do a quick DRY refactor. To remove over-engineered tests that add no value. You can’t be bothered looking at the code: the project is small enough that a little slop won’t confuse your tireless minions for at least a few thousand more lines. Either way, this doesn’t need to be avionics-grade; it’s just your first attempt at something people may never even look at.

You reach a point of diminishing returns; all the low-hanging fruit is gone. The basic idea for the product is etched into a few dozen files.

“Phew, not a bad MVP for a couple of weekends of work,” you tell yourself. The landing page is up, Stripe is connected, and the GitHub README is human-friendly. Time to share it with your circles. You announce the launch on several WhatsApp groups and a couple of Slack communities. You ask people to try it and tell you what they think. Your app solves a personal problem; others will surely relate.

Crickets. Your acquaintances must be slammed with work. Probably just bad timing.

“Huh, odd. Maybe I need a bigger audience,” you think to yourself as you submit the app to a few tech watering holes.

Zero upvotes. The Reddit post gets taken down for promoting AI slop. X gives you 12 impressions before deciding you’re not worthy. A commenter on HN asks why we need another one of these. The world is drowning in zero-star GitHub repos and cookie-cutter Claudish landing pages that promise to solve increasingly niche problems. Same styling, same copy, same generated assets.

Agentic coding in 2026 lets the average person spawn their dream app: pay the token slot machine for enough pulls, and you eventually get something resembling your original idea. This hugely reduces the barrier to entry for the uninitiated. For seasoned pros, the tools amplify expertise and accelerate development beyond anything available to previous developer generations. A startup can get an MVP to market in hours.

Valuable applications have emerged from this explosion of developer productivity. And yet, nobody is using 100 times as many of them. Everybody is stuck on the same dozens of mobile apps they’ve been using for years. The same social sites. The same business software from long before ChatGPT was a thing. Countless weekend vibe-projects and rushed startup MVPs die on the vine, leading their creators to wonder why.

What’s going on? Where are all the applications delivering delight and productivity? Why are our minds not blown by the flood of game-changing products made by people taking creative risks never seen before?

Part of the answer is that faster dev cycles don’t make it any easier to discover what people want. Without talking to users, you simply build the wrong thing faster, and that’s what ultimately kills most projects. Talking to people still happens at human speed.

Even solid customer-centric products promising something new still struggle with adoption. Society has a speed limit for absorbing change. At the beginning of the current tech wave, that limit is lower than most AI bulls anticipated.

And there’s only so much human attention to go around. With the number of projects on offer increasing by a couple of orders of magnitude in the span of a few years, GitHub is now absorbing 24 million new repositories a month and scrambling to keep the lights on. We still have the same number of hours in the day to try something new.

What is a product designer to do when faced with such poor odds?

Most MVPs do not make a credible promise. A product is a promise that its creator understands the user’s problem, has the judgment to solve it, and will keep doing the work after the user comes on board. It’s a fair trade: the user’s time — maybe even money! — for the creator’s past and future investment in their creation.

And part of that promise isn’t yours alone to make. A great product carries an implicit claim that other people are already here and glad they came: that someone else hit the sharp edges first. Every user who sticks around confirms to the world that the promise is being upheld.

Your vibe-coded offer has to make that promise credible, and most MVPs can’t do that. The application might work; it might even solve a pressing problem. But prospective users have little reason to believe you understand it deeply, have worked through the gnarly details, and are ready to enter a long-term relationship. They might even be user number one. Why should they believe you won’t lose interest and abandon them when maintenance gets tough or when something else shiny distracts you? They might be better off one-shotting something with Claude if it gets them the same result.

The problem isn’t new. “Build it and they will come” never worked to begin with in crowded markets. Shipping something was never sufficient on its own, but it counted for more when high costs and specialized knowledge kept supply permanently scarce.

But in 2026, it’s never been easier to assemble a digital product. The CRUDdier, the better. What previously required weeks of work, technical chops, and focused dedication is now only a few prompts away from reality. Why should the user give attention to something that required little from its creator? Subconsciously, something about that human-time-in-exchange-for-machine-time feels unfair.^{1 2}

Good marketing can communicate the promise and persuade someone to give a new product its first chance. A compelling story can make the claim sound credible, but most people notice an overpromised product once they’re inside. The real proof comes from keeping a product useful, reliable, and well maintained, then communicating that work over a long stretch of time.

The answer is to make the promise credible through deep problem expertise, visible judgment, and stewardship. Expertise helps you build the right thing. Writing, speaking, and open-source work let users assess your judgment before they invest their time. Stewardship gives them a reason to stay and recommend the product. Three recent products show how this work turns into adoption.³

Handy fits this. Announced with barely an upvote, it garnered a major following over the next year by doing the hard work of stewardship and fulfilling the initial promise of privacy and simplicity. The author, CJ, actively polices every PR, rejecting many that don’t fit. The product stays minimalistic, intuitive, and maintainable. It’s used by thousands of people actively reporting issues on Discord and GitHub. Those same users recommend it enthusiastically.

Ghostty embodies this strategy. Its founder, Mitchell Hashimoto of HashiCorp fame, invested more than two years in it and ran a private beta with around 2,000 testers before asking the wider public to care. He did this as a passion project with no plans to commercialize it. By launch, users could see the promise in the work: a professional tool, clear product judgment, and a community that had already hit the sharp edges. His reputation earned attention, but the accumulated evidence made adoption feel safe.

OpenClaw took the opposite route. steipete channeled the chaos, bringing it into the world early, rickety and weird, then taking everyone along for the ride. He talked about it constantly, shipped at a maniacal pace, and merged PRs as if his life depended on it. The lobster memes helped, but the real pitch was his relentless presence and visible judgment. Peter never promised that OpenClaw would be stable. He promised that he’d be there in the middle of the night fixing bugs, day after day, for as long as it took.

I experienced firsthand the cost of upholding the promise while building Koom, a self-hosted desktop screen recorder and web viewer designed as a low-cost alternative to tools charging $20 a month. Like many others, I had vibe-coded the tool over many weeks to solve a personal problem and threw it out into the world to see if it would stick. No lofty goals, just curiosity about whether the problem would resonate with others. For a few, it did, but ultimately, what killed it was my own lack of commitment to the promise.

Soon after an early release, a few internal users started asking for changes.

“Does the client work on Windows?” Nope. Sorry, I’m on macOS. In theory, I could work on supporting that. Doing so sounds boring and requires a lot of extra work for — currently — no payoff.

“Why can’t I hear the voice as clearly in recordings made with microphone model X?” Not sure. At the moment, I only have so many mics to test with, and so far, it hasn’t happened to me. I could eventually track this down, but that’s a lot of work.

“Can it be hosted on custom PaaS XYZ instead of current PaaS ZYX?” Yep, and that’s probably the right move in the long term, but it will require a bunch of thinking, branches, testing, and commitment to functionality that I won’t personally enjoy.

You get the idea.

Pretty quickly, the joy of making something for my personal happy path turned into the pain of productionizing for a broader audience whose needs I didn’t relate to. Requests turned into decisions that turned into hours of work that turned into surface area I needed to vouch for in perpetuity but didn’t care much for. That reluctance told me I didn’t want to shepherd the tool after all.

Had I had it in me to grind this out for a few months and talk about it incessantly in public, I would have accrued users. But I quickly realized I didn’t have it in me; I wasn’t going to make that promise to its users.

The weekend builder hoping to strike gold and the startup rushing to market make the same mistake: they think that an MVP’s existence is enough to justify adoption.⁴ But a landing page, a Stripe integration, and a working first iteration prove only that the thing can be built, and we already knew that. In 2026, that is no longer enough. Crickets at launch are just the starting point; the continued work and advocacy are where real growth happens.

Next time you’re chasing agents at 1:30 a.m., ask what you’re promising anyone who decides to depend on your project. Will you still be there when the novelty fades and the Windows port, the obscure heisenbug, and the thousand dull decisions arrive? Will you climb out of the swamp of zero stars, earn your first users, and keep the promise that gives them a reason to stay?

Notes