Grimoire Culinaire: 14 batches solo
700 tests, an 80% coverage gate, 14 batches, and a scoping mistake caught early enough to fix. A look at shipping a real mobile product, batch by batch.
A real product, not a side project
Grimoire Culinaire is an Android recipe app built as a real product: internal economy, useful AI, offline-first Supabase sync, gamification, and Play Store publication.
The challenge was not only to code the app. It was to keep the architecture stable over time while product integrations kept growing.
What 14 batches actually look like
Batch 1 covered the core: recipe library, manual creation, SQLite storage via Drift. Batch 8 covered full auth: unified login/register screen, Google OAuth, guest mode, email verification.
Batch 10 covered cooking mode: fullscreen PageView, parallel multi-timers, wake lock, local notifications. Each batch was a shippable and testable block, not a vague feature.
The scoping mistake the method made visible
Batch 9 was the hardest one: paywall + RevenueCat + AdMob in the same block. Three third-party integrations in one batch was too wide.
The post-delivery audit made the problem visible early. Subsequent batches were sliced more carefully. The method does not prevent scope mistakes; it makes them visible before they spread.
The technical backbone that held across 14 batches
The MVP ended with 6 Supabase Edge Functions, 66 Firebase analytics events, GitHub Actions CI/CD with an 80% coverage gate, and offline-first sync with retry queue and last-write-wins conflict resolution.
By the MVP's delivery, the Drift database had reached migration v11 with 10 tables, without turning the project into a fragile stack of exceptions.
What I take away
Lot-based delivery forces shipping. Not perfect shipping: clean, testable, auditable shipping.
It is less spectacular than a final rush, but it is what lets a real product survive 14 blocks without making every next block more expensive.