01 Marketplace · Paiements · Mobile

Kayn Fitness

  • Elixir
  • Phoenix
  • Ash
  • Oban
  • GraphQL
  • React Native
  • Postgres
  • Cloudflare

Un réseau fitness à la séance pour le Maroc. Les membres achètent des jetons et réservent une salle de sport, une piscine, un studio de pilates, un terrain de padel ou un spa depuis un seul solde — sans abonnement. Les salles ouvrent leurs créneaux vides et sont payées pour chaque passage.

Visiter le site

Deux côtés, un seul système

Membres

Acheter un pack de jetons, trouver une salle par sport ou par lieu, réserver un créneau, et scanner un pass QR à l'entrée. Les jetons ne quittent le solde qu'à une visite effective.

Salles

Fixer leur propre tarif, ouvrir les heures creuses de leur choix, gérer les séances et la capacité, et recevoir un reversement unique et agrégé chaque mois.

Ce qui a été difficile

  1. 01

    Deux produits, un seul système

    Une marketplace n'est pas une seule application. Les membres et les salles ont des besoins opposés, mais ils partagent les réservations, la capacité et l'argent — donc les mêmes règles doivent tenir des deux côtés à la fois.

  2. 02

    De l'argent qui ne peut pas disparaître

    Les jetons sont de la valeur prépayée. Une réservation qui échoue après débit du solde, ou un passage compté deux fois, c'est un client qui a payé pour rien et une salle payée pour une visite qui n'a jamais eu lieu.

  3. 03

    La capacité est une course

    Un cours à huit places reçoit plus de huit personnes qui appuient sur réserver en même temps. Survendre un créneau, c'est refuser quelqu'un à la porte pour une séance qu'il a déjà payée.

  4. 04

    La porte est le pire endroit pour échouer

    Le check-in se fait sur un téléphone, dans une salle, avec la connexion disponible sur place. Il doit fonctionner dans une salle de sport en sous-sol sans réseau aussi fiablement que sur Wi-Fi.

Comment nous l'avons construit

01

Réservation et solde dans une seule transaction

Débiter les jetons et réserver une place se font ensemble, ou pas du tout. Il n'existe aucun instant où un membre a été facturé sans détenir de réservation.

02

Capacité imposée au niveau de la base de données

La limite de places est maintenue là où sont les données, pas dans le code applicatif en espérant que deux requêtes n'arrivent pas en même temps — ainsi une séance complète reste complète même sous une ruée simultanée.

03

Reversements construits à partir d'un registre auditable

Chaque passage est un événement enregistré. Le reversement mensuel d'une salle est calculé à partir de ces événements plutôt que d'un total courant, si bien qu'un montant contesté peut être retracé jusqu'aux visites qui le composent.

04

Des règles déclarées une fois, appliquées partout

Qui peut annuler, ce que coûte un créneau, quand un remboursement s'applique — défini dans la couche métier, pour que l'application mobile, le tableau de bord des salles et l'API ne puissent pas se contredire.

Le prochain pourrait être le vôtre.

Dites-nous ce que vous construisez et ce qu'il ne peut pas se permettre de rater. Nous vous dirons honnêtement si nous sommes la bonne équipe pour ça.

Démarrer un projet hello@elixiria.ma
enfrar