The saddest "Just Ship It" story ever (2020)
A widely shared blog post about an indie productivity app that never launched – only to be overtaken by a slower, buggier competitor that did – has reignited perennial debates over “just ship it” in software. Commenters weigh the value of early, imperfect releases for learning, market validation and avoiding years of wasted effort against the user fatigue caused by half-baked products and mounting technical debt. The thread broadens into questions of engineers’ responsibilities: balancing code quality with business needs, when to resist deadline pressure, and how much workers should care about profitability if they don’t share directly in the upside.
Emotional impact of being scooped
- Many relate deeply to discovering “someone else shipped my idea first” after years of tinkering.
- Common arc: grief, regret, self‑recrimination, then reframing it as learning about tech, pace, and personal preferences.
- Several say the bigger regret is not continuing or not shipping, not being second.
“Just ship it” vs quality / first impressions
- Strong support for shipping early to test if anyone cares, avoid building in the dark, and reduce emotional load.
- Others stress: “first impression” matters; shipping obvious‑to‑you, confusing‑to‑users UIs can burn credibility.
- Nuanced view: “shipping” can mean private betas, friends, or target users, not necessarily a public launch.
Solo projects, MVPs, and feedback
- Multiple stories of multi‑year side projects that never launch due to perfectionism, life changes, or loss of belief.
- Tactics suggested:
- Explicitly list compromises you will not address before launch.
- Stage work so you only automate things (billing, lifecycle) once real users show up.
- Use your own tool “for real” to recalibrate expectations; users tolerate more rough edges than creators think.
Role of engineers vs business and sales
- Big debate: is a developer’s job to “write great software” or to help make the company money?
- One camp: engineers should resist “just ship it” pressure, prioritize craftsmanship, and protect themselves from burnout.
- Counter‑camp: everyone’s job is to support profitability and product value; over‑engineering is bad engineering.
- Consensus middle: engineers should clearly communicate trade‑offs (quality, risk, timelines), then collaborate on compromises.
Ideas, cofounders, and equity
- Several anecdotes about “idea guys” demanding 50% for vision while engineers build everything.
- Many argue execution, sales, and long‑term iteration matter far more than the original idea.
- Good sales or product‑oriented cofounders are described as game‑changing and often worth equal equity—if they truly execute.
Market and competition for productivity apps
- Commenters note todo/habit/productivity apps are extremely crowded; parallel invention is expected.
- Being first is seen as less important than iterating, differentiating, and maintaining momentum.
- Some skepticism that yet another productivity app is special; others argue niches and better execution still have room.
Update from the article’s author (in comments)
- The author later states they did eventually ship their app and now iterate on it.
- Landing page and UX receive both positive interest and critical feedback (performance, wording, timezone labeling).