I've watched brilliant ideas die in planning documents. Projects that never launched because they weren't "ready." Decisions delayed until the moment evaporated. Strategies so polished they never saw daylight.
The pattern is predictable and painful: we wait for certainty that never arrives, chase perfection that doesn't exist, or stall for conditions that keep shifting like sand.
Ship it or kill it is my antidote. Make the call. Take the action. Learn from reality instead of the fiction in your head.
If something isn't worth doing imperfectly, it probably isn't worth doing at all.
The Certainty Lie
Here's the uncomfortable truth about perfectionism: it's not about quality. It's about fear wearing a productivity costume.

We tell ourselves we're being thorough. Responsible. Strategic. But what we're actually doing is hiding from the possibility of being wrong in public.
I've spent years in technical strategy delivery, and I can tell you: the teams that ship messy v1s consistently outperform the teams crafting pristine vaporware. Not because messy is better, but because reality is the only teacher that matters.
Parkinson's Law nails it: work expands to fill the time available. Give a perfectionist six months, and they'll use every day "refining." Give them two weeks, and suddenly they discover what actually matters.
The difference isn't capability. It's constraint.
The BurnFriends Story
BurnFriends didn't start as a "vision." It started as the pandemic doing what it did best: turning normal humans into little goblins who will try anything for structure.
For me, that structure looked like:
- spin classes with my dad (yes, really)
- daily calls with my friend David (because apparently we're the kind of people who cope with chaos by aggressively scheduling connection)
On one of those calls, David tells me his friend group wants an easy way to stay fit together—specifically, to walk more. They'd tried other apps, but nothing stuck. Nothing made it fun.
And I remember thinking: this is a product. Not because other fitness apps were bad, but because the intent was great: people wanted accountability and motivation through friendly competition—something that actually made walking exciting.
What if we built a fitness app with a leaderboard to spark competition and a tamagotchi-style digital pet phoenix that thrives when you walk and wilts when you don't? Gamification that actually works.
This is where I pulled out my favorite story from that one ceramics teacher (the "Quantity vs. Quality" class). Half the students were told: make one perfect pot. The other half were told: make as many pots as possible. The twist: the "quantity" group got better faster because they learned by doing, not by philosophizing about glaze.
My dad has an even punchier version of that philosophy, and he says it like a battle cry:
"Let's do something, even if it's wrong!"
So David and I did the thing: we threw our hats over the fence and committed to a 6-week sprint. Not "a roadmap." Not "a discovery phase." A deadline.
The method was simple and mildly unhinged:
- 6 weeks total
- build in public (ish)
- weekly video reveals to keep us honest (and slightly terrified)
Tooling was also equal parts real and chaotic:
- Xcode
- Swift
- and some no-code magic with Make.com to glue things together before we had any business "engineering" them
Six weeks later, BurnFriends had ~200 concurrent users.
And here's the part I still love: about half were total strangers. Not friends being polite. Not my mom trying to be supportive while asking why the button is purple. Random humans… voluntarily showing up.
That's the Magic Click, by the way. Not "the app works." The moment you realize the why is landing with real people—and suddenly the what stops being theoretical.
Also: we didn't achieve that by perfecting. We achieved it by shipping, watching reality punch holes in our assumptions, and iterating before our confidence could talk us out of it.
The 2-Week Rule: Side Projects Edition
Every side project at Diversified Fun follows the same constraint: 2 weeks max to v1. If we can't ship something usable in 14 days, we're either building too much or the idea isn't clear enough.

Here's the current scoreboard:
| Project | What It Does | Time to Ship |
|---|---|---|
| Alty | AI alt text generator | 2 days |
| Seggy | Section title generator | 8 days |
| LinkSleuth | Broken link checker | 1 day |
The deadline isn't about rushing or cutting corners. It's about forcing decisions.
When you have two weeks, you can't build everything. You figure out what actually matters versus what's just "nice to have." You learn to distinguish the essential from the ornamental.
This is where The Magic Click happens: that moment when a team suddenly understands the why behind the what. Constraints create clarity. And clarity creates momentum.
At Work: Done Beats Perfect (Every Time)
In my advisory work, I see teams paralyzed by perfectionism constantly. The migration plan that keeps getting revised. The feature that's been "almost ready" for months. The decision that needs "just one more analysis."
This is Engineering Intent Decay in action: the original strategic vision getting diluted through endless revision cycles until nobody remembers why they started.
| Perfectionism Says | Action Says |
|---|---|
| "We need to think through all the edge cases first." | "Let's ship to 10% of users and see what breaks." |
| "The stakeholders need to align before we proceed." | "Let's build a prototype and give them something to react to." |
| "We should wait until Q3 when we have more resources." | "What can we ship with what we have right now?" |
| "It's not ready for external review." | "External feedback is how it becomes ready." |
Here's the thing: you will never think of all the edge cases. The ones you miss will only become visible in production anyway. The difference is whether you discover them in week 3 or month 18.
I've watched teams spend six months planning a "perfect" rollout, only to hit issues in the first hour of launch that nobody anticipated. All that planning, and reality still had surprises. The teams that ship early and iterate? They've already solved those problems while the perfectionists are still revising their Gantt charts.
In Life: Make the Call, Then Make It Right
This principle extends way beyond code and product launches.
Career moves. Relationship decisions. Creative projects. The conversation you've been avoiding. The pattern is identical: we wait for certainty, and while we wait, life happens without us.
→ The job offer you're analyzing to death: take it or don't, but decide
→ The conversation you've been rehearsing for weeks: have it imperfectly or live with avoidance
→ The project you've been "thinking about" for years: start today or let it go
The insight that changed everything for me: most decisions are reversible. Most actions can be adjusted. The cost of waiting usually exceeds the cost of being wrong.
We overestimate the permanence of our choices and underestimate our ability to course-correct. The person who makes ten decisions and gets seven right will always outpace the person who makes two perfect decisions.
The "Kill It" Part
Here's where most "just ship it" advice falls short. Shipping isn't just about launching: it's about learning fast enough to know when to stop.

Not every idea deserves to become a company. Some are experiments. Some are learning experiences. Some are just fun distractions that taught you something about what you actually want to build.
The goal isn't to succeed with every idea. It's to:
- Learn quickly whether an idea has legs
- Build the muscle of shipping (it genuinely gets easier)
- Stop investing in things that won't work
- Free up energy for the next experiment
Killing a project that isn't working isn't failure. It's graduating to the next experiment. It's respecting your own time enough to stop pouring it into a hole.
Some of my best professional decisions have been kills. Projects that were technically working but strategically pointless. Features that users tolerated but didn't love. Partnerships that looked good on paper but drained energy in practice.
The kill is part of the process. Honor it.
How to Actually Apply This
1. Set a deadline before you start
The constraint forces decisions. Two weeks for side projects. One week for major decisions. One day for emails that feel "important." The container shapes the work.
2. Build the smallest thing that tests the idea
What's the ONE thing that has to work for this to be worth pursuing? Build only that first. Everything else is decoration until you've validated the core.
3. Launch before you're ready
If you're not slightly embarrassed by v1, you waited too long. Discomfort is data. It means you're actually shipping, not just preparing to ship.
4. Learn from reality, not speculation
Watch what actually happens. Listen to real users, not imaginary ones. Adjust based on evidence. Repeat: or kill it and move on with zero guilt.
Ship It or Kill It in 90 Days
A 32-page playbook that turns this philosophy into a phased system. Three 4-week sprints, each ending with a Ship or Kill checkpoint — so you're never more than a month away from a real decision.
Includes weekly sprint templates, the 7 Traps That Kill Side Projects, a 5-dimension scoring framework, printable 12-week tracker, and mindset reframes for the beliefs that keep you stuck.
Get the PlaybookThe Bottom Line
Perfectionism is procrastination in a blazer. It feels productive. It looks responsible. But it's just fear with better marketing.
Ship it or kill it. Those are your options. The middle ground: endless refinement, perpetual "almost ready," infinite planning: is where ideas go to die slowly.
Make the call. Take the action. Learn from what happens.
The world doesn't reward perfect plans. It rewards people who show up, ship something, and figure out the rest in motion.
Your move.
Ready to start? Grab the 90-day playbook →