Every engineer faces this tension: ship now with rough edges, or polish until it's perfect?
The perfectionist voice says wait, it's not ready. The pragmatist voice says ship it, we're burning time. Both are right sometimes. Here's how I decide.
The Default: Ship at 80%
Most work should ship when it's 80% done. Not 100%. Not 50%. 80%.
Why 80%?
- The last 20% takes 80% of the time (Pareto principle)
- Users give feedback that changes your direction anyway
- Shipping reveals problems you can't predict
- Done is better than perfect
If you're building a feature, get it working, test the happy path, ship it. You can handle edge cases when users actually hit them.
When to Polish More
Some situations demand the extra 20%:
Security and Data Integrity
Never ship 80% security. Auth, encryption, data validation — these need to be right. A security bug isn't "we'll fix it later." It's a breach.
Public APIs
Once an API is public, changing it breaks users. Think carefully about contracts, error formats, and versioning before exposing them.
Core Workflows
The main thing your product does? Polish it. If your app is a todo list, the "add task" flow better be bulletproof.
First Impressions
Onboarding, landing pages, first-run experiences. Users judge quickly. A rough first impression is hard to recover from.
When to Ship Faster
Some situations demand speed over polish:
Internal Tools
If only your team uses it, rough edges are fine. You can explain quirks and iterate without support overhead.
Experiments
Testing a hypothesis? Ship the minimum that proves or disproves it. Polish is wasted if you're about to pivot.
Time-Sensitive Opportunities
A competitor launching? A customer waiting? Speed matters. You can polish while they're using it.
Already Behind Schedule
If you're already late, more polish rarely helps. Ship what you have and iterate.
The Reversibility Test
Ask yourself: how hard is this to fix later?
Easy to fix later:
- UI tweaks
- Copy changes
- Feature additions
- Performance optimizations
Hard to fix later:
- Database schemas
- API contracts
- Security models
- Architecture decisions
Bias toward shipping things that are easy to change. Bias toward polishing things that are hard to change.
The "Ship and Iterate" Trap
"We'll fix it later" is dangerous when you don't actually fix it later.
If you ship fast, you need:
- A way to know what's broken (monitoring, user feedback)
- Time to actually iterate (not just shipping feature after feature)
- Permission to prioritize fixes (culture that values maintenance)
Without these, "ship fast" becomes "accumulate debt forever."
My Heuristic
When deciding whether to ship:
- Is it safe? Security, data integrity, core workflows. If no, keep working.
- Is it reversible? Easy to change later? Ship it.
- Is it blocking something? Users waiting? Feedback needed? Ship it.
- Am I procrastinating? Be honest. Ship it.
Most hesitation is fear, not wisdom. Ship.
How do you decide when to ship? I'm always curious about other engineers' heuristics.