The standard advice for anyone building an app is to validate the idea first. Talk to users, research the market, prove demand, then build. It is good advice. I am not following it right now, and that is on purpose.
I am in a different phase. Right now, I am not trying to find a product that a market is desperate for. I am trying to get good enough at building software that, when I do find that product, I can actually build it well. Those are two different goals, and they call for two different approaches.
What I actually do instead
My process for picking what to build is not a five-step validation framework. It is closer to this: I look for a problem I find interesting, that I would personally enjoy solving, and that is the right size to finish. Then I build it.
That is it. No user interviews, no landing-page smoke tests, no spreadsheet of competitor reviews. I am not going to dress it up as something more rigorous than it is. For where I am, that is the right call, and I would rather explain why than pretend I run a process I do not.
The phase I am actually in
I am a newer developer building in public as softDev23. I have shipped a few iOS apps, and I am working toward more across iOS, web, and digital products.
The honest bottleneck for me right now is not market fit. It is a skill. I am still learning how to build well: how to structure an app so it does not fall apart, how to ship the whole pipeline from idea to App Store, how to make something feel finished.
Validation does not help with any of that. You cannot validate your way into being a better builder. So I am optimizing for the thing that is actually holding me back, which is reps.
The build-ten-apps approach
The framing I keep coming back to is one I picked up from CodeWithChris: build ten apps, and by the end, you will be ready to build real products for people.
The number is not magic. The point is that you get good by finishing things, not by planning them. Each app teaches you something the last one did not: a framework you had not used, a bug you had never hit, a corner of the App Store process you had not touched. Ten times through that loop, and you are a genuinely different developer than when you started.
If I stopped to run heavy validation on every one of those, I would build fewer of them, learn slower, and probably quit out of boredom before I got good. Building things I enjoy is what keeps me in the chair long enough to actually improve.
What this looks like in practice
Three apps so far, each a different lesson. Habitual is a gamified habit tracker and my most complete app to date.
My water tracking app, called Think Drink, was deliberately small, a way to get through the entire App Store pipeline once without much on the line.
Mana, my gamified focus app, is the most ambitious of the three and the one stretching me the most right now. None of them started with a validation study. They started with “this would be interesting to build, and I will learn something by finishing it.”
When validation will absolutely matter
I am not arguing that validation is overrated. It is essential, just later, for a different job.
There is a phase after this one, where you stop building to learn and start building to solve real problems for real users, including the boring, unglamorous problems people actually pay to make go away. That is where validation earns its keep, because then you are betting months of finite time that a specific market wants a specific thing. I am not there yet.
When I am, the App Store research and the honest demand-testing become non-negotiable. I wrote up the method I use for that in my post on how to find app ideas worth building. Skipping validation to learn faster is reasonable. Skipping it when you are building a sustainable product is just gambling.
The honest caveat
This is a phase, not a forever philosophy, and it has a real trade-off. Building what I enjoy means some of what I ship will not find an audience, and that is fine, because finding an audience is not the current goal. But I would be lying if I called “build what you love” a business strategy. It is a learning strategy.
The mistake would be staying here too long. Building app number twenty for the joy of it while still avoiding the harder work of validating something people will pay for would not be craft. It would be procrastination with a nicer story.
The takeaway
Match your process to your phase. If you are learning, the win is finishing things you find interesting, as many as you can, and validation can wait. If you are building for a market, validate before you commit months to it.
Right now I am building to get good. The validation phase is coming, and I will know I have reached it when the question stops being “what would be fun to build” and becomes “what is worth solving for someone other than me.” For how I am structuring this learning phase, see Build 10 Apps First.
