50 écrans, 25 tables, un développeur seul, un mois

Les applis de niveau hackathon meurent généralement la deuxième semaine d'utilisation parce que le chemin de démonstration est le seul que le développeur ait jamais parcouru. Avec Roamly, je voulais voir à quel point une construction en solo pouvait se rapprocher d'une forme de production en un seul cycle de concours.

Pourquoi je l'ai construit

Les applis sociales existantes supposent qu'on vit quelque part. Les nomades, non. La vraie question pour quelqu'un qui bouge toutes les deux ou trois semaines, ce n'est pas « qui est près de moi maintenant », c'est « qui va aussi à Lisbonne en octobre, et est-ce que je peux lui faire confiance avant d'y arriver ». Rien sur le marché ne répondait à ça proprement, alors je l'ai construit.

Ce qui s'est retrouvé sur la table

• Plus de 50 écrans React Native couvrant la découverte par swipe, la messagerie en temps réel, les fonctionnalités de groupe, les invites vocales et un système de vérification validé par la communauté.
• Une couche de services modulaire avec plus de 15 services et un backend Supabase de plus de 25 tables protégées par Row Level Security et plus de 20 migrations.
• Une file de swipes haute performance avec traitement en arrière-plan, compteurs locaux pour un retour instantané, mise en cache intelligente et UI Reanimated pour tenir le 60 fps sur les interactions lourdes.
• Détection de convergence pour les nomades qui se dirigent vers les mêmes lieux, filtrage par priorité multi-intentions et score de compatibilité basé sur les intérêts et le style de vie.
• Verrouillage de fonctionnalités RevenueCat, sync de messagerie en temps réel, moteur de thèmes avec bascule instantanée sur plus de 5 palettes, et outils de sécurité pour le blocage, le signalement et la vérification faciale.

Comment je l'ai construit

La stack, c'est Expo et React Native avec expo-router, Reanimated v3 pour la surface de swipe et d'animation, Supabase pour la base de données, l'auth et les canaux temps réel, RevenueCat pour le verrouillage des abonnements, et TypeScript de bout en bout avec des types auto-générés depuis le schéma de la base. L'état est réparti sur cinq contextes (Auth, User, Theme, Subscription, Location) plutôt qu'un seul store global, comme ça chaque écran ne se re-rend que sur la tranche qu'il lit vraiment.

La file de swipes

La file de swipes est passée par trois révisions majeures. La version un écrivait dans Supabase à chaque swipe et saccadait. La version deux groupait les écritures mais perdait des swipes quand le réseau tombait en pleine session. La version trois, c'est celle qui a été livrée : un compteur local qui se met à jour instantanément, un processeur en arrière-plan qui vide la file dans la base, et un cache intelligent qui pré-charge le prochain lot de candidats avant que l'utilisateur n'arrive au bout. La couche Reanimated fait tourner les animations sur le thread UI, donc l'aller-retour vers la base ne bloque jamais la transition de carte.

Pourquoi le RLS a été le déblocage, pas le goulot d'étranglement

Le Row Level Security de Supabase a la réputation de ralentir le premier jour. Sur la durée d'un projet, c'est l'inverse : chaque nouvel écran arrive avec le modèle de sécurité déjà en place, chaque jointure passe le même filtre de politique, et on n'écrit jamais « vérifie l'utilisateur » dans le code. Avec 25+ tables, c'est la seule raison pour laquelle la base de code est restée saine.

Ce qui a été difficile

Trois choses ont pris du temps réel. D'abord, tenir les animations de swipe à 60 fps pendant que la file, le cache et le canal temps réel tournaient tous en même temps : j'ai réglé ça en poussant chaque animation sur le thread UI de Reanimated et en gardant le thread JS uniquement pour vider la file. Ensuite, concevoir un système de vérification qui résiste à l'abus sans devenir une file de modération : la réponse, c'est le vouching communautaire avec un seuil qui auto-vérifie dès qu'un utilisateur accumule assez de vouches de comptes déjà vérifiés. Enfin, le verrouillage d'abonnement sans polluer chaque composant : un seul hook useFeatureGate lit l'état RevenueCat depuis le contexte Subscription et retourne un booléen, donc les checks de fonctionnalités restent sur une ligne.

Ce que j'ai coupé

Les salles audio, l'économie de cadeaux et un « mode correspondance » étaient tous au tableau. Aucun n'a survécu à la coupe avant livraison. Le produit est plus fort parce que les fonctionnalités livrées sont celles pour lesquelles un nomade ouvrirait vraiment l'appli : qui se dirige là où je vais, est-ce que je peux lui faire confiance, est-ce qu'on peut se parler.

Ce que j'ai appris

• L'état local optimiste avec sync en arrière-plan bat l'attente d'un aller-retour vers la base à tous les coups, en chat comme en swipe.
• Découper l'état global en cinq petits contextes est plus simple à raisonner qu'un gros store, surtout quand Theme et Location se mettent à jour à des cadences différentes.
• Les types TypeScript auto-générés depuis le schéma Supabase attrapent plus de bugs à la compilation que toute suite de tests que j'aurais pu écrire dans les mêmes heures.
• Le design de communauté compte autant que le code. Une appli sociale, c'est ce que les règles de vérification laissent entrer.

La suite

Tout de suite : tests beta avec des vrais utilisateurs, notifications push pour les matchs et messages, modération étendue avec filtrage automatique du contenu, soumission à l'App Store et au Play Store, et travail de performance pour les Android d'entrée de gamme. Ensuite : Atlas AI pour la convergence intelligente d'itinéraires (l'intégration est câblée et commentée pour la V1), invites vidéo en plus des invites vocales (l'infra est déjà en place), événements de groupe et itinéraires partagés, et intégration calendrier pour planifier les rencontres.