All case studies

Case study

A coaching program that now runs on one app the client owns

  • Live · App Store and Google Play
  • iOS and Android · French

Relance Métabolique runs a metabolic health program in Québec, where named coaches guide each client through the program and stay with them afterwards. We built the Flutter app that carries the whole program, the coaching conversations and every client's progress, on a backend the company controls.

The Relance Métabolique home screen: Programme Relance with the Libération and Réintégration phases, and Programme Équilibre with stabilisation and the Défi Boost track.
Published on iOS and Android
Program 4 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 requirement 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.

This principle settled 3 of the larger decisions on this project: the messenger, the backend, and when to leave the low-code platform.

The program

Every program phase, delivered in the app

The full Relance curriculum sits in the app: Libération, Réintégration, Stabilisation and the Défi Boost track, replacing the rented course platform the program used before.

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

The messenger 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.

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.

Voice notes and images

Clients and coaches exchange text, photos and voice notes recorded in the app, and 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 reply quoting, pinned messages, per-conversation mute and deletion governed by role.

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.

What we built

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.

  1. Get a real app in front of real clients

    First version
    • Built in FlutterFlow and shipped rather than specified
    • Program structure settled on a real phone
    • Tracking screens and onboarding shaped by use
    • Product questions answered while they were still cheap
  2. 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
  3. 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
  4. Test the app as it ships

    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
  5. 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

The business no longer pays for a course platform or a chat service that meters active users, and no low-code vendor sits 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.

Have a project in mind?We build it and keep it running.

Book a call