You already know this: shipping imperfect work beats polishing in private. You've heard it, you believe it, and you've done it before.
But right now you are sitting with one project that keeps pulling you back. The core works. Users could use it today. And yet your brain keeps whispering "just one more thing", a missing detail, a rough edge, a feature that would make it feel complete.
The trap is not belief. You believe in shipping. The trap is decision. When exactly do you cut it loose?
Here's what separates shipping from procrastination: a ruthless definition of done. Not the polished version you imagined. The version that actually works right now.
How to decide when today's version is done
The definition of done has two parts: what HAS to work, and what CAN wait.
What has to work: core functionality. If you shipped it, users have to be able to use the primary thing you built. If it is broken, don't ship.
What can wait: everything else. Polish. The edge case. The missing flow. The thing that makes it feel "finished." These do not block shipping.
Write these down. Seriously. Make two lists. One is a blocker, one is not. The person who can tell the difference between the two is the person who actually ships today.
Most people mix them. A typo feels like a blocker. A missing refinement feels critical. They are not. A typo is cosmetic. A missing flow is feedback waiting to happen.
The cuts that actually matter
You are going to cut something. The question is what.
Cut: visual refinement, nice-to-have copy, edge cases that don't affect the core flow, anything you think "users want" but haven't confirmed they want.
Don't cut: functionality that makes the core thing work, anything that breaks the primary user path, fixes for bugs that actually block usage.
The difference is this: would a user today be able to do the main thing you built? If yes, ship it. If no, fix that first, then ship it.
Most polishing is in the "cut" category and feels like "don't cut." Your job is to tell the difference. It gets easier after you do it once.
Version zero: shipping a real example
Let me give you a concrete one. I built a simple notification system for teams to send updates to their Book of Business without ever leaving their CRM.
Core functionality: create a message, pick the recipient list, send it. Done.
What I almost didn't ship: a template library, custom formatting, scheduling for later, read receipts. Felt incomplete. Felt like it needed those things.
What I shipped: create message, pick list, send it. That is it. The refinement came after users had sent a hundred messages and told me what they actually wanted.
If I had waited for the template library, the product would have sat on my hard drive for another month. Instead, I shipped, got feedback, and built the right features instead of the ones I guessed at.
Shipping with known gaps
When you ship today's version, you ship with gaps. Your job is not to hide them. Your job is to be specific about them.
"This is ready to use today. Known gaps: no bulk export yet, notifications won't work on mobile for a few days, the API isn't public yet."
That is not a disclaimer. That is honesty. Users respect it. They know what to expect. They will not discover broken things later.
The alternative is shipping something you think is complete but isn't. Users hit an undiscovered gap, assume the feature is broken, and leave. Much worse than telling them upfront.
Why iteration in public beats polishing in private
Polishing in private is building a sculpture in a locked room. You refine it over and over. It gets closer to perfect. You ship it when it is perfect.
Iteration in public is building a sculpture while people watch. You ship a rough version. They tell you what is wrong. You refine it in front of them.
Which one ends up better? The second one. Not because public pressure makes you refine faster, but because real feedback beats your own judgment every time.
You cannot guess what users need. You can only build, ship, watch, and adjust. The only blocker is the core thing has to work.
FAQ
Q: What's the difference between shipping today and being reckless?
Shipping today means releasing your working version with known, non-blocking gaps; being reckless means ignoring actual breaking issues. The difference is deciding ruthlessly what breaks functionality (don't ship those) vs what just feels incomplete (ship those).
If a user can't use the main feature you built, it's a blocker. If they can use it but it feels rough around the edges, that's the gap you ship with.
Q: What's the difference between today's version and an MVP?
An MVP is the minimum set of features needed to test a hypothesis with real users; today's version is whatever works right now, with gaps, for your actual current use case. You can ship today's version to see what people use; MVP is a planning concept.
Today's version assumes you already have users or you already know your hypothesis. You are not trying to discover if people want it. You are trying to let them use what you built.
Q: What do you do when your team wants to polish more?
Name the trade-off explicitly: shipping today trades short-term polish for long-term momentum and real user feedback. Set a clear definition of done (functionality works, known gaps listed, no blockers) and ship to that bar, not the perfection bar.
The conversation is not "Should we ship?" but "What are we betting on: polish or speed?" Most teams choose speed when they say it out loud.
Q: What if users hate the gaps you shipped with?
You learn which gaps actually matter; users show you priorities faster than guessing during polish. Ship, gather feedback, iterate, the cycle is faster than polishing in private and discovering you built the wrong thing.
A user telling you they hate a gap is valuable information. It tells you what to build next.
Q: What should you do if you discover a critical bug the day after shipping?
Ship the fix immediately; this rapid response is the core advantage of shipping today. You can patch critical issues in hours instead of weeks, and users see fixes right away instead of waiting for the next planned release cycle.
Speed of shipping means speed of fixing. That is the game.