I Built an AI Recipe App, Got Apple's Approval, and Never Published It.

I spent months building an iOS app. I designed it, coded it, tested it with friends, submitted it to App Store review, and got approved.

Then I closed my laptop and never hit publish.

Sound dramatic? Maybe. But here's the thing: knowing when to stop is a skill nobody talks about. Especially when you've already invested hundreds of hours into something that actually works.

The Fridge That Started Everything

It started the way most side projects start. With a stupid, simple problem.

I opened my fridge, saw a bunch of random ingredients, and had no idea what to cook. Tomatoes, some leftover chicken, half a cucumber, yogurt. All perfectly fine stuff. But my brain just went blank.

And then the thought hit me: what if I just take a photo of what's in my fridge, and an AI tells me what I can make with it?

That's it. That was the whole idea.

I bought the domain wunderchef.ai the same day. If you know me, you know I have a thing for the word "wunder." My company is Wunderlandmedia. My macOS app is WunderType. My German learning app is DeutschWunder. At this point it's basically a branding addiction.

The concept was clear: snap a photo of your ingredients, AI recognizes what you have, generates recipes based on what's actually in front of you. No scrolling through recipe blogs. No "you'll also need 17 ingredients you don't have." Just use what you've got.

I also wanted to track the environmental impact. Every recipe you generate shows how much food waste you prevented, how much money you saved. A collective impact dashboard across all users. Because the whole point was reducing waste, not just convenience.

The Stack Behind the Scenes

This is where it gets technical. If you're not into code, skip to the next section. If you are, buckle up.

My initial architecture was SwiftUI for the iOS app, Directus as the backend CMS, and a Next.js app for the server-side AI components. The idea was to handle image recognition and recipe generation through Next.js server actions.

It worked. But it was painfully slow.

The bottleneck was the Next.js endpoint. Sending a base64-encoded image to GPT-4o-mini for ingredient recognition, then generating structured recipes with a second call, all through Next.js server actions, that pipeline was just too sluggish for a mobile app. Users don't wait 15 seconds staring at a loading screen.

So I ripped out Next.js for the API layer and rebuilt everything as a standalone Express.js API with TypeScript. Night and day difference. Build time dropped to 30 seconds on Coolify with Docker. AI responses were significantly faster.

Here's what the final stack looked like:

• iOS App: SwiftUI with modern async/await patterns, custom environment-based dependency injection, Keychain token storage with proactive 5-minute refresh buffer
• Backend API: Express.js (v5) + TypeScript, Zod validation, Helmet security headers, structured error handling with domain-specific error classes
• AI Engine: OpenAI GPT-4o-mini with structured JSON output mode. Image recognition uses base64 JPEG at low detail for speed. Recipe generation includes a professional chef system prompt with dietary restriction handling, allergy safety ("MUST AVOID" emphasis), and sustainability metric calculations
• CMS: Directus for user data, recipes, credits, transactions. The Express API handles writes, Directus handles reads directly from the iOS app
• Auth: Apple Sign-In with full JWKS verification. The Express server fetches Apple's public keys, verifies the RS256 signature, validates the audience against the bundle ID. Then creates or updates the user in Directus with a cryptographically random password
• Payments: StoreKit 2 with JWS transaction verification. Four credit packages from $9.99 to $99.99. Server-side validation before crediting
• Languages: 55+ languages supported in recipe generation. The iOS app itself supports 5 languages with dynamic switching

I learned a lot building this. Base64 image size directly impacts recognition model costs. Compression matters: the app uses a loop that starts at 0.85 quality and reduces by 0.05 increments until the image is under 1MB, while rejecting anything under 1KB as over-compressed.

I also built prompt injection protection into the API. Input sanitization that blocks patterns like "ignore previous instructions" or "system:" before they reach the AI. When you're generating food recipes, you really don't want someone tricking the model into suggesting dangerous combinations.

One thing I couldn't get working with my original Next.js setup was Apple Sign-In with Directus. I read all of their documentation. Twice. I just wasn't understanding the token exchange flow. Moving to Express with the jose and jwks-rsa libraries made it click. Sometimes the problem isn't the concept, it's the tool.

It Actually Worked

Here's the part that makes this story harder to tell.

The app was good. Like, genuinely good.

I built proper onboarding. Language selection first, then a clean home screen with quick actions. Generate a recipe, browse saved ones, discover what others are cooking. A profile page with your credits, stats, and settings.

The credit system worked. Buy credits through StoreKit, spend them generating recipes. Image analysis was free to encourage usage. Each recipe generation cost one credit and tracked your sustainability impact: waste reduced in kilograms, money saved in dollars, ingredients used.

The collective impact dashboard showed community-wide stats. Thousands of kilograms of waste reduced, thousands of dollars saved, tens of thousands of ingredients used. It made people feel like they were part of something.

I had friends test it. They opened their fridges, snapped photos, and the app identified their ingredients and suggested recipes. Turkish chicken sausage with tomatoes. Mediterranean chickpea salad. Grape and yogurt parfait with chocolate drizzle. Real recipes with prep times, difficulty levels, and step-by-step instructions.

I created workflows, wrote tests, polished the UI. The Next.js landing page for wunderchef.ai was done. The logo was clean. The color scheme, a warm dark theme with orange accents, felt premium.

On August 26, 2025, I submitted the app to Apple's review process.

It got accepted.

I never published it.

Four Reasons I Never Hit Publish

So you might be asking: all this work, all this time, and you just... didn't?

Fair question. Here's the honest answer.

Maintenance Is Not a Part-Time Job

I run a one-person agency. I build software for clients. I maintain two live apps already. I know exactly what maintenance means for a solo developer.

An AI recipe app isn't a "set it and forget it" product. OpenAI changes their API. Apple updates StoreKit requirements. Users find edge cases. Someone's allergies aren't handled correctly. The Directus backend needs updating. The Express server needs security patches.

I know I wouldn't be able to maintain this project to the fullest of my capabilities. And here's where I differ from a lot of indie hackers: I will never understand how people push 100 apps and claim to support their users. Either they don't actually care about the people using their software, or my ethics don't allow for that kind of operation.

I cannot maintain this app and provide proper support while also serving my clients. It's not the way I do business.

EU Regulations and Recipe Liability

This one kept me up at night. I'm based in Germany. In the EU. I'm building an app that uses AI to generate cooking instructions.

What if a recipe makes someone sick? What if the AI hallucinates an ingredient that someone is allergic to, despite the safety prompts? What if someone follows the instructions and something goes wrong?

I built allergy handling with "MUST AVOID" emphasis in the prompts. I built dietary restriction filters. But AI is probabilistic. It's not deterministic. And I don't have a lawyer on speed dial.

In Europe, providing AI-generated guidance that people physically consume is a liability minefield I'm not equipped to navigate as a one-person operation.

The AI Slop Problem

If I had published in August 2025, maybe I could have carved out a niche. But since then, something shifted.

Everyone's building an app now. Claude Code got really good. People are vibe coding 10-20 apps and pushing them to the App Store without a second thought. The store is flooded with AI-generated apps that all look the same, do the same thing, and have no long-term support behind them.

My app would get lumped in with the slop. It's much harder to justify that WunderChef is a carefully built, thoughtfully designed product when the App Store is drowning in overnight clones. The signal-to-noise ratio has collapsed.

Must-Have vs. Nice-to-Have

This is the one that really got me.

WunderChef is a nice idea. Don't waste food. Use what you have. See your environmental impact. All great.

But is it a must-have? Is it an app that solves a genuine, daily problem that people can't solve by, you know, just Googling "chicken tomato yogurt recipe"?

I have doubts. It's a nice-to-have. And nice-to-have apps die slow, painful deaths of declining engagement and guilt-inducing push notifications.

Knowing When to Stop

There's a Turkish proverb I think about a lot: Kervan yolda düzülür. The caravan gets organized on the road. You figure things out as you go.

But sometimes the caravan needs to stop.

I learned a ton building WunderChef. Base64 image optimization. StoreKit 2 transaction flows. Apple Sign-In JWKS verification. Express API architecture. SwiftUI dependency injection patterns. Security considerations I wouldn't have thought about otherwise, like prompt injection protection for AI endpoints.

None of that knowledge is wasted. It's already making me better at client work.

But the app itself? It sits on my machine, approved by Apple, fully functional, never seen by the public. And I'm okay with that.

At the end of the day, we need to be honest with ourselves and know where to stop. Not every project needs to ship. Not every idea needs to become a product. Sometimes the building is the point.

I'm not going to pretend this was some grand strategic decision. Part of me is just scared. Scared of the maintenance burden, scared of the liability, scared of launching into a market that's already drowning in AI apps. Maybe I'm using those concerns as excuses.

I don't have a neat answer for that one.

What I do know: I'd rather have one app I never published than ten apps I can't support.

If you're building something and wondering whether to ship it or shelve it, I can't tell you the right answer. But I can tell you this: quitting isn't always failing. Sometimes it's just being honest about what you can actually sustain.

Thinking about building something and want a second opinion before you invest months? Let's talk. I've been on both sides of the "should I build this" conversation.