Why I built it

I built My Head Chef as an independent product, not a client engagement.

The starting point was a simple consumer problem: most recipe apps give you a giant archive when what you actually need is one useful answer. When someone is standing in front of a refrigerator at 6:00 PM, tired and hungry, search is often friction disguised as choice.

I wanted to test whether AI could close the gap between “what I have” and “what can I make right now” without turning the experience into another bloated subscription app.

For my work, this matters less as a hospitality case study and more as proof that I can conceive, build, ship, and keep improving a real consumer product end to end.

What I built

My Head Chef is a mobile assistant designed to reduce the decision load around cooking.

Generative Recipes: Instead of searching a static database, the app uses Google Gemini to generate custom recipes on the fly. You tell the app what ingredients you have and any dietary restrictions, and it builds a formatted, coherent recipe in seconds.
SousBot – Your Voice-Guided Assistant: Cooking is a hands-on activity. To solve the problem of “flour-covered fingers on a glass screen,” I developed SousBot. It’s a witty, confident AI persona that reads instructions aloud and responds to voice commands like “SousBot, next step,” allowing for a completely hands-free experience.
Smart Automation: The app automatically translates recipes into categorized shopping lists, syncing across devices so the transition from planning to shopping is seamless.

What it demonstrates

This project shows a few things that are relevant to prospective clients, even though it is not client work:

Product judgment: I can define the problem, set the scope, and decide what belongs in the product versus what is noise.
Technical execution: I can ship a live mobile app across iOS and Android, maintain it, and evolve the architecture as the product changes.
Real-world operations: I have dealt with the messy parts of app ownership too, not just the exciting launch phase.

What I changed after launch

In its early stages, My Head Chef followed the standard mobile playbook: freemium pricing, banner ads, in-app purchases, and the usual stack of monetization baggage. Over time, that made the product worse.

The compliance overhead, tracking SDKs, and monetization logic started to compete with the actual utility of the app. That friction did not just slow development down. It made the product feel less honest.

So in early 2026, I stripped it back:

Deleted the Bloat: I removed thousands of lines of code related to ad-serving and complex tracking.
Performance First: Without external tracking SDKs, the app became faster, lighter, and more reliable.
The “Cup of Coffee” Model: I replaced the paywalls and ads with a simple, voluntary donation model. Every feature—from cloud backup to SousBot’s premium voices—is now free for everyone.

That decision reflects how I prefer to build systems in general: make the useful thing work well, remove unnecessary operational drag, and avoid complexity that only exists to serve the software instead of the user.

Where it fits in my portfolio

I do not treat My Head Chef as evidence that I have solved winery membership, CRM, or tasting room operations for a client. It does not answer that question, and I do not present it that way.

What it does show is that I am a builder, not just a strategist. I can take an idea from concept to live product, make hard calls about scope and architecture, and keep the thing running after launch. That is supporting evidence, not the lead case.

Project Specs

Platform: iOS & Android (React Native & Expo)
Intelligence: Google Gemini via Azure Functions
Voice: Azure Cognitive Services
Development Philosophy: Builder-led, utility-first, ad-free.

My Head Chef