Building Pantry Burn: a food waste app that refuses to become a recipe app

Pantry Burn came from a boring problem that happens constantly: buying food with good intentions, then forgetting about it until it is already bad. I have used grocery apps, shopping lists, and recipe apps. None of them really solve that part.

The missing piece is not meal inspiration. It is recall under time pressure. You open the fridge, you need a fast answer, and you want the app to tell you what is becoming urgent right now. That became the entire shape of Pantry Burn.

The product boundary

The most important decision was what not to build.

I did not want Pantry Burn to become:

• a grocery list manager
• a meal planner
• a recipe recommendation engine
• a barcode scanning project

Those are all valid products, but each one pulls attention away from the problem I actually cared about. Pantry Burn is about expiry awareness. If the home screen cannot answer “what should I use first?” in a second or two, the app is failing.

That is why the landing page and the app copy both keep returning to the same framing: use-first ranking, not content overload.

Building the urgency engine first

The first real architecture decision was to make urgency calculation a pure module instead of scattering date logic across screens.

That logic now lives in a dedicated utility layer:

• parse the saved date-only value
• normalize both dates to the start of the local day
• compute days remaining
• map that number into expired, urgent, soon, or fresh

This sounds small, but it matters. Date handling gets messy quickly, especially when you accidentally store timestamps for a problem that is really about calendar days. Using date-only strings reduced a whole class of timezone bugs and made the ranking rules easier to reason about.

Once that module existed, the rest of the app became simpler. The home screen, item detail, search filters, and notification copy all pull from the same urgency model.

Why the app is local-first

Pantry Burn stores items and settings in AsyncStorage. That was a deliberate product choice, not just an engineering shortcut.

Food inventory is personal, lightweight, and highly local. Adding accounts would introduce signup friction, sync complexity, and failure modes that do not create meaningful value for the first version. If the app opens instantly and works offline, it is already doing the most important part of the job.

The same logic shaped notifications. Rather than building a remote reminder system, I used Expo Notifications to schedule alerts on device. Settings determine how many days before expiry to notify and at what time, and changing those settings triggers a full local reschedule. Nothing depends on a server being alive.

The flow I cared about most

The key flow was not item creation by itself. It was reducing the number of steps between noticing something and recording it.

That is why the add screen is intentionally compact:

• name
• expiry date
• optional replacement selection

The replacement flow ended up being more important than I expected. If you buy the same item again, you often do not want a duplicate row. You want to refresh the existing one. Building that into the form made the app feel more aligned with how people actually restock food.

Organizing the home screen around action

I did not want a flat list with a lot of decoration. I wanted the home screen to function like triage.

So the items are sorted by urgency first, then split into sections:

• Use first
• All good

Search and filters sit on top of that, but they do not replace it. That was an intentional UI choice. The structure of the screen should reflect the main decision the app is helping you make, not just display stored records.

Theme, tone, and why it does not look like a utility clone

Pantry Burn uses a warmer palette than a lot of mobile utilities. I wanted it to feel domestic rather than clinical. Food waste is a practical issue, but it is tied to routines, kitchens, and everyday habits. The tone needed to feel useful without looking like an enterprise inventory scanner.

That also influenced the copy. I kept the language direct and ordinary. No nutrition dashboards, no “AI meal optimization,” no fake smartness. Just urgency, reminders, and recall.

What I learned from building it

The biggest lesson was that scope discipline creates product clarity.

It is easy to imagine an expanded version of Pantry Burn with recipes, barcode lookup, shared household syncing, and purchase history. Maybe some of that belongs later. But the shipped version works because it does one thing cleanly: it helps you stop forgetting what you already bought.

That is the standard I wanted for the app. Not bigger. Just sharper.