When Good Enough Is Good Enough

Last edition we asked whether you should vibecode your MVP or hire an agency. A lot of founders wrote back. And the most interesting conversations weren't about the tools. They were about the moment just before everything got complicated. “We had traction. We had users. And then we didn't know what to do next.” Which is exactly where this one starts.

Founders spend a lot of time asking whether the product is ready. Ready to ship. Ready to show investors. Ready to scale. We believe this is half the question. The product doesn't exist in isolation. It exists inside a moment. And the same product that's exactly right for one moment is exactly wrong for the next.

Good enough is a property of what you still don't know.

When you don't know if this is worth building

In this mode, good enough is the correct strategy. Every dollar you spend on infrastructure you might not need, every week you spend on edge cases that might never get hit, every architectural decision you make to support a scale you haven't earned yet. That's money, time and cognitive load you spent on a bet that hasn't been confirmed yet. The job is to find out if there's something real here. And the fastest way to do that is to build the thinnest version that can generate a true signal. Not a polished version. Not an impressive one. A true one. Vibecoding was made for this moment. The speed is the point. The roughness is the point. You're not building a product yet, you're running a question.

When you know it's worth building, and now you have to grow it

This is a different job entirely. And it requires a different product, not because the old one is broken, but because the old one was built to answer a question that's now been answered. In this mode, the things that didn't matter before start to matter. A lot. Load. Security. The data model that made sense for ten users but creates real problems at ten thousand. The authentication you wired together on a Sunday because you just needed something to work. The onboarding that only functions cleanly if you already know what you're doing. These were decisions correct for the moment they were made, in a mode that's no longer the current one. The problem is that the mode changed, and the product didn't.

The gap between modes is where product rescue lives. The concept isn't new. The conditions are. It's what we keep getting called in for.

A founder builds fast. Vibecoding, freelancers, whatever was available. Gets traction, raises a round, starts hiring. And then discovers that the foundation can't hold the weight of what they've actually built. Users are on top of it. Revenue is moving. The product is real. And underneath all of it is something that was built to answer a question, not to run a company.

It could be the codebase. Or the design system that worked for one persona and now has to hold five. Or the jobs the product was built around that aren't the jobs anymore. Or the process that got it here.

The rescue isn't always a teardown. Sometimes it's a line edit. Sometimes it's a rewrite.

Product rescue is triage. What's worth keeping. What needs to be rebuilt underneath. What has to change before the next thing can be added without breaking the last one. It costs more than making those decisions at the right time, not because the original work was wrong, but because now you're working around something real. You can't pause the product to fix the product. Everything happens in motion.

Eric Ries told us “to fail fast”. The version we live in now with AI, is fail fast and epically. The tools we use to build are responding at a scale that wasn't possible before. The wins are bigger. So are the failures.

The founders who avoid the painful version aren't the ones who built more carefully from the start. They're the ones who recognized when the mode changed. And made a decision instead of just continuing.

The diagnostic

The honest way to know which mode you're in is one question: What is it that you still don't know? If the answer is “whether this is worth building”, you're in mode one. Move fast. Good enough is right. The product's job is to generate signal, and signal doesn't require perfection. If the answer is “how to grow this”, you've crossed. And the product you used to generate the signal is probably not the one that should be running the business. That crossing doesn't come with a notification. The product keeps working. Users keep arriving. Revenue keeps moving. And somewhere in the middle of all that motion, a decision that nobody made out loud is getting made anyway. Just more expensively, and later.

Good enough is always the answer. The question is: good enough for what moment.

The Lean Startup, Eric Ries (2011).