There is a piece of advice for new developers that sounds almost too simple to be useful: build ten apps. I picked it up from CodeWithChris, and the longer I build, the more right it feels. The idea is that you do not get good by studying or planning. You get good by finishing a lot of real things. Ten of them, roughly, and by the end, you are ready to build products people actually rely on.
I am somewhere in the middle of my own ten right now, building in public as softDev23. Here is why the approach works and how I am trying to do it without wasting the reps.
Why volume beats planning when you are learning
When you are new, the instinct is to plan the perfect app and get everything right before you ship. That instinct is backward.
The lessons that make you better are not in the planning. They are in the parts you cannot see until you are deep in the build: the architecture decision that boxes you in, the bug that only shows up on a real device, the App Store rejection over something you did not know was a rule. You only hit those by finishing.
A planned app teaches you almost nothing. A shipped app teaches you everything you did wrong, which is exactly the curriculum you need.
Volume forces those lessons to repeat until they stick. Build one app, and you might get lucky. Build several, and the patterns become muscle memory.
“Ten apps” does not mean ten throwaways
The number is a target, not a literal quota, and it does not mean shipping ten copies of the same to-do list.
The point is range. Each app should stretch you somewhere the last one did not. A new framework. A feature you have never implemented. A different kind of data, a different kind of user, a harder design problem. If app number five is just as easy for you as app number two, you are repeating a grade instead of moving up one.
The way I think about it: every app should have at least one thing in it that scares me a little. That is the part doing the teaching.
How to pick the ten so they compound
Left unstructured, “build ten apps” can turn into ten random projects that each teach the same beginner lesson. A little intent fixes that.
I try to vary the challenge on purpose. One app is deliberately small, just to get through the entire pipeline from empty project to live on the App Store without much on the line. One more ambitious, the kind that forces real architecture. Something with a backend or a web piece. Something heavy on design. The goal is that by the end, there are very few parts of building and shipping software I have not touched at least once.
Finishing is the whole point
This is the part most people skip, and it is the part that matters most.
An app you abandon at sixty percent teaches you the easy sixty percent, which you mostly already knew. The hard, valuable lessons live in the last stretch: polishing, fixing the unglamorous bugs, writing the App Store description, handling the edge cases, and actually shipping.
If you keep starting new projects and never finishing, you are not building ten apps. You are building the first half of one app ten times.
So I treat finishing as non-negotiable, even when a project stops being exciting. Especially then. The willingness to push something boring across the line is itself one of the skills you are trying to build.
The traps to avoid
A few ways this approach quietly fails:
Tutorial hell. Following along with courses forever feels like progress, but it is not the same as building your own thing. The ten have to be yours.
Comfort cloning. Building the same easy app over and over because it feels good to finish. Finishing matters, but only if the thing was hard enough to teach you something.
Polishing one app forever. The opposite trap. Endlessly refining app number one instead of starting app number two. At some point, the lesson is “ship it and move on.”
What you are actually building
The apps are the visible output. The real output is you.
After enough reps, you build faster, you make better architecture calls earlier, you stop fearing parts of the process that used to intimidate you, and you develop the judgment to know what is worth doing and what is not. You also end up with a portfolio that proves you can finish, which matters more than any single idea.
That judgment is the thing that lets you eventually build for a market instead of just for practice.
When you graduate
The build-ten phase is not forever. It ends when the bottleneck stops being your skill and starts being your aim.
At that point, the question changes from “what would teach me something” to “what is worth solving for real users,” and that is where validating an app idea becomes essential instead of optional. I am not there yet, and I am deliberately not rushing it. I would rather earn the skill first and validate second than validate a product I am not yet good enough to build well.
The takeaway
If you are early, stop planning the perfect app and go build a real one, then another. Make each one stretch you, finish every one even when it gets boring, and keep the projects yours. Do that ten times, and you will be a different developer.
I am still working through mine. When I come out the other side, the next job is figuring out what is actually worth building for other people, which is a different phase and a different post.
