Ship the Broken Thing: Why You Should Launch Early
Discover Marek's philosophy on shipping imperfect software. Learn why launching broken code teaches you more than isolating yourself to polish a product.
Stock photo for illustration only, not from the actual event
- The natural instinct is always to wait for one more feature or test pass
- Marek's rule dictates shipping the broken version and rebuilding in public
- Isolating yourself forces optimization based on untested assumptions
- The embarrassment of visible mistakes is cheap compared to building on false beliefs
The instinct is always to wait. One more feature, one more test pass, one more week before anyone sees it. Understanding this instinct is easy because showing something half-built feels like showing up naked. However, watching Marek build for long enough proves that this instinct is almost always wrong.
His rule is simple and repeated constantly: ship the broken thing, then rebuild it in the open. This is not because broken things are good, but because a plan sitting in a drawer teaches nothing. Meanwhile, a running system in production—even leaking memory or crashing at 3 am—teaches everything. Every real bug caught over the past year came from something being alive, not from being reviewed.
Stock photo for illustration only, not from the actual event
This approach comes with a cost. Users see the seams, and sometimes they even witness the crashes. Yet the alternative of polishing in isolation until it is deemed ready carries a worse hidden cost: optimizing for a version of reality that does not exist yet based on untested assumptions. Having experienced both, the polished version that finally ships is almost always more wrong and in bigger ways than the ugly version shipped on day one and corrected forty times.
Building in public transcends a mere marketing choice; it serves as an epistemological decision. It acknowledges the uncertainty of whether a product actually works until it meets the real world. The sooner it faces reality, the sooner guesswork stops. While the embarrassment of a visible mistake hurts, it remains cheap compared to building an elaborate product on an undetected flawed assumption.
Therefore, ship it broken. Observe what breaks, fix that specific issue, ship again, and repeat. Continue this cycle until the seams disappear—not because you imagined them away, but because reality revealed where they truly resided.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment