Larder
A kitchen that knows what is actually in it.
A stock ledger for a household: what is in the pantry, what this week's cooking needs, the difference between the two, and when to buy it. Eleven build phases, complete, and the environment where several of our offline-sync and AI-extraction patterns were proven before they went anywhere near client work.
- 11 phases
- all built
- Offline tolerant
- works in a kitchen
- Multi-user
- one live household
The problem
Meal planning apps assume an empty kitchen
Every one of them starts from a recipe and produces a shopping list, as if the pantry were empty. Real households already own most of what a recipe needs. The useful question is not what to buy but what is missing, and answering it requires knowing what is genuinely in the cupboard.
How it was built
In order, and why.
01
Stock as a ledger
Quantities as movements rather than a current count, so the number is derived and correctable. A household inventory that cannot be corrected without lying about history stops being trusted within a fortnight.
02
Diff, don't list
The planner computes the shortfall between what the week's cooking requires and what the ledger says is present. The shopping list is the difference, not the ingredients.
03
Capture without typing
AI receipt capture, because any system that needs manual entry of forty grocery items after a shop will be abandoned by the second week.
04
Make it a household
Multiple people editing the same live state from different devices, including the one standing in the kitchen with no signal.
The part that was actually hard
Two people in a kitchen with bad wifi
Household inventory is a distributed systems problem hiding in a domestic one. Two people put things away at the same time, one phone has no signal behind the fridge, and both are editing the same quantities. Larder is local-first with queued operations and an explicit conflict policy, so the till-style rule applies: the device keeps working alone and reconciles honestly afterwards. Those patterns went on to underpin how we build offline-tolerant client work.
What it does
The features that carry it.
01
Live stock ledger
Movements rather than counts, so the current quantity is derived and a correction fixes history instead of inventing a jump.
02
Shortfall diffing
The plan needs this, the pantry has that, buy the difference. The core operation the category usually skips.
03
Cook calendar
A week planned around what is already in stock and what expires soonest, rather than around whatever the recipe feed suggested.
04
Purchase-timing engine
Not only what to buy but when, based on consumption rate and what is about to run out.
05
AI receipt capture
Photograph a receipt, get stock movements. Confidence-scored, with review for anything uncertain.
06
Live household
Several people, several devices, one shared state, with sensible behaviour when two of them edit at once.
Outcome
What actually changed.
01
All eleven phases built
A complete system rather than a prototype: stock ledger, planning, purchase timing, capture and a live multi-user household.
02
Works with no signal
The device is authoritative while offline and reconciles honestly afterwards, which is what makes it usable in the room it was built for.
03
Patterns reused since
The local-first sync and confidence-scored extraction approaches proven here are the ones we now reach for on retail and field-service work.
In hindsight
What we would do differently.
We stored quantities as absolute values for the first two phases and had to migrate the entire ledger to movements. Absolute values look simpler and they silently lose data the moment two devices edit while disconnected, because the last write wins and the other change disappears without an error. It is the most expensive lesson in the project, and it is why every stock system we have built since starts as a ledger.
Built with
The stack underneath.
- Backend
- NestJS, Prisma, PostgreSQL, BullMQ
- Web
- Next.js, React, TypeScript
- Mobile
- Expo, React Native, local-first sync
- AI
- Receipt extraction with confidence scoring
Where it stands today
Built through all eleven phases and running as a live environment rather than a demo. Its value to an engagement is the patterns it proved: local-first sync with an explicit conflict policy, and confidence-scored AI extraction with a review path. Both now ship in retail and field-service work.
Practice areas this evidences
Want something like this
This is bought as one of these.
Fixed-price project
Mobile Apps
Fixed-price project
iOS and Android from one codebase, shipped to both stores. Offline-first where staff work in basements and stockrooms.
Fixed-price project
AI Integration
Fixed-price project
AI added to software that already exists — where it removes real work, not where it reads well in a deck.
Fixed-price project
Web Applications
Fixed-price project
Customer portals, operational dashboards, booking systems and internal tools. The things a spreadsheet used to do until it stopped coping.
Tell us what you’re trying to build.
If something here looks like the problem you have, say so and we’ll tell you how close it actually is.
Phone
+1 (407) 796-2376Reply time
One business day, from an engineer
Based in
Orlando, Florida · serving the United States
What happens next
- A reply within one business day, from an engineer
- A thirty-minute call, with no qualifying call before it
- A written scope and a fixed number, if it fits