Grimoire Culinaire : 14 lots en solo

Grimoire Culinaire est une app Android de gestion de recettes pensée comme un vrai produit : économie interne, IA utile, sync Supabase offline-first, gamification, publication Play Store.

Le sujet n'était pas seulement de coder une app. Il fallait tenir dans la durée sans que l'architecture s'effondre au fur et a mesure des intégrations produit.

Le lot 1 couvrait le cœur : bibliothèque de recettes, création manuelle, stockage SQLite via Drift. Le lot 8 couvrait l'auth complète : écran unifié login/register, Google OAuth, mode invite, vérification email.

Le lot 10 portait le mode cuisine : PageView fullscreen, multi-timers parallèles, wake lock, notifications locales. Chaque lot était un bloc livrable et testable, pas une feature vague.

Le lot 9 a été le plus dur : paywall + RevenueCat + AdMob dans le même bloc. Trois intégrations tierces dans un seul lot, c'était trop large.

L'audit post-livraison a rendu l'erreur visible très vite. Les lots suivants ont été redécoupés plus finement. La méthode n'empêche pas les erreurs de scope; elle les rend identifiables avant qu'elles contaminent le reste du projet.

Le MVP s'est termine avec 6 Edge Functions Supabase, 66 évènements analytics Firebase, un CI/CD GitHub Actions avec gate de couverture a 80%, et une sync offline-first avec queue de retry et résolution de conflits last-write-wins.

À la livraison du MVP, la base Drift était allée jusqu'à la migration v11 avec 10 tables, sans que le projet devienne fragile à chaque nouveau lot.

Le découpage en lots force la livraison. Pas la livraison parfaite : la livraison propre, testable et auditable.

C'est moins spectaculaire qu'un rush final, mais c'est ce qui permet de tenir un vrai produit sur 14 blocs sans que chaque lot rende le suivant plus cher.