13 Years, 22 Android Apps: What I've Learned About Building Software Solo

I've shipped 22 Android apps. I've watched most of them grow, some of them stagnate, and a few get downloads I never expected. Here's what those years taught me.

---

The Technical Lessons

1. Architecture pays compounding interest

The MVVM + Clean Architecture decision I made 5 years ago still pays dividends on every app I start today. I open a new project and know exactly where the repository goes, how the ViewModel connects to it, what the use case pattern looks like.

Bad early architecture choices compound the other way. I've seen codebases where adding a feature requires touching 8 files in unpredictable places. Every new feature is slower than the last.

The right architecture isn't a constraint — it's leverage.

2. Tests are insurance, not overhead

For years I was inconsistent about testing. Some apps had solid tests, others had none. The ones with tests, I refactor confidently. The ones without, every change is followed by manual testing anxiety.

Now I consider the minimum viable test suite — unit tests for business logic, integration tests for the database, a few UI tests for critical flows — as part of development, not an addition to it.

3. Kotlin saves time that Java would have wasted

Not just because of syntax. Null safety alone has prevented hundreds of production crashes. Extension functions reduced duplication across apps. Coroutines made async code readable.

The language you choose shapes what you spend your mental energy on. Kotlin lets me spend it on the problem, not the boilerplate.

4. Automation earns negative time

Negative time: you spend 4 hours setting up CI. Then every release takes 3 minutes instead of 45. After 10 releases, you've earned back the 4 hours. After 100 releases, you've saved 70 hours.

I have 22 apps. Every automation multiplies by 22. The setup is always worth it.

---

The Mindset Lessons

5. Shipping beats perfection every time

The best code I've never shipped has zero users. An imperfect app with real users is infinitely more valuable than a perfect concept.

I've learned to separate "good enough to ship" from "good enough to be proud of." The bar for shipping is lower than the bar for pride — and that's the right relationship.

6. Users tell you what to build if you listen

My most-requested features across apps were always the ones I didn't predict. The features I was most excited to build often had the least uptake.

Read every review. Not to respond to negativity — to understand what users are trying to do that your app isn't helping with.

7. Small apps can serve large audiences

I have an app with 200,000 downloads that does one thing. One thing, done well, with good search visibility and a clear value proposition. You don't need complex apps to reach a large audience.

8. QA experience made me a better developer

Thirteen years of finding bugs changed how I write code. I think about error cases before happy paths. I consider what happens when the network drops. I write validation that fails gracefully rather than crashing.

The developers who produce the most stable code are often the ones who've spent time on the other side — seeing what breaks, and how.

---

The Business Lessons

9. Discoverability is the problem, not quality

Most good apps fail because nobody finds them. Most successful apps are adequate because people found them. Quality keeps users; discoverability brings them.

ASO (App Store Optimization) isn't glamorous, but it's more impactful than the next feature for most apps.

10. Monetization model matters more than price

I've had apps with free tiers that converted well and others that didn't. The difference was never the price — it was whether the free tier showed the value clearly enough that users wanted to upgrade.

The paywall is the product experience. Design it with the same care as the feature.

11. Maintenance is underestimated at every step

Keeping 22 apps current with Android API changes, dependency updates, Play Store policy changes, and OS releases is a full-time job that isn't writing new features. I didn't understand this until I had more than 5 apps.

Plan for maintenance time. Build automation that makes it cheaper. Or keep fewer apps.

---

What I'd Tell Myself 10 Years Ago

Start with architecture. The time you "save" by skipping it, you pay back 10x later.

Automate the boring parts immediately. Every manual step you repeat is time you won't get back.

Ship sooner. Every month a product isn't live is a month without user feedback.

Track what users do, not what they say. Analytics over surveys. Behavior over opinion.

Focus on one app until it's good. The urge to start the next app before the current one is mature is a trap.

Your QA background is not a liability. The instinct to think about failure modes is rare and valuable.

---

What's Still True After All Of It

Building software alone is hard. It requires breadth (design, development, testing, release, marketing, support) where teams have specialists. It requires discipline when there's no external accountability. It requires perspective when you're too close to see the problems.

And it's worth it. You build exactly what you decide to build. The feedback loop is direct. The ownership is complete. The alignment between what you make and what you care about is perfect.

That's not available in most other contexts.

Build something. Ship it. Learn. Repeat.

---

Takeaways

• Architecture and automation are investments with compounding returns — make them early
• QA thinking (failure modes, edge cases, validation) makes better developers
• Discoverability is a bigger bottleneck than quality for most apps
• The maintenance burden of multiple apps is underestimated — automate or focus
• Ship sooner, learn from real users, iterate — this beats extended private development every time