They asked me to redesign a meal page. I built the machine underneath it.

How it started

Chefs cook in your home and people love it. Then they open the app.

The in-person experience was the whole company. The product around it wasn't close. The founder came from marketing, one engineer held the entire codebase, and product had no owner. I came in Q1 2026 to be that owner, brought a product designer from my studio, and started by auditing everything a customer touches. By Q2 the team was smaller. Marketing had left, my designer had rolled off, and what shipped after that shipped with four people on it.

Q2

The menu was eating whole weeks

On paper, Q2 was a marketing site. Probably Framer. But the meal page wasn't the problem. Every menu update crawled through a Rails dev cycle, and a seasonal menu cost the founder weeks of manual work. A prettier page wouldn't touch that. So I pitched the machine instead: the menu as structured data in Sanity, a Next.js front end on Vercel, and every future surface inheriting both. They said yes. Everything below this line comes from that yes.

The menu

630 dishes, modeled once, reused everywhere

Every dish became structured data. 1,073 ingredients carrying nutrition profiles in a relational graph, macros that derive instead of getting typed in, 45 health labels that fire against clinical thresholds. Add a dish and it inherits all of it. A menu drop went from weeks of manual work to a day or two, and every dish page came out the other side as a landing page, shareable and indexable on its own.

Demand

Four ways in. One vocabulary.

With the menu as a base, the site fanned out. Four ways people actually arrive: a search, a neighborhood, an identity, a partner. All of them generated from the same tagged data, about 160 pages in total. But a lander that drops you into generic signup wastes the click. So every identity lander, all 24 of them, hands off to its own onboarding written to that person's real problem. Someone landing on diabetic meal delivery gets asked about diabetes, not about their zip code.

Supply

The recipe engine

The doors outpaced the catalog. 160 pages want more than the kitchen can write recipes for, and nobody writes at lander speed. So I built the tool nobody asked for. Describe a dish in plain language and it comes back a chef can actually cook: recipe, computed nutrition, and menu copy, all verified before it can publish. It feeds the internal menu tool, the customer plan AI, and the landers from one source.

doesn't ship

Brief

plain language

Generate

recipe + nutrition + copy

Verify

checked against the goal

Publish

chef-ready

“Marathon training, mostly plant-based, kid only eats mild food.”

Charred Lamb Kebabs

Lamb kebabs · Whipped hummus · Cucumber salad & rice

44g proteinGluten-freeHigh-protein

High-protein

Charred Lamb Kebabs

Whipped hummus, rice & cucumber salad.

“Marathon training, mostly plant-based, kid only eats mild food.”

Charred Lamb Kebabs

Lamb kebabs · Whipped hummus · Cucumber salad & rice

44g proteinGluten-freeHigh-protein

High-protein

Charred Lamb Kebabs

Whipped hummus, rice & cucumber salad.

Expand

The foundation

They said no to my stack twice

My first question on day one was whether I could ship React. No. Rails, and a contract dev shop. So we did it the traditional way: design in Figma, buy dev seats, hand it over. Features took 30 to 90 days, and most of that was waiting. I pitched Next.js again when we took the menu to existing customers. No again. That's when I stopped asking. The React system I'd been building since Q1 compiles to livin-tokens.css and standalone HTML, and HTML drops into Rails without touching their stack. Now an idea on Monday can be a working prototype by Friday.

In numbers

Numbers as of July 2026.

Odds and ends

A few other things I made

A few things that didn't fit anywhere above, and are worth looking at anyway.

The meal page shipped, fast. So did the machine around it. Four people move like a department now, because the system underneath them compounds. The menu feeds the landers, the landers open onto onboarding built for that exact person, the recipe engine keeps the catalog ahead of both, and design leaves my hands as working code. That's the work I want to keep doing. Find the bottleneck under the ask, then build the thing that removes it for good.