Connected early-learning platform
Early-childhood learning platform spanning a parent mobile app, content operations, backend APIs, QR-based access, and progress analytics.
Product system
HungryBrain is more than a parent app: it joins physical product activation, per-child learning programs, operational content tooling, and progress analytics across Flutter, Next.js, Express, and PostgreSQL.
Program progression
Stages, typed tasks, prerequisite graphs, steps, and per-child progress
QR entitlements
Physical activation, family access, selected modules, and timed release
Content operations
Nested authoring, ordering, dependencies, cloning, and quick guides
Learning analytics
Engagement cohorts, detailed completion trails, filters, and exports
Case study
A focused view of the product problems, system boundaries, and engineering decisions behind the work.
Product reality
HungryBrain starts with a physical learning product but has to maintain a digital journey for an entire family. One account can include multiple caregivers and children, each child can activate different programs, tasks unlock through prerequisites, course modules may release gradually, and the operations team needs to understand who is progressing, who stopped, and who never began.
My contribution
I worked across the Flutter parent experience, the Next.js operations panel, Express APIs, PostgreSQL and Prisma domain models, and the access and analytics logic between them. The focus was to turn nested educational content into a system that could be activated from a physical product, progressed safely per child, managed by non-developers, and audited by the support team.
Engineering deep dives
Each story follows the user journey, its failure modes, and the decisions that made the system dependable.
Learning engine
Problem
Child-development programs are not linear checklists. They contain ordered stages, four kinds of learning tasks, multiple steps, and prerequisite relationships. The system has to recommend what comes next without unlocking dependent work too early or mixing progress between children in the same family.
Result
Each child receives the next available Activity, Association, Memory, and Problem Solving task for the current stage. Completing a step updates the same progression model used by the home experience, detailed program view, and family-level overview.
System path
Engineering decisions
A completion belongs to one child and one task step, with the caregiver and timestamp recorded. Task, stage, and program status are derived upward rather than stored as competing flags.
Before accepting a step, the API resolves every prerequisite task and verifies that all of its steps are complete for that child. A hidden or outdated client cannot bypass the graph.
The next-task service evaluates Activity, Association, Memory, and Problem Solving independently, allowing a child to progress across development areas without flattening them into one queue.
Batch skipping records missing steps transactionally and ignores existing completions, giving authorised workflows a repeatable way to move a child to an appropriate starting point.
Physical-to-digital access
Problem
A code included with a physical product must grant the correct digital content—not simply mark a purchase. It can target a program or course, belong to a particular child and family, include only selected course modules, and release those modules on a configured schedule.
Result
Scanning a valid code creates an auditable family-and-child activation. The backend returns only the entitled content, exposes future modules as locked metadata, and automatically opens them according to the activation schedule.
System path
Engineering decisions
A typed QR target supports programs, products, and courses while a composite family, child, and code key prevents the same entitlement record from being created twice.
Course responses include full chapters and items only for granted, unlocked modules. Locked modules expose their title and unlock time without leaking protected content to the app.
Module release times are calculated from the QR activation timestamp and configured duration. When multiple codes grant a module, the earliest valid unlock wins.
Free courses bypass QR scheduling and unlock all modules, while purchased courses preserve their code-level module selection and pacing rules in the same response contract.
Operations platform
Problem
Programs contain deeply nested stages, tasks, steps, task types, media, prerequisites, ordering, and parent-facing guides. Managing that structure through scripts would make every curriculum change slow, fragile, and dependent on engineering.
Result
The operations team can build and evolve complete programs from the web panel, including inline edits, drag ordering, dependency links, reusable program structures, and Markdown quick guides consumed by the parent app.
System path
Engineering decisions
A sheet-style interface keeps tasks, nested steps, task types, dependencies, and dependents visible together, with focused inline mutations instead of a chain of disconnected forms.
Program, stage, task, step, and guide indices are persisted explicitly. Drag operations rewrite that order so every client receives the same curriculum sequence.
Cloning recreates stages, tasks, and steps, records the old-to-new task ID map, and then rebuilds prerequisite edges against the cloned IDs instead of pointing new content back to the source program.
The Next.js admin works directly against the shared Prisma schema, while the Express API presents the resulting structure to Flutter through a stable response envelope.
Progress intelligence
Problem
A completion percentage alone cannot tell the operations team who needs help. They need to separate active learners, children who stopped, and families that activated a product but never started—then trace the exact stage, task, or course item behind that status.
Result
Program and course dashboards turn raw completion records into searchable engagement cohorts and detailed histories, giving support teams a direct path from an overview to a specific child's latest activity.
System path
Engineering decisions
Analytics distinguishes active today, inactive beyond a configurable threshold, and never-started activations instead of hiding all three behind a single average.
Queries join child, family, preferred caregiver contact, program, current stage and task, and last completion so the result can drive follow-up without another lookup workflow.
Date ranges and day boundaries use the operating timezone consistently, including the different meaning of a dated completion versus inactivity that carries forward.
Teams can drill into step-level program history or module, chapter, and item-level course progress, filter the evidence, and export all matching completion rows as CSV.
I can help take your next digital product from idea to production.
Get in Touch