I used to spend more time planning projects than actually building them.
I'd think about the tech stack.
The database.
Authentication.
Folder structure.
CI/CD.
Docker.
Kubernetes.
Monitoring.
By the time I finished planning...
I was already tired.
The project never even started.
Then I tried something different
One weekend I gave myself a simple rule.
Build something that works in one day.
No fancy architecture.
No microservices.
No "future-proof" decisions.
Just make it work.
That project was ugly.
The UI wasn't great.
The code wasn't perfect.
But people actually used it.
Shipping teaches things tutorials don't
When real users start clicking your app, you notice problems that never appear in toy projects.
Your loading state is confusing.
Your error messages make no sense.
Someone tries something you never expected.
And suddenly you're solving real problems instead of imaginary ones.
Perfection is expensive
I've realized perfection has a hidden cost.
Every extra day polishing an unreleased project is another day without feedback.
You don't know if people even want your idea.
You're optimizing for users that don't exist yet.
My new workflow
Now I ask myself only three questions before starting:
- Does it solve one problem?
- Can I build it this weekend?
- Can someone use it on Monday?
If the answer is yes...
I start coding.
Everything else can wait.
Funny enough...
The projects I spent months planning never launched.
The projects I built in a weekend are the ones still online today.
Not because they're better.
Because they actually exist.
Final thoughts
Your first version isn't supposed to impress people.
It's supposed to teach you something.
You can always improve software that exists.
You can't improve software that's still inside your notebook.
Top comments (0)