This is a guest post from Deepak Chennakkadan, founder of Pollzy, a solo developer who launched Pollzy on iOS and Android.
…
I built and launched Pollzy on iOS and Android as a solo developer, despite having never built a mobile app before. I also regularly attend Expo’s Seattle meetup so I’ve shared my work with the team in person and they asked if I would put a little blog together so here we go!
On August 26, 2026, I launched Pollzy, a social platform built around opinions, on both iOS and Android. The app has personalized feeds, messaging, push notifications, moderation, subscriptions, advertising, and many of the systems you'd expect from a social platform.
Behind the engineering team? Just me.
I had spent years building software at Microsoft and Turn 10 Studios, working on the Forza franchise. But building my own product was an entirely different experience. For one, I had never built a mobile app before. I also wanted to do something I'd never done professionally: own every single part of a product, from the initial idea and design to engineering, infrastructure, monetization, and running the business itself.
So on July 15, 2025, I started building Pollzy. A little over a year later, it was live on both app stores (I obviously could have launched.
Building social media around participation
The idea behind Pollzy came from something I'd been noticing about social media. A lot of social media has become about consuming content rather than interacting with people. Most of the time, we're just scrolling, watching, and occasionally liking something.
Polls always stood out to me as an interesting exception. Answering a poll takes almost no effort. You're presented with a choice, you make it, and you're immediately curious about what everyone else thinks. I wondered what would happen if that interaction became the foundation of an entire social network. That became Pollzy.
The core experience is simple: swipe through polls, vote, see how everyone else voted, and discover people who share your opinions. I also wanted to bring elements of gamification into the experience. Pollzy includes different ways to participate, such as classic polls, quizzes, and head-to-head Duels. Features like Vibe Check let users discover how closely their choices align with other people. I wanted voting to take just a few seconds, but still give people a reason to come back.
Why I chose Expo
Before starting Pollzy, I researched different approaches to cross-platform mobile development. I knew I wanted to launch on both iOS and Android, but building and maintaining two separate native applications didn't make sense for a solo developer. Expo and React Native seemed like the obvious choice.
There was also a practical consideration: I didn't own a Mac when I started developing Pollzy. Expo Build made it possible to create iOS builds in the cloud without needing a local macOS build environment. That significantly lowered the barrier to getting started.
I started with Expo Go, which was great for quickly iterating on the core interactions without worrying about native builds. Once I started integrating dependencies that required native code, I switched to Expo development builds. That let me keep the React Native development workflow I'd gotten used to while testing the native modules the production app depended on. These eventually included subscriptions, advertising, identity verification, crash reporting, and tracking-permission flows.
I kept an iPhone and Android device around throughout development so I could test changes on both platforms. Even with a shared codebase, there were plenty of differences to account for, particularly around navigation and UI scaling on Android. Expo made developing for both platforms much easier, but a shared codebase did not eliminate the need for platform-specific testing.
The engineering behind a seemingly simple app
From the beginning, I tried to keep Pollzy's architecture as modular as possible. I knew I'd be building a lot of different systems, and I didn't want the codebase becoming a nightmare to maintain as I added features.
I went with Firebase for the backend, primarily using Firestore for data, Cloud Functions for server-side logic, and Storage for media. It was a practical choice for building the real-time functionality I needed without having to manage a lot of backend infrastructure myself.
The feed was more complicated than the swipe
The swipe-and-vote experience was actually the first interaction I built. I spent more time than I expected researching card-based interactions, including Tinder's swipe mechanics. I wanted the swipe to feel right, since it's something users would be doing constantly. But the much bigger challenge was everything behind the feed.
I didn't want Pollzy to simply display polls in chronological order. I wanted a personalized, algorithmic discovery experience while keeping the backend efficient and operating costs under control. I had to figure out how to select, rank, and personalize polls without making every page of the feed expensive to generate. I ended up building shared recommendation pools and using individual interest signals to personalize what users see, with caching and pagination to keep Firestore reads under control. I also had to account for new users who hadn't voted on anything yet.
The features nobody thinks about
One feature I really underestimated was multi-account support. From a user's perspective, switching accounts can be as simple as a double tap. Implementing that meant maintaining independent authentication sessions, isolating cached data and in-memory state, routing notifications to the intended account, and making sure information from one account could never carry over to another.
Push notifications involved much more than sending an alert. Expo Notifications handled the device-facing integration, but I still had to build the server-side routing, grouping, badge accounting, and account-aware behavior for different social interactions.
Messaging came with its own challenges, like handling message requests, deciding who can contact whom, and making sure notifications behaved correctly.
I also integrated services like RevenueCat for subscriptions, Stripe Identity for verification, and Google AdMob for advertising. I thought integrating AdMob would be relatively straightforward. It wasn't. Between native ads, mediation, and the various SDK integrations, I ended up spending far more time on advertising than I'd anticipated.
Advertising also showed me that using Expo did not mean avoiding native configuration entirely. Supporting AdMob mediation required native SDK adapters and platform-specific settings for networks including Unity Ads, Meta Audience Network, and Liftoff Monetize. I handled those integrations through project-local Expo config plugins, which kept the native setup reproducible instead of requiring me to manually maintain separate iOS and Android projects.
Here's the relevant plugin list from app.json:
Building with AI throughout the development process
AI was also a big part of how I built Pollzy. I used Codex extensively throughout development. In fact, one of the things I wanted to explore with this project was how far I could push AI-assisted development when building an actual product, rather than just experimenting with small projects. I'd already spent time working on AI initiatives at Xbox, so I was familiar with what these tools could do. But applying them to a project where I was responsible for absolutely everything was a different experience.
I used AI to help implement features, debug issues, refactor code, and work through parts of mobile development that were completely new to me. Codex was incredibly useful, but it wasn't a case of just asking it to build something and getting a working feature back. I still had to figure out the architecture, make the product decisions, review code, and catch things that weren't implemented correctly.
Even with all the reviewing and testing involved, AI made a huge difference in how quickly I could build. I'm not sure I would have attempted something this big on my own a few years ago.
The mistakes I'd avoid next time
One of my biggest mistakes was leaving a lot of the Firebase security rules work until late in development. I kept putting off security rules because I was focused on getting features working. When I finally tightened them, I ended up breaking a bunch of flows that had been working perfectly fine in TestFlight. I then had to go back through the app and fix things that I thought were already finished. If I were doing it again, I'd implement and test the security rules alongside each feature rather than leaving them until the end.
I also waited too long to pay attention to Firestore usage. By the time I started looking closely at reads and writes, especially across feeds and real-time listeners, I realized parts of the implementation were doing a lot more work than necessary. I ended up restructuring some of it to reduce unnecessary operations. Definitely something I'd think about much earlier next time.
I later built realistic Firebase emulator datasets and cost-profiling tools so I could exercise feeds, votes, comments, messaging, and notifications without experimenting against production. That made it much easier to identify unbounded queries, overly broad listeners, and interactions that generated unnecessary reads.
Getting from development to the App Store
One thing Expo made surprisingly painless was getting builds out to testers and eventually the app stores. With Expo Build and Expo Submit, distributing builds through TestFlight and Google Play became a repeatable part of my development workflow. Leading up to launch, I was distributing TestFlight builds roughly every other day, which made testing and fixing platform-specific issues much easier.
On August 26, 2026, Pollzy officially launched on iOS and Android. Going from having never built a mobile app to shipping one on both platforms was pretty satisfying. I've kept up a similar pace since launch, releasing updates roughly every two to three days.
The hardest part might actually come after launch
I was never particularly intimidated by the engineering involved in building Pollzy. I've spent years working through technical problems, and I'm also pretty stubborn when it comes to finishing things I've started. I figured I'd eventually work through whatever challenges came up. What I found much more intimidating was everything that came after building the app.
Marketing, for one. Building a social network is one thing. Actually getting people to use it is another. There's the whole cold-start problem of needing an existing community to make the platform interesting, while simultaneously trying to attract people when that community doesn't exist yet.
And then there's everything involved in running a business. Accounting, taxes, legal responsibilities, figuring out how to generate revenue, and so on. At Microsoft, there were entire teams handling different parts of a product and business. With Pollzy, I'm responsible for all of it. That's probably been the biggest adjustment so far.
So, how many engineers does it take?
When I've shown Pollzy to people, one of the reactions I get fairly often is surprise that I built the whole thing myself. I can understand why. There's a lot more going on behind the app than the relatively simple swipe-and-vote experience might suggest. I don't think this makes engineering teams unnecessary. But it definitely changes what one developer can realistically build.
Expo made cross-platform development and distribution much more accessible. Firebase took care of a lot of the backend infrastructure, and Codex helped me work through development much faster than I otherwise could have.
I started this project without having built a mobile app before. Now I have a social network running on both iOS and Android, and I'm figuring out everything that comes with keeping it running and trying to grow it.
If you'd like to check it out, you can try Pollzy. I'd love to hear what you think.
So, how many engineers does it take?
In this case, just one.