The Nice-to-Haves Are Killing Your Launch

Tuesday, 10 February 2026

That voice that says “just one more feature,” “just this refactor,” “just this optimization.” It never stops. And if you let it, it swallows the entire project.

I caught myself doing exactly this with Reellette.

The perfectionist engineer

I was building the RAG pipeline for the recommendation engine. An important component, yes, but one that didn’t need to be perfect on day one. Except the engineer in my head disagreed.

My inner engineer: “We need daily sync for all titles. If a title changes, the vector store has to update immediately.”

My inner PM (after wasting 6 hours): “It’s a movie title, not a stock price. A weekly GitHub workflow handles this.”

Six hours. Six hours trying to solve a problem that, in practice, didn’t exist. No user would notice the difference between a daily and a weekly update. But there I was, optimizing something nobody asked for.

The problem of not having a PM

When you don’t have a product manager, you need to play one ruthlessly. Someone who looks at that shiny feature you’re planning and asks: “Does this need to exist for us to launch?” If the answer is no, cut it.

Otherwise, you end up with:

  • Beautiful architecture
  • Everything in real time
  • 0 users
  • An app that never ships

And the worst part is you can feel productive the entire time. You’re coding, solving complex problems, learning new things. But none of it is getting you closer to launch. It’s illusory productivity.

The rule I use now

If it doesn’t directly unblock the launch, it’s out of scope. Simple as that.

It sounds obvious, but when you’re deep in the code, it’s very easy to convince yourself that a “quick” refactor is essential. It’s not. The imperfect product that exists is infinitely better than the perfect product that never ships. Launch first, improve later.

Open Source Is a Cheat Code for Juniors »