Published
Start from the problem, not the stack
How I choose what to build — and what I refuse to invent.
Most builds fail before the first deploy. They start with a stack, a template, or a feature list — and only later look for someone who needs them.
I start with a problem that already has owners: a clinic that loses clients between sessions, a firm that cannot see tax cases, a school that runs on paper and chat. If I cannot name the owner and the cost of the gap, I do not open a repo.
NORA exists for that sequence: find the market problem, design the product, grow it until it can stand. CheckOn, Panah, Rooznegar, and the clinic sites are not a portfolio of technologies. They are answers that people open every day.
The stack comes after. Next.js, Postgres, and the rest are tools. The decision is what not to build.
When the work gets busy, I ask one question: does this feature defend the original decision, or only make the deck look fuller? If it cannot name the decision, it is not ready to ship.