Vesta

Overview

Vesta is a home inventory and pantry management app that tracks what's actually in your kitchen using voice input, barcode scanning, and receipt parsing — instead of manual data entry. Say "used two cups of flour" and inventory updates instantly. Photograph a receipt and a whole grocery run gets logged. Run low on something and it lands on the shopping list automatically.

I ran this as a solo build, but deliberately structured it through the design thinking process rather than jumping straight to screens. That discipline is what surfaced three major pivots — each one a return to Empathize or Define after new evidence, not a restart from scratch. This case study walks through the project stage by stage, including the parts that didn't survive contact with reality.

01 · Empathize

Goal · Understand who this is for and where existing solutions actually break.

I'm the primary user — this started as a personal problem, not a market brief — but I treated that as a starting hypothesis to interrogate, not a shortcut past research. The empathize phase was built around two tracks:

02 · Define

Goal · Turn the empathize-phase findings into a sharp, human-centered problem statement.

That statement did real work — it ruled things out as much as it pointed things in. "Just build a good inventory list app" was never on the table: dozens of apps already do that competently, and they still fail at retention. The core need isn't storage or organization, it's near-zero-friction logging.

03 · Ideate

Goal · Explore the solution space widely before committing to scope.

The ideation phase produced a genuinely ambitious concept: a multi-household, cross-platform consumer product. I pushed the idea as far as it could go before applying any constraint, because scoping down from an over-built idea is a more honest process than scoping up from a timid one.

The Home screen, three very different ways

Before converging on a direction, I pushed three genuinely different visual personalities for the same Home screen — same data, three different theories of what the app should feel like.

"Stocked Pantry" — dark, moody, photography-heavy

Looked expensive, read as a developer tool or a wine-cellar app, not a kitchen. Too cold for something meant to live next to a stove.

"Pantry Pop!" — bright, mascot-driven, emoji alerts

This one quietly broke my own design principle: I'd explicitly ruled out "playful like a food-delivery app" back in Define, and here I was reinventing it from a different angle. A principle only works if new ideas actually get checked against it — this is the check catching something.

"Provisions Ledger" — serif type, formal rows, small caps

Elegant, but it read as a spreadsheet wearing a nice font — the opposite of "unhurried kitchen drawer."

The signature pattern that survived from here on: a colored indicator per item tied to its computed health score, so the whole pantry's composition is scannable without opening anything.

04 · Prototype

Goal · Make the idea tangible enough to pressure-test — and here, "prototype" meant more than wireframes; it meant building working scoped versions and finding out which assumptions held.

I treated the full-platform concept from Ideate as a paper prototype for feasibility, not a build target, and it failed the test fast: a backend to run and pay for indefinitely, multi-user auth solving a problem I didn't have, and four separate API integrations before validating whether the core loop worked for even one person. So I prototyped down, in two rounds:

I also prototyped the trust mechanism that makes AI-assisted logging usable at all: every model-driven action — barcode match, voice parse, receipt scan — surfaces a confirmation screen before anything commits to the data model. Low-confidence results get flagged amber with inline edit, never a silent guess. This one pattern repeats across four different entry points because it's the actual answer to "how do you trust an app that's writing to your inventory based on a transcription."

05 · Test

Goal · Put the thing in front of reality and let the results change the design.

Testing here has run in two forms so far, with a third planned before public launch.

06 · What this project demonstrates

1. 01

   A real Empathize → Define cycle

   Not a skipped step — the problem statement (friction kills accuracy, not storage quality) is what ruled out "just build a nicer list app" and pointed at voice as the core mechanism.

2. 02

   Ideation disciplined by scope

   Not abandoned by it — the ambitious platform concept wasn't wasted; its visual system and IA held, while its infrastructure got cut for a solo build.

3. 03

   Prototypes cheap enough to be wrong twice

   The protocol-based AI architecture meant two full engine reversals cost an interface change, not a rewrite.

4. 04

   Pre-registered tests

   Not retrospective justification — the on-device promotion bar and the API-key security gate were both written down before the code that would be judged against them.

5. 05

   Ownership of the whole loop

   Research framing, problem definition, IA, visual system, and technical architecture were one continuous set of decisions, made and lived with, with no team to hand the hard tradeoffs to.

This case study covers the design and product-strategy work behind Vesta as of October 2026. The product is under active development; screens shown are from the in-progress Figma file and reflect the current build, not a final shipped state.