One-to-one and group threads
Each client has a thread with their coach. Group threads carry membership management and role badges, so it is clear who is a coach, a closer or a member.
Published on
iOS and Android
Program
Four phases
Coaching
In the app
Built with
Flutter and Supabase
The brief
Everything the program needs, in one place the client owns
The course content, the coaching conversations and the progress data each lived on a different platform. Relance Métabolique wanted them in one app, published under its own name on both stores, with the data behind it in a database the company controls.
That shaped the build. Wherever a hosted service would have been quicker to wire up, we priced what it would cost the client in ownership before we used it.
- Program content
- Coach messaging
- Progress tracking
- Access from the CRM
- Push notifications
- iOS and Android
How we framed it
The app is the product. Anything the business cannot change, export or take with it does not belong in the build path.
The program
Four phases, delivered in the app
The full Relance curriculum sits in the app: Libération, Réintégration, Rééquilibre and the Défi Boost track. The rented course platform is gone.
What a client opens
- The phase they are in, and the day they are on
- Modules and sub-modules with video lessons
- Approved food lists and the day-by-day reintegration table
- Recipe collections, downloadable guides and FAQs
- Content tiered by the program they bought
Coaching
A messenger built for coaching, not a support widget
This is the largest piece of engineering in the app. Coaches had been working out of a personal Messenger inbox; the conversation now lives beside the client's progress data, and the business owns both.
Voice notes and images
Text, photos and voice notes recorded in the app. A coach can answer a long question by speaking it, which is how most of them prefer to work.
Realtime, with the details
Messages arrive live, with typing indicators, reply quoting, pinned messages, per-conversation mute and deletion governed by role.
Canned replies and client context
A coach answers a recurring question from a saved reply, and opens the client's summary sheet without leaving the thread.
Scheduled messages
A coach writes once, picks a recipient list and a time, and a server-side job sends it and keeps the run history.
Roles and permissions
Coach, closer and member each get their own permission set, so pre-sale conversations stay separate from coaching.
Why we built it
We evaluated the hosted chat products first. Each one brings its own backend and meters by active user, so picking one would have moved the conversation data onto a third platform and put a per-client cost on growth. That is the dependency the project existed to remove.
What we built instead
The messaging interface runs directly against Supabase, the database the app already uses. Role gating, group semantics, voice capture and the coach tooling are all ours, and every message stays in the client's own database.
Progress
The data the program is judged on, in one database
Weight, measurements and photos used to be self-reported into whatever the client had to hand. They are now recorded in the app, charted for the client and visible to their coach.
What the app records
- Daily weigh-ins with a trend graph
- Body measurements over time
- Progress photos with before and after comparison
- Access checked against the client's CRM record on sign-in
- Push notifications, with per-user preferences
An assistant beside the coaches, not instead of them
A separate Coach IA tab answers routine program questions, backed by a self-hosted n8n workflow that keeps the conversation thread. It opens by telling the client it can be wrong and that their human coach is the authority. It exists to protect coach time on the questions that have a documented answer.
Delivery
Validated in low‑code, then moved to a codebase the client owns
The first version shipped from FlutterFlow on purpose, because it was the fastest way to settle the product questions with real clients. When the roadmap turned to the messenger, we left the platform.
-
Get a real app in front of real clients
First version- Built in FlutterFlow and shipped rather than specified
- Program structure settled on a phone, not on paper
- Tracking screens and onboarding shaped by use
- Product questions answered while they were still cheap
-
Leave the platform cleanly
The pivot- Realtime, voice capture, role permissions and scheduled fan-out sit past what low-code can express
- We took the export and froze it on its own branch as a baseline
- Development continued by hand from that point
- No rewrite from scratch, and no interruption for clients already using the app
-
Keep the decisions recoverable
Practices- Written specs for significant features, versioned alongside the code
- Database changes ship as migrations, never as dashboard clicks
- Tables, policies, storage buckets and cron jobs all in the repository
- Outbound endpoints held in vault secrets, with the environment set at compile time
-
Test the shipped app, not a mock of it
Every release- Maestro flows drive the real app through its accessibility layer
- Organised by persona: VIP, Boost, coach, closer, profile, account deletion
- One local runner, interleaving database resets between flows
- New user-facing features arrive with their test flow
-
Release without hand steps
Continuous- A push to the release branch triggers Codemagic
- iOS to TestFlight and Android to the Play internal track, from one build
- Flutter SDK pinned to match local development exactly
- Every release since the first has run this way
The result
Relance Métabolique ships its own app on both stores, with the program, the coaching and every client's history in a database the company controls.
For the clients
One login for the whole program: the phases, the food lists, the recipes, the guides, their coach, and their own progress over time.
For the coaches
An inbox across every assigned client, with canned replies, scheduled broadcasts and the client's context available inside the thread.
For the business
No course platform subscription, no chat service metering active users, and no low-code vendor sitting in the build path.
Flutter, SDK pinned with FVM · Dart · Supabase for Postgres, auth, storage, realtime and edge functions · Firebase Cloud Messaging · go_router · provider · GoHighLevel CRM · self-hosted n8n · Maestro · Codemagic
The Relance Métabolique program, its methodology and its content belong to Relance Métabolique. The app ships in French.
Ship your app on both stores and keep the codebase
We build mobile products end to end, from the first version that answers the product questions to the release pipeline that publishes every build after it. You keep the repository, the database and the store listings.