Christian Garciacg
← All projects
case study / 02Phase 1 / In Development

Nutrition Tracker

An offline-first Flutter nutrition tracker designed around a strict domain model: canonical units, centralized calculations, and clear boundaries between business logic and UI.

View source ↗
Platform
Flutter mobile
Architecture
Clean Architecture
State
Riverpod
Persistence
Drift + SQLite

01 / Context

Why this project exists

Nutrition apps look simple at the screen level, but their data model becomes fragile quickly. Serving sizes, unit conversion, recipe totals, and daily logs can all produce conflicting answers when calculation logic leaks into widgets or each feature stores nutrition differently.

This project starts with the domain rules instead of the interface. Nutrition is normalized to a single internal representation, recipes are derived from ingredients, and the presentation layer only asks for results. That foundation is intended to keep later feature work consistent and testable.

02 / System

Domain flow

  1. 01Store nutrition per 100g
  2. 02Capture amount + unit
  3. 03Convert in the domain layer
  4. 04Calculate food or recipe totals
  5. 05Persist locally
  6. 06Present logs + goals

03 / Decisions

Architecture decisions

Use one canonical representation

Nutrition values are stored per 100 grams, with grams and milliliters as base units. Conversions happen at explicit boundaries instead of creating parallel representations.

Keep math out of the UI

A centralized nutrition engine owns portion calculations, unit conversion, and recipe aggregation. Widgets consume domain results rather than reimplementing formulas.

Compute recipes from ingredients

Recipes are compositions, not separately maintained nutrition records. Totals are derived from ingredient values and quantities so edits have one source of truth.

Design for offline ownership

Drift and SQLite provide the intended local persistence boundary. Riverpod coordinates application state while repositories separate storage concerns from domain behavior.

04 / Delivery

Current state

The foundation is defined; feature delivery comes next

Phase 1 establishes the architecture, navigation, feature surfaces, documentation, and testing setup. The case study describes the intended system design without presenting placeholder screens as finished product functionality.

In scope now

  • Clean Architecture project structure
  • Navigation across the primary feature areas
  • Placeholder screens for log, foods, recipes, goals, and settings
  • Product principles and architectural decision records
  • Testing infrastructure

Next

  • Food database schema and entry workflows
  • Daily food logging
  • Ingredient-based recipe management
  • Nutrition calculations and goal tracking