MealPlan

Three screens: tell it your budget, get an honest week, shop once. That's the whole product. The hard part was making honest mean something. Everything above is real output from the live app.

THE INSIGHT

The reframe that built the whole product

By law, the most SNAP can pay a household is the cost of one nutritious week - the USDA Thrifty Food Plan. So most people start at or below the floor. "Budget too low" isn't the edge case, it's the normal one. Once I saw that, the job changed: stop pretending an impossible budget works, and build the shortfall in instead.

CUSTOMER DISCOVERY

I checked the assumption before we built on it

I ran a survey before we designed a screen. People wanted cheap and nutritious, not just cheap; the core idea landed with everyone who answered; and the asks were specific - "basic everyday affordable staples," "Indian groceries." Read against public USDA and Census data, it kept resolving into two households.

THE SOLUTION

Less a recipe app, more a budget-and-nutrition engine

No account, no cost, built to run on an older Android over 3G. Under the hood it's a data problem: price a week to the budget, check it against nutrition guidelines per person per day, and keep every dietary rule in the food data so it can't be broken. Having a CS background meant I could get into that logic with the team, not just hand it over.

FOCUS

We said no to a lot, on purpose

Six days meant the real work was subtraction. Accounts, PDF export, food-swaps, sharing, barcode scanning - all cut, so one honest loop could be genuinely good instead of five things being mediocre.

WHERE IT GOT HARD

The hardest parts were judgment calls, not code

On a four-person team I owned turning messy inputs - survey signal, USDA data, a dozen opinions - into personas and requirements people could build from. That put me in the middle of the calls that were actually contested.

• A DESIGN DEBATE - THE FIRST FIVE SECONDS

  What should the landing page say before it says anything hard?

  Working through priorities as a group, we hit a real split: lead the landing page with the honest budget reality, or lead warm and save the honesty for where it's specific? I argued for the warm hook - “a whole week of meals, on the budget you actually have,” free, no account - with the shortfall landing in context on the plan view. We each pitched, talked it through, and aligned there. It's what shipped.

• A TECHNICAL CALL - RELIABILITY OVER WOW

  Live AI on stage, or a demo that couldn't break?

  Part of the team wanted live generation. With one shot at the judges, I pushed to run on prepared plans across every dietary filter - less flashy, but every combination we showed actually worked, and we could stand behind all of it.

• PRIORITIZATION - HOLDING THE LINE

  Everyone had a favorite feature. Most had to wait.

  Good ideas, nearly all cut. I kept v1 to the one loop and wrote the rest into a “next / later” roadmap so it read as a plan, not a loss. Keeping the team aligned on that while tired and behind was harder than the product work.

WHERE IT LANDED

Live, honest, shipped on time

Six days, a real working app, submitted on schedule - and the honesty survived the build: short budgets get the truth and the USDA number, not a fake plan. Next up is real interviews to replace the composite personas, then taste and cuisine preferences (our leading v1.1 bet), and the food-swaps the survey already asked for.