In Defense of Shipping Something Imperfect

There's a version of this post that's been sitting in my drafts for six months. It had better structure. More examples. A cleaner argument. I deleted it and wrote this one instead. That felt appropriate. We work with a lot of founders who are building their first serious product. And the pattern I see most often — the thing that kills more projects than bad code ever could — is the fear of releasing something that isn't finished. Here's the thing: it's never finished. Software is not a physical product. You don't manufacture it once, ship it, and move on. You ship a version, observe how people use it, and use that information to build the next version. The feedback loop is the product. When you delay shipping to make something more perfect, you're not improving the product — you're deferring the feedback that would actually tell you what to improve. What "done enough to ship" actually means. It doesn't mean buggy. It doesn't mean embarrassing. It means: the core use case works, it works reliably, and it's not lying to the user about what it is. The best framing I've heard is: would you be comfortable if a journalist wrote about this version? Not comfortable in the sense of "it's flawless" — comfortable in the sense of "this does what we say it does." If the answer is yes, you're probably overthinking it. The thing nobody tells you about perfection. Perfect is a moving target. The version you're agonising over right now — the one that isn't quite ready — will look rough six months from now regardless. Not because you'll regret shipping it, but because you'll learn so much from shipping it that the current version will seem naive. Every hour spent polishing before launch is an hour you're not spending learning from real users. And real users always know things your team doesn't. A practical rule we use. When a project is running long because we keep finding things to improve, we use a simple test: is this a "must-fix before launch" or a "can fix in the next iteration" issue? If it doesn't break the core promise of the product, it's the second one. We keep a list. We call it the "Week 2 list." Almost everything ends up there. Almost nothing on it turns out to matter as much as we thought before we shipped.