Context
NETME is a Munich-based social app built on a deliberately contrarian premise: no swiping, no endless chat, no judging by profile photos. The entire product is designed to get people offline as fast as possible — find someone nearby, pick a meeting place, send an invitation, and once it's accepted, the interaction moves out of the app and into real life.
That premise puts unusual engineering weight on a handful of modules most social apps treat as afterthoughts. If the whole point is a real-world meeting, then the meeting-point selection, the pre-meeting chat, and the invitation lifecycle are the product — not supporting features around a feed or a swipe deck. Working on this Flutter project under the lead of Haris Akram (Project Lead), I — Muhammad Ahmad Khan, Senior Flutter Engineer — owned four of these core modules: subscriptions, the Google Maps meeting-point flow, chat (message and voice), and authentication.
The Product
A tour of the surfaces tied to the modules in this case study — discovering people and places nearby, choosing a meeting point and sending an invite, premium benefits, the invites list, and sign-in.
The Problem
- Subscriptions had to be native, not bolted on. NETME runs a freemium model — free to use, with paid upgrades for unlimited invitations, advanced filters, and higher visibility. App store policy requires digital subscriptions to go through platform billing, so this meant building against Google Play Billing and StoreKit natively, while keeping entitlement state consistent for the same user across both platforms.
- Meeting-point selection needed to feel human, not like a maps widget bolted onto a dating app. The core interaction — proposing a place to meet, whether a restaurant, a bar, or a café — had to be simple enough to pick in a couple of taps.
- Chat had to be temporary and tied to the invitation lifecycle, not always-on. Unlike a typical dating app's persistent chat, NETME's chat unlocks once an invitation is accepted and stays relevant around the meeting itself — plus support voice, not just text.
- Authentication had to satisfy platform policy and real user preference at once. Offering Google sign-in on iOS obligates offering Sign in with Apple as well under App Store guidelines, and email/password needed to remain available — all three had to resolve to one consistent user identity.
What I Built
Native subscriptions — Google Play Billing + StoreKit
Implemented subscriptions using each platform's native purchase system rather than a web-based paywall, so purchases, renewals, and restores follow platform-standard flows users already trust. Built the entitlement layer so a user's premium status (unlimited invitations, advanced filters, higher visibility) stays consistent regardless of which platform they purchased on, with purchase restoration handled so reinstalling the app or switching devices doesn't strand a paying user.
Google Maps meeting-point flow
Built the meeting-point selection experience on top of Google Maps: choosing a location to propose for a meetup, attaching it to an invitation, and presenting it clearly to the person on the other end. The goal was to make picking "where" as frictionless as picking "who" — the map is in service of the invitation flow, not a separate destination in the app.
Message and voice via Firebase + WebRTC
Built the chat system on Firebase (Firestore/Realtime Database) for real-time messaging, tied directly to the invitation's state — the conversation becomes available once an invitation is accepted, matching the product's design of a temporary, purpose-bound chat. Added voice calling on top using WebRTC, giving users a lower-friction way to coordinate details or get a read on the other person's voice before meeting in person.
Authentication — Google, Apple, and email/password
Implemented all three supported sign-in paths, resolving to a single unified account model regardless of which method a user chooses, so switching sign-in methods or linking providers later doesn't fragment a user's identity or their subscription/chat history.
Why These Choices Mattered
Beyond being a platform requirement, native IAP is the flow users already trust with their card details — building the entitlement sync layer on top was the harder but necessary part, since "premium" has to mean the same thing whether the purchase happened on Android or iOS.
The meeting-point flow only succeeds if it disappears into the invitation process — over-engineering it into a full map-browsing experience would have worked against the product's actual goal of getting two people to agree on a place quickly and get offline.
Tying chat availability to invitation state, rather than making it permanently open, is what keeps the product's core differentiation intact — NETME's chat exists to facilitate a specific meeting, not to become another messaging app people never leave.
Supporting Google, Apple, and email/password isn't just a checklist of options — it's what lets the app satisfy App Store policy while still giving users who are wary of social login a straightforward alternative, without splitting their account across methods.