Social fitness app + admin data platform
nobo
A social network and a fitness tracker in one app, two app stores to satisfy, and a founder who needed to see what was actually happening inside it.
The problem
Most social app briefs are really two products pretending to be one. There is the thing members touch, the feed, the profile, the workout log, and there is the thing the business needs: moderation queues, support tooling, campaign sends, and an honest answer to whether any of it is working. nobo had the first half sketched and none of the second. The app also had to do something apps rarely get away with: be a genuine social network and a genuine fitness tracker at once, on two operating systems whose health and motion APIs behave nothing like each other, with a team small enough that every hour spent chasing data by hand in a database console is an hour not spent on the product.
What we built
A production Flutter application shipping on the App Store and Google Play, a Firebase and Google Cloud backend behind it, and a React admin platform where the business is actually run.
The app
Five surfaces: a social feed with posts, stories and pages; workout planning and coached sessions; capture for food, workouts and challenges; a discovery layer holding communities, leaderboards and challenges; and a personal profile with diary, progress and privacy controls. Direct and community messaging runs throughout.
The fitness layer, done properly
Step counting is the part everyone underestimates. iOS and Android expose completely different sensors, and the naive implementation, take the counter and subtract a stored baseline, produces wildly wrong numbers the moment the platform's own window shifts underneath it. We rebuilt it against the native platform APIs on each side, with per-day queries rather than derived arithmetic, and wrote the rules down so nobody reintroduces the bug later.
The backend
Firebase and Google Cloud throughout: Firestore for data, and Cloud Functions for the logic that cannot be trusted to a client, which means follow and connection sync, feed fan-out, counter integrity, media cleanup on deletion, challenge leaderboards and notification triggers, plus a Cloud Run service for feed reads. Access control lives in security rules that are documented and tested, not improvised.
The admin platform
A React and TypeScript workspace where the business is actually run: members and account support, feed moderation, a reports and safety queue, page ownership and verification, a review queue for submissions, audit logs of sensitive admin actions, and internal task and calendar tooling. It mirrors the app's structure deliberately, so the person answering a support email is looking at the same shape of product the member is.
The data side
Two layers, on purpose. A Firestore aggregator produces the fast, in-product numbers. A native Firebase to BigQuery export gives the team a SQL backdoor for the questions dashboards never anticipate: time from signup to first post, which onboarding step loses people, whether the tab someone lands on first predicts whether they stay. Both stay inside the client's own cloud project, and no third-party analytics processor was introduced, which keeps the privacy story simple.
Communications
Campaign email lives in the admin platform, with per-recipient delivery logs, chunked sending so a large audience cannot silently stop halfway, and guards that refuse to send a campaign still carrying its own placeholder text. That last one exists because it happened once. It cannot happen again.
The part that is not visible
Before launch we ran a full readiness pass over the signup path, the feed backend and the fan-out triggers, and re-checked every finding against the live deployed configuration rather than against what the documentation claimed. Some of it was wrong, and fixing that before a launch surge is cheaper than fixing it during one. The same instinct runs through the rest: security rules mapped and documented, disaster recovery written down as a runbook, incidents recorded with the rule that came out of them, and a test suite over the backend logic that matters.
- Live on the App Store and Google Play, shipping regularly
- Five app surfaces, one Flutter codebase, both stores
Live on both stores and shipping regularly. The admin platform is in daily use, and a marketing site is built and waiting on launch.
What it proves
Any product where what the members touch and what the operator needs are really two builds: communities that have to be moderated, marketplaces that have to settle disputes, membership businesses with a programme attached. The app is what people see. The admin platform decides whether a small team can run the thing without a developer on call, and it is the half that almost never gets specified.