← All work
Recipe Fox

Recipe Fox

Home cooks waste time fighting recipe content designed for SEO and social media, not for cooking. Recipe Fox strips recipes from any web page or social video and presents just the ingredients and steps — clean, distraction-free, built for a kitchen screen.

Role Solo designer, developer & product owner
Platform iOS · Android
Year 2026
Status Live
Recipe list
Recipe detail
Cook Mode

Context

Recipe Fox is an app that saves recipes from the web and social media, strips away all the noise, and presents them in a clean, kitchen-friendly format. The idea came from a personal frustration: every time I wanted to cook something I found online, I was fighting the content to get to the actual recipe.

Problem framing

People who cook at home rely on recipes from the web and social media. Existing solutions fail in predictable ways:

The core need: extract only what a cook actually needs — ingredients and steps — and present it in a format designed for a kitchen setting.

Existing dedicated recipe apps existed, which I saw as validation rather than a threat. The market had a proven need. My challenge was finding a meaningful differentiator.

My role

Solo project from concept to App Store. I owned every design decision: problem framing, information architecture, UI design, and implementation. My process was non-traditional — rather than producing Figma files and formal research deliverables, I worked from a clear mental model of the problem and used AI tooling to accelerate execution. Every product and design decision was mine.

Key design decisions

01

Radical scope restriction

I chose to do one thing — save and display recipes — instead of adding shopping lists, meal planning, and social features like competing apps.

Every competitor I looked at was bloated. Adding features hadn't improved the core experience — it had diluted it. If the recipe reading experience wasn't excellent, nothing else mattered. Cutting scope was a design decision, not a resource constraint.

02

One-time purchase over subscription

I chose a one-time Pro unlock instead of a subscription model.

Subscription fatigue is real, and most competing apps charge monthly. As an indie project without pressure to generate recurring revenue, I could offer something users actually prefer. It also served as a demand signal: if people pay once, the core value proposition is proven. A subscription can come later, once the product has earned it.

03

Cook Mode — one step at a time

I chose to build a dedicated Cook Mode that shows one step at a time, rather than displaying the full recipe as a single scrollable page.

I mapped the full user journey — finding a recipe, saving it, then actually cooking it — and the cooking context has completely different needs than browsing. A scrollable page requires constant interaction with hands that are busy, wet, or messy. Breaking it into sequential steps removes that friction and lets the cook focus entirely on what they need to do right now.

04

Share extension over copy-paste

I shipped v1 with URL paste as the import method, then added a native share extension.

The paste flow required 7+ steps: tap share, copy link, switch apps, tap add, tap input field, paste, save. The share extension collapses that to two: tap share, tap Recipe Fox. Same outcome, a fraction of the friction. Reducing import friction directly impacts whether users actually build a recipe library or abandon the habit after a few saves.

Outcome

Recipe Fox launched on iOS and Android. Within the first month: 200+ sign-ups, averaging 3.5 recipes saved per user — with no paid marketing. The engagement metric matters more than download numbers at this stage: users aren't just downloading and forgetting, they're using the core loop.

Reflection

Two things I'd do differently.

First: slow down on shipping. Early on I was pushing releases fast — excited by how quickly an idea could become a feature. In hindsight, that energy was better spent on clarity than velocity. Not every idea needed to ship in week two.

Second: start with distribution, not the product. The hardest problem isn't building something that works — it's finding the people who need it and convincing them to try it. I'd approach it differently now: build an audience before launch. Waitlist, content, community. Get momentum before the app exists.

The surprise was how invisible a well-built app can be without a growth strategy. The product doing exactly what you imagined is a great feeling. But it only matters when other people find it.