I abandoned my iOS app. Then I rebuilt it from scratch with a real method.

The painful realisation

A few months earlier, I had launched Caffio, an app to track your coffee consumption and explore recipes. Built in a week, riding the excitement around the FoundationModels framework announced at WWDC 2025. Local AI, directly on the iPhone, no cloud connection. Technically thrilling.

Except I had stopped using it. Not because of bugs, but because it solved no real problem. Scrolling through my own screenshots, the truth hit: I had built a technical demo dressed up as a product.

That kind of realisation stings, but it is also the best place to start. So I rebuilt everything from scratch, this time with a rigorous methodology. Here are the 8 steps of that process, documented in real time.

Step 1: Step back honestly

Before touching a single line of code, I forced myself to answer three core questions.

What does the app uniquely do? Not "it lets you log coffees" (any notes app does that), but what does it bring that no other product offers in exactly that way?

Would I still use it in six months? Not in the high of building it, not to impress people around me, but in my daily routine, six months later?

Is it an app, or just a feature? Sometimes what you are building deserves to live inside something larger rather than alone on the App Store.

The answers were brutally clear. The first: blurry. The second: no. The third: uncertain. The signal was obvious: start from the problem, not the solution.

Step 2: Pick a precise audience

The classic mistake of a developer building for themselves is to assume the audience is "coffee lovers". In other words, everyone, which means no one.

I identified four potential profiles: the pro barista, the person watching their caffeine intake for health reasons, the enthusiast who wants a tasting journal, and the curious one exploring recipes. Four radically different behaviours that call for four different apps.

Choosing your audience means accepting you will not please everyone. It is uncomfortable, but it is the only way to actually serve someone instead of vaguely satisfying a wide crowd.

Step 3: Validate needs with real people

Intuition gives you a starting point. Data gives you a direction.

I built a custom form with Next.js and MongoDB, then shared it on Instagram, Reddit and LinkedIn. The goal was not to gather thousands of answers but to gather quality ones.

16 people responded. That is not a statistically significant sample, sure. But 16 people who precisely describe their frustrations around their coffee routine is infinitely more useful than 1000 clicks on a sloppy form.

The main finding: people forget what worked. They take notes on paper, in voice memos, in their head, and they almost never find them at the right moment.

The real problem was not "I want a coffee app", it was "I keep repeating the same mistakes because I have no system to remember what works".

Step 4: Build a persona as a compass

Feeding the form responses and my ideal target into Claude Code, he helped me create Léa.

Léa, 28, freelance designer, self-taught coffee enthusiast. She discovered the V60 on YouTube, invested in a good grinder, and is actively exploring. Her core frustration: she cannot remember her ratios, temperatures, or what made one cup feel exceptional on a Tuesday morning three weeks earlier.

Léa is not real, but she embodies a behaviour validated by the survey data. With a persona, every design decision becomes concrete: would Léa use this feature? No more "is it a good idea?" or "is it doable?", just: would Léa, in her daily life, open this feature?

Step 5: Prioritise features with MoSCoW

The MoSCoW (Must have, Should have, Could have, Won't have) method is both radical and indispensable. Radical because it forces you to reject ideas. Indispensable because without it, the backlog becomes infinite and the MVP never ships.

The survey data spoke for itself: 100% of respondents wanted caffeine tracking, 79% statistics, 64% tasting notes, and only 21% a social or community angle.

• Must have: caffeine tracking, statistics, tasting notes
• Won't have: anything social

For each feature kept, one final filter: would Léa use it during her first week? Not in six months, in the first seven days. That single criterion eliminates a lot of features that look important but are not for an MVP.

Step 6: Structure the brief before using AI

This is the step most people skip when working with AI. They open Claude and improvise the context as the conversation goes. Then they are disappointed by generic results.

A language model cannot guess what you already know. It works strictly with what you give it.

I prepared a structured document in five parts: the application context, the Léa persona with her precise frustrations, MoSCoW-prioritised features, technical constraints (iOS 18+, SwiftUI only, no backend for the MVP), and most importantly what we do not want. That last point is underrated: explicitly saying "no long onboarding" or "no side features that dilute the core" saves a lot of round-trips.

I also created a CLAUDE.md file at the project root. It is a Claude Code convention: this file is read at every session, which avoids repeating the context every time you sit back down.

Step 7: Iterate with Claude Code

Many people use AI as a plain code generator. You describe what you want, you copy-paste, you hope it compiles. That is not the right approach.

My workflow ended up in three phases.

Foundations first: ask Claude to scaffold the app skeleton (architecture, navigation, data models) without any actual feature. The goal is something that compiles and has a healthy structure before adding complexity.

Feature by feature next, in must-have order. For each one, the loop: describe the goal precisely, let Claude implement, review the code yourself, test on simulator or real device. Never two features in parallel.

Finally, ping-pong: challenge the AI. "Why this architectural choice?", "Is there a better approach for this case?", "What edge cases have we missed?". That is where collaboration becomes truly productive: not by accepting whatever lands, but by questioning.

Step 8: The functional MVP

At the end of the process, I had a working app. Not perfect, not App Store-ready, but enough to validate the hypotheses: is the tasting note flow natural? Are the statistics legible? Could someone like Léa use this without a manual?

That is what an MVP is. Not version 1.0, not something you are 100% proud of. A tool that lets you find out whether you are building in the right direction before pouring six more months in.

The difference between Caffio v1 and v2 is not code quality. It is the clarity of intent behind every feature.

What I take away

You hear a lot about "shipping fast" in indie dev culture. It is a valid principle, often misread. Shipping fast does not mean coding without thinking. It means shrinking the gap between a hypothesis and its validation.

The 8 steps described here do not slow development down. They cut out useless work. The survey, the persona, the structured brief: a few hours that save weeks of code on features no one will use.

As for AI, it is precious. Claude Code saved me considerable time on implementation. But that time is only worth it if what you implement deserves to be built. The real work (understanding the problem, picking your audience, prioritising) cannot be outsourced to a language model.

AI accelerates execution. But it does not replace vision.