Skip to main content
Back to homepage

Personal Project · Solo Build · Live

Familia.life

Role: Product, design and engineering

A weekly planning tool for families. Tell it who is eating, how much time you have and roughly what you want to spend, and it returns a week of meals, a grocery list built from them and activity ideas. Free to start, no credit card.

Visit Familia.life
Familia.life landing page showing the family size, cooking time and weekly budget inputs.
2 weeks
idea to live
3
inputs to a full week
Solo
product, design and engineering
Familia.life weekly plan showing breakfast, lunch and dinner for each day with time and cost.

The Problem

The gap between a grocery list and a week of meals

The hard part of family food logistics is not the cooking. It is the sequencing. Deciding what the week looks like, working backwards to what needs buying, and then doing the whole thing again seven days later.

I built Familia.life because I wanted that tool to exist in my own household.

Why I Built It

Two things I wanted to find out

The first was whether the problem could be solved in a way that felt light, rather than becoming another system to maintain.

The second was professional.

  • Whether I could take an idea from nothing to a live product on my own
  • What new tooling actually changes about the process, rather than what it claims to change
Familia.life input screen on a phone: who is eating with adult and child steppers, cooking time options, weekly budget options, a collapsed optional preferences row, and a summary line reading three members, 60 min, low budget above the Create my plan button.

Design Decisions

Three inputs, nothing else

The product asks for three things: who is eating, how much time you have, and roughly what you want to spend. Preferences exist but stay collapsed and optional. A running summary line confirms the choice back to you before you commit.

  • Cooking time is a primary input, not a filter applied afterwards
  • Budget is expressed as a rough weekly range rather than an exact figure, because families do not plan to the euro
  • The grocery list is derived from the meal plan automatically, so nobody has to bridge that gap by hand
  • The AI generation is labelled openly rather than hidden behind the interface

The last one matters most to me. A system that quietly decides things on your behalf is harder to trust than one that tells you what it did.

Adjusting, Not Regenerating

Change one meal without losing the week

The obvious way to build this is a single generate button. Do not like the result, press it again. That throws away everything the user already accepted in order to fix the one thing they did not.

Instead, every meal carries two inline controls: make it faster, and make it cheaper. Those are the two axes families actually negotiate on, so they became first-class actions on each row rather than settings buried in a preferences panel.

The unit of change is the meal, not the week.

Familia.life recipe view showing per-ingredient prices, a total cost estimate and cooking steps.

Estimating Honestly

Showing the cost, and its limits

Every recipe breaks down to per-ingredient prices and a total, so a family can see where the money goes rather than trusting a single figure. Rolled oats at forty-five cents, berries at two euros.

Under it sits a plain sentence: average supermarket prices, actual cost varies by store, region and brand.

An estimate presented as a fact is a broken promise waiting to happen. Saying what a number is worth costs one line and buys the whole feature its credibility.

Planning For Real Life

Leftovers are a feature, not an accident

Monday's chicken stir-fry becomes Tuesday's lunch, labelled as leftovers, costing five minutes instead of thirty-five.

Families already do this. Most planning tools ignore it and generate seven unrelated dinners, which quietly inflates both the grocery bill and the cooking time the plan promised.

Designing leftovers in meant the plan could hold its own time and budget claims instead of breaking them by the second day.

How I Built It

Product, design and engineering, all me

Built with Lovable and Supabase. I owned the product decisions, the interface and the implementation, which meant every design choice had to survive contact with the thing that actually builds it.

There was no handoff, no spec to write, and nobody to absorb an idea that did not work in practice.

What Changed

What it changed about how I work

Working end to end with AI tooling shifted where my time goes. Less of it on producing artefacts, more on judgement about what should exist in the first place.

It also means I can take a design intent to a working, deployed prototype without waiting on engineering. That changes what a design conversation can be, because the thing being discussed is real.

Got a challenge? I'd love to hear about it.

Send the rough version. I read every message and reply personally, usually within a few days.

A few sentences is plenty. What the product is, what is breaking down, and roughly when you need it solved.