Social

How Pop-out Shipped a Swipe-and-Poll Social MVP Ahead of Its Original Timeline

Techparser built the Pop-out social MVP on Flutter and Firebase in April–May 2026, delivered ahead of the original timeline with full source code handed over.

Client
Pop-out
Industry
Social
Timeline
April 2026 – May 2026
Team
1 engineer

Want results like these?




Results

Ahead
Of the original timeline, in the client's words
2 months
Engagement, April to May 2026
Full
Source code and setup instructions handed over

The problem

Pop-out lets people discover each other through a swipe interface and interact through polls. The founder, Jentzen Malone, needed a working MVP to test the idea with real users, quickly, and without building features the idea had not earned yet. Social apps invite scope creep: chat, stories, recommendations, moderation. Each one is reasonable on its own, and each one delays the day the founder learns whether people swipe and vote at all. The brief was therefore as much about what to leave out as what to build, and about getting to a testable app in weeks rather than months.

The MVP also had to be handed over cleanly. The founder wanted the full source code, instructions to set up Firebase and release builds, and support through testing, so that the next version could be built by whoever he chose rather than being tied to one developer. That meant documenting the Android keystore and the Firebase configuration files rather than leaving them on one machine. Real-time data mattered too: a poll result that lags or a vote that double-counts would make the product feel broken during the exact test it was built for.

What Techparser built

  • Swipe discovery of other users, with a paginated feed that batches Firestore lookups in groups of ten to respect the whereIn limit.
  • Polls: create a poll with options, answer it and see results, with vote counts incremented inside Firestore transactions so concurrent votes cannot double-count.
  • Accounts with email sign-up, login, password reset by email link, and password change with re-authentication.
  • Profile setup with a photo, compressed on device before upload to Firebase Storage, and a profile screen.
  • A feed, bottom navigation and a shared loading state across every screen.
  • A handover package: full source code, setup instructions for Firebase config files and the Android keystore, and support through testing.

Decisions that mattered

Keep the MVP about the idea

Every proposed feature was tested against one question: does it help learn whether people swipe and vote? Chat, notifications and recommendations did not, so they stayed out of the MVP. The founder's words: the work 'helped keep the MVP focused without over-complicating things.' Keeping scope tight is what allowed the MVP to land ahead of the original timeline rather than on it, and it leaves the next version free to add what the test shows users want.

Real-time data that stays correct

Firestore gives real-time updates for free, but correctness under concurrency does not come for free. Vote counts are updated inside transactions, swipes and like or dislike actions are separate collections so a feed query never has to scan interaction history, and images are compressed before upload so profiles load quickly on mobile data. The module structure, with a binding, controller and repository per feature, means each of these decisions lives in one place.

Hand over something the next developer can run

An MVP that only its author can build is a liability. Techparser delivered the repository with a README covering architecture, Firestore collections, Firebase setup, keystore configuration and release commands, and stayed available through testing and final delivery. The client confirmed that the source code and set-up instructions were part of the handover, which is what makes a second version possible with any team.

Design once, fit every phone

The founder supplied designs at a single phone size. Rather than build separate layouts, every dimension in the app scales from a 440 by 956 design base through flutter_screenutil, and the SF Pro typeface ships with the app so text renders the same on iOS and Android. Eleven screens, from splash and sign-up through swipe, polls, feed and profile, share one theme file and one colour palette, so a visual change is a single edit.

Outcome

The MVP was delivered in an engagement that ran from April to May 2026, ahead of the original timeline according to the client, with full source code and setup instructions handed over. The delivered app covers eleven screens across accounts, profile setup, swipe discovery, polls and a feed, on one Flutter codebase for iOS and Android.

As of September 2026 Pop-out is a completed MVP handover rather than a public store listing, so this study reports no install or rating figures. What it reports instead is the delivery record: a scoped MVP, an early finish and a clean handover.

Questions about this project

How long did the Pop-out MVP take?
The engagement ran from April to May 2026, and the client reported that the MVP was completed ahead of the original timeline. The scope covered swipe discovery, polls with live results, accounts and profiles, plus a handover package. Keeping features that did not test the core idea out of the MVP is what kept the schedule short.
What stack was the Pop-out MVP built on?
Flutter with a modular, layered architecture, on Firebase: Authentication for accounts, Cloud Firestore for users, swipes, actions, polls and votes, and Firebase Storage for profile photos compressed on device. Firestore transactions handle vote counting and the feed is paginated. The whole MVP is one Flutter codebase for iOS and Android.
Do we own the code if Techparser builds our MVP?
Yes. Pop-out was handed over with the full source code, a README covering setup and release, the Firebase configuration steps and the Android signing setup, and Techparser supported the founder through testing. You can continue with Techparser or with any other team. Ownership of the repository is part of every MVP engagement.