Most solo developers spend 90% of their time writing code and 10% on everything else. After a few years of building indie products — some failures, a couple that found traction — I've tried to document the framework I wish I'd had earlier.

The framework has four phases: clarify, build, grow, monetize. None of it is novel. The value is in applying it in order, because most failures happen when you skip the first phase and go straight to the second.

Clarify first. Before writing code: who exactly are you solving a problem for, and what problem are you solving? The answer needs to be specific enough to function as a filter for future decisions. "Productivity software for remote workers" is not an answer. "A tool that helps freelance developers track billable time without switching contexts" is closer.

Once you have that, validate the problem using a simple heuristic: Frequency × Intensity × Scale. A problem that's frequent, painful, and affects many people is real. A problem that scores high on only one dimension is usually not worth building around. Also: what users say they want and what they actually do are different. Design around behavior, not stated preferences.

Competitive research belongs here too. The 1-star reviews on app stores and complaint threads in relevant communities are a map of unmet needs. That's your opportunity space.

Build less, ship sooner. The right unit to build is the minimum thing that lets a real user accomplish the core task. Every feature beyond that is a liability until it's validated. The goal is to shorten the loop: build → ship → real user feedback → iterate. Most indie products fail because this loop is too slow, not because the underlying product is bad.

Grow through content and community. Paid acquisition before you've validated the model is expensive and usually misleading. Content that addresses real problems in your domain compounds over time. Community participation — being genuinely useful in places where your target users already are — builds trust that converts at higher rates than ads. The practical version: write about problems you've actually solved. Show up consistently. Don't make every post about your product.

Charge before you feel ready. Delayed monetization is usually a form of avoiding the most important feedback signal. If nobody pays, that tells you something essential — and you want to learn it as early as possible, not after six months of building. Think through the unit economics: LTV needs to exceed CAC, or you don't have a business yet. Retention matters more than acquisition. Track the metric that best reflects whether users are getting value, and let that drive decisions.

The short version: define who you're solving for, validate before building, ship in small increments, and charge for your product sooner than feels comfortable. The hard part isn't technical — it's the discipline to do the unsexy work before the fun work.

A note on the sequencing: most indie product failures I've seen — including my own — share the same pattern. The builder had a problem they wanted to solve, skipped the validation phase, built for months, shipped, and discovered either that nobody wanted it or that the people who wanted it wouldn't pay. The fix is not to become a business person instead of a developer. It's to do a small amount of structured thinking upfront and revisit it regularly as you learn. The code is the easy part.

One resource I'd point to: Rob Fitzpatrick's "The Mom Test" for the validation phase. The core idea — ask about problems, not solutions, and watch behavior rather than taking stated preferences at face value — has saved me significant amounts of time building things that turned out not to matter.