Start easy, I said to myself for the n'th time
"Start simple."
I've told myself that sentence so many times it should be printed on my coffee mug. Yet somehow, every new project still begins with a mental architecture diagram that looks suspiciously like a five-year roadmap.
And yes, it makes sense. Yes, it's visionary. Yes, it would be beautiful… in two years.
But not for a PoC. Not for an MVP. Definitely not for an early access product.
The overengineering trap
My pattern is simple and painfully familiar:
I start with a basic idea. Then I think: "But what if this scales?" Then: "We'll need this feature anyway." Then: "Let's just do it properly from day one."
Fast forward a few months and I'm juggling features I never wanted in the first place, fixing edge cases for scenarios that don't exist yet, and debugging things that should never have been written before the product even had users.
Somewhere along the way, the basics stopped being basic.
Vision is not the problem
Having a long-term vision is not a flaw. It's usually a strength.
I naturally think in one-year and two-year horizons. I like shaping what a product could become, how it should feel when it's mature, and what problems it should eventually solve properly.
The problem starts when you are:
- the CEO
- the product owner
- the project manager
- the developer
- the tester
All at once.
You're arguing with yourself, approving your own ideas, and convincing yourself that "future-me will thank present-me." Spoiler: future-me is usually just tired.
Write it down. Then obey it.
What finally started working for me was brutally boring:
- Write things down.
- Define clear milestones.
- Reduce scope aggressively.
- Stick to the plan like your life depends on it.
Once it's on paper, it's no longer a thought floating in your head. It's a contract. And when that shiny new idea appears (it always does), you can look at the document and say: "Not now."
And yes, swallowing the fact that a feature won't ship in v1 hurts. But rewriting half a codebase hurts more.
Lean plans are not weak plans
As I reduced scope, something unexpected happened:
The plan became lean. Tasks became smaller. Milestones became achievable. Progress became visible.
Suddenly things felt… manageable. Feasible. Real.
Not perfect. Not visionary. But shippable.
Let people hate on it (politely)
If you have people around you, use them.
Let them question your ideas. Let them tell you it's too complex. Let them hate a feature you love.
That feedback loop is gold. It forces you back to your docs, back to your vision, and helps you reshape what actually matters. You stop building what you think people will need in two years and start shipping what they need now.
Don't rebranch from "almost done"
One of the worst feelings is rebranching from a product that's basically ready because the feedback is:
"It's too much."
"It's too complex."
"This feels like version 3, not version 1."
At that point, you're not iterating — you're undoing.
Start simple. Add later.
Simple products get less hate. Small changes get better feedback. Basics that work beat complex systems that almost do.
The advanced version of your product will come. It just shouldn't come first.
So yes — once again — start easy. This time, I'm actually trying to listen.