I started PodLP in 2020 with no clue it would lead me give talks with 20,000+ aspiring Indian developers and take calls from a New Zealand campground with Bangladesh’s largest telecom company. It’s now 2026, I just launched PodLP for Android, and I still don’t know where it all ends.

Like many, the COVID-19 pandemic gave me sudden free time. Curious to try a “digital detox,” I wanted a flip phone for camping trips. However, the phones then on the market (like the Go Flip 3) didn’t have a podcast app, so I built one.

Fast forward to 2026, I’ve built (and rebuilt) PodLP for three very different platforms: KaiOS, Cloud Phone, and Android. It’s been downloaded over 10 million times across 175+ countries. For many, it was their introduction to podcasts. While its growth has ebbed and flowed, PodLP has proved to be both a successful side hustle and technical playground.

These lessons might not apply to starting a one-person billion-dollar company, but they are relevant for bootstrapping an impactful consumer-facing application without quitting your day job.

1. Leave the crowds #

Podcast apps are a popular genre for burgeoning programmers; building one requires learning networking, parsing, UX, data storage, and media playback. While it’s a valid way to grow as an engineer, most podcast apps never leave GitHub. If you do publish on Google Play or the Apple App Store, yours is often lost in a sea of apps.

Skip the crowds and launch somewhere you can get organic installs. When I launched PodLP on the JioStore for the JioPhone in India, I saw 100,000+ installs on the first day. Within days there were dozens of YouTube videos featuring PodLP. All with $0 in ad spend.

The challenge is picking the right app store when there are so many. For Android there’s F-Droid (if your app is open source), Huawei AppGallery in China, Tencent Appstore, and Palm Store from Transsion. For browser extensions there’s the Naver Whale Store in Korea and Opera add-ons. For TVs and set-top boxes (STBs) there’s the Jio Developer Program, LG’s Content Store for webOS, and the Foxxum App Store. For games there’s JioGames. For web apps there’s KaiOS and Cloud Phone. Even the Yoto kids speaker has an API! This list isn’t remotely exhaustive.

The lessons you’ll learn measuring engagement, debugging crashes, localizing for diverse markets, generating marketing material, and responding to real user feedback are irreplaceable.

2. The riches are (still) in the niches #

Ask AI to write a KaiOS app, then try to run it on a TCL Flip 4 5G. There’s a good chance it will hallucinate non-existent APIs, and it won’t natively handle directional pad or soft-key navigation unless prompted. You still can’t effectively “vibe code” a decent flip phone app.

In the process of building apps for niche platforms, you’ll learn that documentation lies. Maybe the docs are out of date. Maybe that feature was never built. Maybe its behind an undocumented permission or feature flag. Maybe it only works on one model. You might have to reverse engineer hidden APIs and while you’re looking, stumble upon an “undocumented API” that accidentally grants you root shell access from the browser. These things happen.

This mess is infuriating, but it is exactly why AI has little hope of displacing human labor here. The real world is messy. It requires forging relationships, compliance with arcane rules, and access to hard-to-obtain physical devices.

Despite selling ~150M units, good luck buying a JioPhone in the United States. Yet somehow I built a JioPhone collection including the JioPhone 1, 2 & Next thanks to serendipity, relationships, and perseverance. One from a r/KaiOS Discord member, one via an eBay alert, and one shipped on trust from a translator in India.

Knowing this gives me hope. The future remains full of niches that AI agents can’t or won’t touch because the opportunities are too small, too fragmented, too messy, and too physical.

3. Stick with it #

The full picture requires a focus to ignore “the next thing,” a time horizon in years not minutes, and a psychological “context window” well beyond one million tokens.

It’s easy to get shiny object syndrome. Trends come and go. One minute everyone is “cloud native”, then suddenly everyone is moving back on-prem. IoT, Big Data, and Edge Computing all had their 15 minutes. Now the talk of the Gas Town is AI. Surprisingly few people stick with someone long enough to see it through before getting caught in the next hype cycle.

Because of PodLP and my blog (KaiOS.dev), I was contacted to build Vipaso, a Bluetooth payment app, and support Developer Relations for CloudMosa. I recognize it sounds egotistical, but in some ways, these opportunities were created for me. Had I (or someone like me) not turned up in a search result, these opportunities likely would’ve never appeared on a job board.

You can’t know where it will go unless you stick with it.

4. The power of “Wow!” #

It has never been easier to bake the same cookies everyone else is baking. Using AI, you can generated a polished set of Tailwind landing pages in seconds, but with results that look nearly identical to everyone else.

Not every application needs a custom component library, but don’t overlook the power of “wow!” People remember something distinct, something they never thought was possible. As one Reddit user commented, I’m “surprised you got the native menu row to work on the Kyocera… impressive, it actually feels almost native.”

Spend the extra minute: prompt something novel into existence, preferably not in AI purple.

5. Technical lesson: memory matters #

Now for some nerd talk. Most of what I’ve built is I/O bound. For flip phones, a major hurdle is out-of-memory (OOM) errors. I soon discovered how big podcasts get. Take Blue Wire’s Pack-a-Day Podcast as an example.

• The RSS feed on Simplecast is 12.97MB of XML!
• The artwork is a 3000x3000 PNG totalling 251KB
• There are 4,275+ episodes averaging ~56MB

Now consider the build.prop from my LG Wine 2 (2020), a flip phone with 1GB RAM running Android Go.

[dalvik.vm.heapgrowthlimit]: [128m]
[dalvik.vm.heapsize]: [36m]

With a 36MB heap limit, every byte counts. I probably should have ignored the LG Wine 2, but I wanted PodLP to work well on low-end phones. I implemented:

• Chunking & streaming. I moved away from JSON.parse or responseXML, which loads the whole document into memory. Instead, I used stream parsing and tools like Kotlin Flows. For audio I used Range requests, chunking, or streaming (based on what’s available).
• Don’t be transparent. Images are collections of pixels. Android’s default ARGB_8888 format uses 32 bits per pixel, but, flip phones don’t exactly have Retina displays. Switching to RGB_565 uses only 16 bits, doubling the number of images I can display.
• Take control. On native platforms like Android, I switched from the default to OkHttpDataSource to share the same connect and thread pools, add interceptors for Brotli and GZIP compression, support HTTP/2 multiplexing, and have more consistent buffer size control.

In the end, getting PodLP to work on low-end phones like the LG Wine 2 meant it ran faster on newer devices with better hardware like the Sonim XP3+ and Kyocera DuraXV.

6. It only gets easier #

When I started PodLP, podcast APIs were paid. I built my own directory, and now there’s a free and open source Podcast Index.

When I started, low-cost distributed databases didn’t exist. I made my own SQLite on Elastic File Service (EFS) that supported millions of users for pennies per month. Now services like Amazon Aurora Serverless and Cloudflare D1 are easy to use and scale to zero.

My first Cloud Phone was a Nokia 110 4G with a QQVGA (128x160) screen using a 4G SIM card from Red Pocket. I would debug remotely using tools like RemoteJS. Now there’s a Cloud Phone Simulator that runs a full developer console in your browser.

In 2024, I wrote the first–and only–guide to publishing on the JioStore for JioPhone. After having nearly a dozen builds rejected were the complete set of rules and requirements shared with me. Things like using a four digit version code, supporting IPv6-only networks (without NAT64), and displaying an exit confirmation dialog.

As time moves on, eventually someone else will share your problem, and eventually someone else fix it. Each problem could itself become a new product or pivot. Either way, you can make it easier for someone else, or someone else can make it easier for you. But it only gets easier.

Closing thoughts #

I find writing creates clarity. This article scratches the surface of a journey that’s taken me–and continues to take me–around the world. It’s taught me the immense value of the small, the fragmented, and the persistent.