You know shipping imperfect beats waiting for perfect. You've heard it. You probably believe it.
And right now, you've got something that's close. Maybe a feature you built for your own workflow, or a tool you've been using solo for three weeks. It's 90% there, it works, a few people have seen it and want it. But there's this thing you keep tweaking. One more design pass. One more edge case. One more day of polish.
That's not iteration. That's procrastination with a keyboard.
The only way out is a date. Not a vague "I'll ship soon." An actual date. A date you write down, a date you tell someone else about, a date that forces you to cut scope instead of pretending you need more time.
Here's how to lock it.
Why a Fixed Ship Date Overrides the 'Done' Problem
The brain is terrible at "done." Done is subjective. Done is always one more thing away. But a date is a wall. A date says: this is the moment the work stops and the release happens. No more time for polish, no more revisions, no more "what if we...?"
A fixed ship date turns the problem from "Is this perfect enough?" (impossible to answer) to "Can we cut scope and ship this in time?" (actually decidable). Once the date is real and external, because you told someone, your brain stops arguing about perfection and starts solving for shipping.
How to Choose Your Ship Date
Pick a date that's soon enough to force real decisions but far enough away that you can actually execute. If you can ship today, tomorrow doesn't matter. If the date is two months away, you'll drift back to polishing.
One week out is the sweet spot for most projects. Enough time to kill the obvious blockers, not enough time to second-guess every decision you've already made.
Write it down. Tell someone. Post it somewhere you'll see it. The publicity is the thing that makes it stick.
Cut Scope, Not Time
The moment you lock a ship date, the only thing that moves is scope.
You realize you can't ship that secondary feature in time. Don't slip the date. Cut the feature. It can go in a 1.1 release. You find a bug that doesn't break the core flow. Don't delay launch, fix it after shipping. You want to rebuild the entire component because the code feels messy?
That's what happens after the ship date. Before it, you ship what you have.
This decision has to be hard and fast, because the alternative is you slip the date by one week, then one more, then suddenly you're three weeks out and nothing has changed except the date you tell people has moved twice.
Stop Polishing When the Clock Hits Zero
You need a hard stop. Not "I'll ship sometime next week." A specific moment: 48 hours before launch, or 72 hours, or whatever gives you time to do one final build and handle one actual emergency.
After that, you stop taking changes. No more commits. No more revisions. You announce it publicly: "Building now, shipping Friday at 5pm." That commitment to someone other than yourself is what stops the polishing hand.
The last thing you do is fix real bugs or actual breakage in the core flow. Everything else, edge cases and tweaks, ships post-launch or goes to the next version.
What Actually Happens After You Ship
You hit publish. Half the things you worried about don't matter. The things that do matter, you find out from users in the first 24 hours and fix them.
You learn more from shipping imperfect than you would from three more weeks of polishing. And you build momentum, which is its own kind of fuel.
That first ship, even if it's rough, is what lets the second ship happen faster. You've proven to yourself you can do it. The next one is less scary.
Template: Schedule Your Next Ship Date
Here's what to do today.
Pick a specific date one week from today, or whatever timeframe actually works for your project. Write it down. Add it to your calendar. Tell someone whose opinion matters to you: a friend building the same thing, a co-founder, someone on Slack who's following your progress.
Then make one decision: what is the core thing users need to do with your product to consider it shipped. That's what ships. Everything else is post-launch.
Now cut the scope to fit that date. It's going to feel like you're leaving money on the table. You're not. You're shipping.
FAQ
Q: Should you ever slip the ship date if something important breaks near launch?
A: Almost never. Only slip if the issue makes your product genuinely unsafe or unusable for the core use case. A bug in a secondary feature or missing polish is not a reason to slip; ship and fix it post-launch.
Q: What if you announce a public ship date and then realize halfway through you can't make it?
A: Announce the slip immediately. Don't wait until the day before. A one-week slip announced at day 3 is a pivot; a slip announced on launch day is a disaster. Be honest about why: scope was too big, you hit unexpected blockers, whatever the real reason is. Then set a new date the same way you set the first one. The embarrassment of having to move it is actually the prevention mechanism that keeps you honest about deadlines in the future.
Q: What if your team disagrees with the ship date or wants to extend it?
A: The date isn't arbitrary. It's a decision the whole team needs to agree on upfront, not something imposed on them. If they think the date is impossible, the question is always: what ships and what gets cut? If they disagree philosophically about shipping early, you need alignment on why you're doing this first. But once the date is locked and everyone commits to it, it's not negotiable. "Just one more week" is how dates slip.
Q: How do I know what counts as the core thing my product needs to do?
A: What would make your first user say "this solved my problem"? Not perfectly, just solved it. That's the line. Can they do the main job you built this for without major friction? Yes, it ships. Everything else that would be nice but isn't essential, that's iteration and version 1.1.
Q: Does this ship-on-a-date approach work for refactors and internal work, or just new features?
A: It works for any project with defined scope: new features, refactors, internal tools, design overhauls. The date discipline forces you to ship what you have and iterate, regardless of what you're building.