Grimoire Culinaire: 14 lots solo
400+ tests, 80% coverage, 14 lots, zero debt. A look at shipping a real mobile product, lot by lot.
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 lots actually look like
Lot 1 covered the core: recipe library, manual creation, SQLite storage via Drift. Lot 8 covered full auth: unified login/register screen, Google OAuth, guest mode, email verification.
Lot 10 covered cooking mode: fullscreen PageView, parallel multi-timers, wake lock, local notifications. Each lot was a shippable and testable block, not a vague feature.
The scoping mistake that forced the method to prove itself
Lot 9 was the hardest one: paywall + RevenueCat + AdMob in the same block. Three third-party integrations in one lot was too wide.
The post-delivery audit made the problem visible early. Subsequent lots 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 lots
The MVP ended with 7 Supabase Edge Functions, 51 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.
The Drift database 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.