🚀 We almost didn’t launch.
Not because the product was impossible.Not because the team wasn’t capable.
Because the scope kept growing… while our capacity didn’t.
A year ago, launching soci.lt felt like chasing a horizon:– People had jobs, studies, life– Capacity was unpredictable– “Just one more feature” kept sneaking in– Timeline kept slipping
And the worst part?Until launch — nothing moves. No users, no feedback, no signal. Just… waiting.
So I did something uncomfortable.
I cut.
Hard.
Users could register… but not delete accounts.You could create data… but not delete it.Some profile fields? Not editable.Logout? Not critical.
If it didn’t block the core flow, it was gone.
The rule became simple:If this can be done the day after launch — it’s not a launch requirement.
That’s when things changed.
Progress became visible.The backlog started shrinking for real.Energy shifted.
But the real challenge wasn’t the backlog — it was discipline.
“Must-have” features kept coming (from everywhere, including my own brain).Each one had to go through the same filter:
Is this truly blocking us from going live?
If not → Day 2.
Another move that helped:We aligned development with business reality.
When it looked like we needed ~3 weeks to finish, and onboarding would also take ~3 weeks — we overlapped them.
Started onboarding before we were fully done.
Risky? Yes.Worth it? Absolutely.
We launched earlier than expected.
And here’s the funny part:
Some of those “critical before launch” features…are still not built today.
Turns out:Doing something manually 1–2 times a yearis cheaper than a week of engineering time.
A lot of projects don’t fail because they’re bad.
They fail because they never cross the line.
Like ships stuck in the harbor, endlessly polished, upgraded, prepared…but never allowed to sail.
What helped us actually launch:
Define a real feature list for launch
Next day — cut it again (ruthlessly)
Map dependencies, estimate, timeline (basics, but done properly)
Protect priorities when chaos hits (because it will)
Align with business timing — not just engineering readiness
And one more, which I learned the hard way:
- Prefer reversible decisions early (features)Be careful with irreversible ones (architecture)
This approach is not universal.
Sometimes you should start fully manual — spreadsheets, forms, emails — and evolve from there.
But if you’re stuck in “almost ready” for months (or years)…you might not need more effort.
You might need less scope.
Harsh truth: Many products die in the shadows of perfection.
Better to launch something imperfect that breathesthan something perfect that never lived.
Top comments (0)