Hardi Jain · AI and SaaS product manager

Building Pantry Vault, a pantry app for vegetarian kitchens

Indian households throw away about 55 kg of food per person every year. I wanted to find out whether one product manager, with AI tools and no engineer, could build something that stops some of it, and ship it to a live URL.

01 · CONTEXT AND ROLE

A personal project. I was the PM and the builder.

I wanted to test a question for myself: how far can a product manager get with AI tools alone? I picked a problem from my own kitchen so I could be the first user.

I decided what to build, wrote every spec and prompt, reviewed and tested everything that came back, and ran the launch. I wrote no code by hand.

02 · THE PROBLEM

Food goes off in the fridge while we order in.

UNEP’s Food Waste Index 2024 puts household food waste in India at about 55 kg per person a year, 78 million tonnes in total. Globally, households cause 60% of all food waste.

In my kitchen it looks like this: paneer and curd forgotten at the back of the fridge, spinach wilting before anyone cooks it, dal running out on a Wednesday night. Pantry apps exist, but nobody keeps them up to date, because typing in every grocery item is a chore.

Source: UNEP Food Waste Index Report 2024

03 · THE INSIGHT

The hard part is keeping the pantry up to date.

A pantry app is only useful if it knows what’s in the kitchen. The moment people stop updating it, every feature built on top gives wrong answers: expiry warnings, recipes, the shopping list.

So the product has to make adding groceries almost effortless, and everything else has to serve one loop: know what you have, cook what’s about to go off, restock what’s run out.

04 · THE SOLUTION

Four features, all serving that loop.

Scan a bill or order screenshot. A photo of a shop bill or a Zepto or Blinkit screenshot becomes a pantry list, with quantities and a use-by date for each item. You check the list before anything is saved.

Pantry with expiry warnings. What’s expiring this week sits at the top.

Recipes from the pantry. Tick what you want to use up and get two vegetarian recipes that follow your food habit, including Jain and vegan rules.

Shopping list on WhatsApp. Items running low become a message for your family or your cook. Voice input takes a recipe dictated in Hindi or any other language and returns it in English.

05 · HOW I BUILT IT (NO-CODE)

A prompt, then a coding agent I directed.

I described the app in plain English to Google AI Studio and got a working React prototype the same afternoon. It had eight tabs and looked finished.

Then I read what it actually did. Everything was saved in one browser, the community feed only showed my own posts, the “automated” WhatsApp alert was just a pop-up, and the recipe-link analyser never opened the link. I cut it down to the four features above and moved to an AI coding agent (Claude) to build the real product: sign-in, a database, a server that keeps the AI keys private, and hosting.

Every change followed the same routine: I wrote what it had to do, the agent built it, and I tested it on the live site before moving on.

06 · KEY DECISIONS AND TRADEOFFS

What I chose, and what it cost.

Removed health advice. The prototype gave diabetes and PCOS “verdicts” from AI-guessed nutrition. It was the most impressive-looking feature, and I cut it. Wrong health advice is worse than none.

Review before saving. Bill scans show a list you check first. One extra tap, in exchange for no wrong items in the pantry.

Email sign-in link, no passwords or SMS. Free and quick to set up. SMS codes in India need sender registration and cost money per message.

Free AI tiers with a fallback. No budget for a paid API, so the app switches providers when one is busy. Answers can vary slightly in quality between providers.

Payment by UPI, flipped by hand. No payment gateway until people show they’ll pay.

07 · CHALLENGES I SOLVED

Four things that broke, and the fix for each.

The app worked here and crashed live. Every AI request failed on Vercel with a blank error. The live server needed file references written differently than my test setup. Found by recreating Vercel’s conditions locally.

“This model is experiencing high demand.” Google’s free tier turned requests away. The app now retries, then tries Groq, then OpenRouter.

A button that did nothing. After a few failed attempts the browser had quietly started blocking the app’s pop-up errors. Errors now appear inside the app.

Sign-in emails that only reached me. The database’s built-in email sender is a test service. Real households need a proper sending service on my own domain.

08 · IMPACT AND WHAT I’D MEASURE

Live, and so far I’m the only user.

There are no user numbers to report yet. What exists: a live app that installs on a phone, with accounts, a private database per household, a cap of 30 AI requests a day per person, and the four features above.

Next is a test with 10 to 20 households. The number I care most about is how many are still updating their pantry after week one, because that’s the insight from section 03 being tested. After that: how many recipes get cooked, how often an expiry warning leads to the item being used, and whether anyone pays after a 14-day trial.

Live app (sign-in by invite) · Code on GitHub

09 · REFLECTION

AI gets you a demo in an afternoon. The product is everything after.

The prototype took hours. Making it safe for someone else’s data took days: who can see what, what each request costs, what happens when a free service says no, and what the user sees when something fails.

Two things I’d do differently. I’d read what the first version actually does on day one, before admiring what it looks like. And I’d test on the real hosting from the first change, not after the fifth.

10 · SKILLS

What this project shows.

Product: framing a problem with data, cutting scope to one loop, choosing the metric that tests the core assumption.

Working with AI: writing specs an AI can build from, reviewing its output instead of trusting it, knowing when a prototype is hiding fake features.

Enough technical depth to run a build: sign-in and per-user data, keeping API keys on the server, usage limits, provider fallback, reading error logs to find a root cause.

Judgment: removing a feature that looked good but could cause harm, and being plain about what’s live and what isn’t.

Next story

Contact me

Connecting the dots

“You can’t connect the dots looking forward; you can only connect them looking backward.”

— Steve Jobs