In the last two posts, we covered the foundational stuff.
Part 1 was about getting your company registered, documents, bank accounts, payment gateways. The boring-but-necessary foundation.
Part 2 was about the technical building blocks — OTP providers, Google login, the common infrastructure every app needs before you write a single line of product code.
Now comes the question nobody really talks about: what do you actually build?
A quick backstory
Last year, I built a web app where parents could upload their child’s photo and get it printed into a personalized storybook. We partnered with printing vendors, handled the shipping, and ran Meta ads. The business was working.
It’s still live — we just aren’t actively pushing it right now. I stepped back for five or six months, and somewhere in that break, my attention drifted elsewhere.
After that pause, I was back to a blank screen, asking myself what to build next.
This time I wanted something different
I didn’t want to build another web app.
I also knew I had a clear gap: I don’t know how to build Android apps. Don’t know Kotlin. Never seriously explored that space.
But here’s what I did notice: in India, the opportunity in Android apps is massive.
UPI, autopay, daily utility tools, habit apps — people are on their phones constantly, and a lot of apps filling that space are either ugly, bloated, or barely maintained. There’s real room to build something cleaner and simpler.
So I decided to explore.
How I actually went about it
I spent time going through the Play Store — not randomly, but with a specific lens.
I was looking for apps that:
Had decent downloads
Weren’t technically complex
Had obvious gaps in UX or features
Once I found candidates, I did something I’d recommend to anyone: reverse engineering.
I used the app. I mapped its core logic. I noted what it was actually doing under the hood — what data it needed, what the key user flows were, where the value really sat.
And then I started prompting.
Seven apps in fifteen days
I’ve shipped more than 6–7 Android apps in the last 15 days.
I still don’t know Kotlin.
What I do know is how to break down an app into its logic, describe that clearly, and use AI to write the actual code. This isn’t magic. It’s just a workflow most people haven’t tried seriously yet.
Find an app that works. Understand why it works. Rebuild it better. Repeat.
The part I’m not proud of
Here’s where I’ll be honest.
I’m good at building. I know Meta ads reasonably well — I’ve run campaigns that worked before. I have the tools, the setup, and the experience to go test these apps in the market right now.
But I keep procrastinating on that part.
Every day I tell myself I’ll stop building and start running ads — and every day I find one more thing to tweak, one more app idea to explore, one more thing to ship.
That pattern is familiar. It’s comfortable. And it’s exactly how products die quietly, never actually reaching anyone.
So I’m making a decision: stop building. Start testing.
I’m going to pick one of these apps, put some real money behind Meta ads, and find out whether these vibe-coded apps can actually get users and retain them.
What’s next
I’ll keep you updated once the ads are running — what I’m testing, what the numbers look like, and whether any of this holds up in the real world.
Because building is the easy part.
Most of us already know that.
Distribution is where things actually get decided.
If you missed the earlier posts in this series: