← All notes
2025-02-06 / Indie Dev · Reflections

Year Three of Indie Dev — What I Learned to Say No To

Not every good idea deserves to start now.

2 min read · LUMAREN

The scarcest resource in indie development isn't ideas — it's sustained focus. Learning what NOT to do matters more than learning what to do.

Stop building for everyone

When a product tries to solve everyone's problem, no one truly remembers it. Now I'd rather start from a tiny audience and seriously solve one specific pain.

Stop chasing the "perfect launch"

I used to think a product needed complete features, polished interactions and full docs before shipping. Now I accept MVP for what it is — if the core loop runs, real users use it, and feedback comes in, that already beats a perfect unreleased product. Survive first, look good later.

Stop treating your stack as a talisman

Rust, K8s, writing compilers… cool, but users don't care. This year I put more energy into understanding user scenarios, refining copy, and designing pricing. Tech is just a means — pick the familiar, iterate fast.

Stop building in silence

Early on I feared copycats and harsh feedback, so I hoarded the big reveal. Now: ask on social media at the idea stage, put up a landing page to collect emails, talk to 3-5 seed users. Honest rejection beats fake encouragement.

Stop measuring only revenue

For two years I fixated on MRR, DAU and conversion anxiety. Now I ask: am I still enjoying writing code? Do users genuinely say "this works"? Am I accumulating reusable assets (component libraries, release processes, SEO experience, trust)? Those compound.

Stop rejecting "uncool" business

Tools, outsourcing, building sites for people, writing docs, selling templates… I used to think these weren't "productized" enough and felt beneath me. Now I know: cash flow buys the freedom to keep doing what I love. Dignity doesn't pay rent — cash flow does.


The keyword for year three is convergence:

  • Feature convergence: only the core 20% that 80% of users touch
  • Audience convergence: only serve people who'll pay for a specific problem
  • Pace convergence: reject fake demands, protect deep-work blocks
  • Expectation convergence: accept high odds of failure; only bet what you can lose

I no longer want to be a "successful indie developer". I want to be someone who keeps making things. That's probably the posture that goes the distance.