Filmflux
Cross-platform movie discovery app with 10k monthly active users across web, iOS, and Android.
Overview
Filmflux is a movie discovery platform I built and ship as the sole developer. It runs on web, iOS, and Android from a single Next.js codebase via Capacitor. 10,000+ monthly active users, 1,000+ commits over eight months, three revenue streams (subscriptions, ads, sponsored promotions), and a personalised home feed that adapts to each user without configuration.
The challenge
Finding what to watch shouldn't be harder than watching it. Existing platforms bury discovery behind algorithms optimised for engagement, not taste. Trailers live on YouTube, ratings on IMDb, streaming availability on JustWatch, and reviews are scattered across blogs. There was no single place to browse, discover, and decide.
I wanted to build that place, and ship it on all three platforms (web, iOS, Android) at startup speed without a team.
The reframe
I assumed Filmflux would be a content problem. Get the data, design the screens, ship.
It turned out to be a performance problem and a search problem. Both took longer than the UI. The features people see (the home feed, the trending hub, the article pages) are the surface. What makes Filmflux feel different is what's underneath: a three-layer cache that resolves most views before a database call, a hybrid keyword-and-semantic search that understands intent rather than exact titles, and a single codebase that ships to three platforms without three engineering tracks.
The reframe wasn't a single moment. It was a long realisation that the screens were the easy part.
Key decisions
Capacitor over native: one codebase, three platforms
Building three separate apps as a sole developer wasn't an option. Capacitor wraps a Next.js build into iOS and Android binaries with native shells. Tradeoff: I gave up some platform-native ergonomics (Material patterns on Android, iOS large titles, certain native gestures). Win: I shipped to all three platforms with a team of one. Code I wrote on Monday for the web was on a user's phone by Tuesday.
Hybrid search: titles weren’t the bottleneck
Analytics showed users searching for descriptions and themes, not just titles. The first version had me typing exact titles to find anything. I rebuilt search around hybrid keyword-and-semantic matching, so “gritty Nigerian crime drama” returns the same result as “King of Boys”. Tradeoff: more infrastructure (vector embeddings, hybrid scoring). Win: search stopped being the most-complained-about feature.
Personalisation that doesn’t ask
Most apps make you pick your favourite genres on first run. Filmflux doesn't. A genre affinity system tracks what users browse, rate, and add to lists, then reweights the home feed in the background. The home page adapts without anyone configuring anything. Tradeoff: cold start is generic. Win: every interaction makes the next visit better.
Three revenue streams, independently toggled
Stripe subscriptions for ad-free Pro, AdMob mobile ads with frequency caps, and sponsored featured promotions on the homepage. Each stream has an environment-variable kill switch so I can turn one off if it hurts the experience. Tradeoff: more code paths to maintain. Win: I can experiment with monetisation without breaking the product.
Impact
10,000+ monthly active users across web, iOS, and Android.
1,000+ commits over eight months of continuous development.
Three revenue streams: subscriptions, ads, and sponsored promotions.
Personalised home feed adapting to each user without configuration.
Single codebase shipping to three platforms via Capacitor.
YouTube API quota burn cut 100x via a more efficient call pattern (covered in the caching writeup).
Reflection
Filmflux taught me that the screens are the easy part. The decisions I'm proudest of don't appear in any mockup: the cache layer that makes the app feel instant, the search system that understands intent, the single-codebase strategy that turned three platforms into one engineering job.
If I were starting Filmflux today, I'd do the same things in a different order: design the architecture first, then the screens. The screens follow from the call pattern, not the other way around.