Back to home page

build

Built for myself

Two apps I use every day.

the problem

Food and training, and shared money, each needed an app that did the whole job, privately.

why it hurts

People stay with a flawed incumbent until something clearly better exists.

what i built

Two apps to replace them: Fuel for food and training, and Tally for shared money, each installable to a phone with privacy enforced in the database. I built them for myself, as their most impatient user.

the apps

  • Fuelin daily usefull page →

    Food, weight and training in one phone app: photograph a meal or scan a barcode for the macros, and it works offline.

  • Tallyin daily usefull page →

    One shared ledger for two people that separates what left the bank from what each person really spent.

how it works

Four ways in, because friction is why food tracking gets abandoned. Photo, barcode, search, or a saved meal, with the day still empty underneath.

01 / 08

Four ways in, because friction is why food tracking gets abandoned. Photo, barcode, search, or a saved meal, with the day still empty underneath.

The training half of the same app: the session plan for the day, and sets logged weight by reps as they happen.

02 / 08

The training half of the same app: the session plan for the day, and sets logged weight by reps as they happen.

Search runs against the Open Food Facts corpus, so real supermarket products come back with real per-100g numbers.

03 / 08

Search runs against the Open Food Facts corpus, so real supermarket products come back with real per-100g numbers.

The day once a meal has landed: calories left against target, the four macros underneath, weight and steps below that.

04 / 08

The day once a meal has landed: calories left against target, the four macros underneath, weight and steps below that.

Merchant memory: three letters of Sainsbury's and the category, the card and the 50/50 split are filled in. The amount never is. Invented data throughout.

05 / 08

Merchant memory: three letters of Sainsbury's and the category, the card and the 50/50 split are filled in. The amount never is. Invented data throughout.

The four numbers, worked out when read: what left my accounts, my real spend, household spend counted once, and the running balance between us.

06 / 08

The four numbers, worked out when read: what left my accounts, my real spend, household spend counted once, and the running balance between us.

One ledger, searchable: every Sainsbury's shop this month, whoever paid and from whichever card.

07 / 08

One ledger, searchable: every Sainsbury's shop this month, whoever paid and from whichever card.

Settling up is a transfer, not spending: the balance goes to all square and no category moves.

08 / 08

Settling up is a transfer, not spending: the balance goes to all square and no category moves.

why it's useful

Both are in daily use.

what i learnt

  • Daily return is the bar.
  • Personalisation does not need a model; knowing what not to predict matters more.
  • Pick the smallest stack that works for each app.

technical specs

Supabase (Postgres, row-level security)Progressive web appsVanilla JavaScript (Fuel)React 19 and TypeScript on Vite (Tally)Open Food Facts (Fuel)
  • Two stacks, chosen per app. Fuel is a single file of vanilla JavaScript with no build step. Tally is React 19 and TypeScript on Vite, with Tailwind CSS v4.
  • Both run on Supabase, with row-level security doing the privacy work in the database, and both install to a phone.
  • Fuel works fully offline and syncs when it can. Tally keeps a ledger of what happened and works out its four numbers when read.
  • Fuel resolves barcodes and searches against Open Food Facts, and a vision model estimates photographed meals as editable entries.
  • Tally scopes every row to a household through a single security-definer function, with its own schema and schema-scoped grants.
Back to home page