Before you write code: plan, ship an MVP, don't chase perfect

The temptation, when you're excited about an idea, is to open the editor and start typing. But the decisions that decide whether a project succeeds are almost all made before the first commit. Here's the order I try to follow.

Plan before you build

Planning isn't a Gantt chart. It's answering three questions honestly: what problem am I solving, who has it, and — most importantly — what am I not going to do. A clear list of non-goals is worth more than a long list of features. Scope is the thing that quietly kills projects, and it's cheapest to cut on paper.

Choose technology you can live with

A stack is a long-term commitment, not a fashion choice. I pick technology I can operate, debug, and still understand in a year — usually the boring, well-trodden option. The exciting framework that saves you a week now can cost you months when it fights you in production.

Ship an MVP, not a monument

Your first launch should not be perfect. It should be real. An MVP exists to answer one question — does anyone want this? — with the least code possible. Chasing a flawless launch is just polishing assumptions you haven't tested yet. Ship the smallest thing that delivers the core value, and let reality correct you.

Test in the real world before you "launch"

This matters most for your own projects, where there's no client forcing the issue. Put the thing in front of real use — even a handful of real users — before you call it launched. Planning tells you what should happen; the real world tells you what does. The gap between those two is where every interesting lesson lives.