I've been building apps independently for over a decade, and there's a question I kept avoiding: what percentage of the apps I start do I actually finish?
Honestly? Not enough. The pattern is familiar: an idea sparks, I dive in enthusiastically, then somewhere around week three the momentum stalls. Another half-built project gets quietly archived. If you count up the folders on my local drive with half-written code sitting in them, the number is uncomfortable.
What changed recently is that I started using Claude not just to write code, but to challenge my ideas before I write any. The result has been a noticeably higher completion rate — not because my ideas suddenly got better, but because the ideas I choose to build have been through a harder filter. Here's what that looks like in practice.
Why Indie Developers Abandon Projects
The root cause isn't usually a bad idea — it's starting before the idea has been properly stress-tested.
The sequence goes like this: exciting concept arrives, coding begins immediately, two to three weeks pass, and then reality sets in. There are already a hundred similar apps in the App Store. There's no clear monetization path. The target user turns out to be mostly yourself and maybe your friends.
By that point, you've invested real effort, which makes pivoting feel expensive. You can't move forward without motivation, can't step back without feeling like you've wasted your time. So the project quietly dies.
The problem isn't that the idea was bad. It's that the idea didn't survive contact with hard questions before development started. And the hard questions are almost always ones you could have asked yourself — if you'd slowed down before reaching for the keyboard.
For solo developers, comprehensive market research before building isn't always realistic. No research team, limited hours. But there's a gap there that Claude can fill more efficiently than I expected.
Starting by Asking Claude to Tear the Idea Apart
The first time I tried this, it was almost a joke — just to see what would happen. I described an app concept to Claude and asked: "What are the weaknesses of this idea?"
The response was sharper than I expected.
"If similar apps already exist, what's your differentiation?" "If you're distributing for free, how do you plan to cover development and maintenance costs?" "What age group is your target user, and what discovery channels reach them?"
These were questions I'd nominally considered, but the excitement of a new idea tends to push them aside. Claude surfaced them calmly — not dismissively, but in the spirit of thinking through the problem together. That tone matters. It didn't feel like being lectured; it felt like talking through an idea with someone who was taking it seriously.
Since then, talking to Claude before writing code has become my default. The rule I've set for myself is: no code until the concept has survived at least one serious round of questioning. That sounds strict, but in practice it usually means one focused thirty-minute conversation before anything else.
The Three Prompts I Actually Use
After some trial and error, I've settled on three patterns that produce consistently useful output.
Pattern 1: Problem Definition Check
I'm an indie iOS developer. Please give me critical feedback on
the following app idea, specifically from the angle of whether
the problem it solves actually exists. I'd rather have honest
pushback than encouraging but vague praise.
Idea: [description]
Target user: [who]
Why I want to build this: [motivation]
The phrase "honest pushback rather than encouraging but vague praise" matters. Without it, Claude tends to be a little too supportive — which is part of its character, but at the ideation stage I want the skeptical voice more than the encouraging one. Explicitly asking for it shifts the register noticeably.
Pattern 2: Mapping Competitors and Alternatives
For this app idea, what search keywords would I use to find
similar apps in the App Store? And if there are many competitors,
what are three angles where a solo developer might realistically
differentiate?
The differentiation angles that come back from this prompt have a habit of becoming the core concept of the app. It's the most broadly useful pattern I've found, and it works across very different types of apps. The act of naming search keywords also forces clarity — it's hard to write an App Store search term for a concept that isn't specific enough.
Pattern 3: Scoping the MVP
Once a concept feels solid, I always work through the minimum viable feature set with Claude before touching any code.
The core value of this app is "[one sentence]."
Can you separate the features absolutely necessary for the first
version from the ones that would be nice to have but can wait?
Assume a solo developer working within a three-month timeline.
Stating the three-month constraint is important. Without it, the suggested feature list tends to balloon toward what the ideal version would include. The constraint forces realistic prioritization and surfaces the real core faster.
A Concrete Example That Changed My Approach
Late last year I had an idea: an app that uses AI to automatically organize travel photos into albums.
In the past, I would have started exploring PhotoKit documentation immediately. This time I ran it through Claude first.
One piece of feedback stood out: "Google Photos, Apple Photos, and Amazon Photos already offer similar functionality. If there's space for an indie developer here, it's probably in a very specific travel scenario those platforms don't handle well — something with a niche constraint they wouldn't prioritize."
That one comment shifted the concept from "AI travel photo organizer (general)" to "an app that automatically sorts photos taken across multiple devices on a backpacker trip, organized by day and location." The niche: people who travel with a phone and a camera, where the timestamps don't align and the albums end up a mess.
Narrowing the target made the technical priorities obvious. "Where does the trip itinerary data come from?" "How do we handle timestamp drift across different devices?" These became concrete engineering questions rather than vague aspirations. The result: I shipped a first version within three months. With the original, broader concept, I'm fairly sure I would have lost momentum somewhere along the way — there's no clean finish line for "organize travel photos generally."
How Claude Sharpened My Questions, Not Just My Ideas
Something I didn't expect: using Claude regularly has sharpened the way I frame questions, well beyond app ideation.
Vague questions get vague answers. "What do you think of this app?" produces nothing useful. "If this app were to fail commercially, what would be the single most likely reason?" produces something actionable.
That habit of asking specifically has transferred into other contexts — user interviews, conversations with other developers, my own internal thinking when I'm working alone. I notice now when I'm asking myself a question that's too vague to answer, and I reframe it.
I've heard the concern that relying on AI makes thinking shallower. My experience has been the opposite. The discipline of formulating questions precisely enough to get useful responses has made my product thinking clearer over time. Claude works best when you bring it a specific question — and building that habit has spillover value.
Where Claude Helps and Where It Doesn't
To be honest about the limitations:
Claude is genuinely good at decomposing vague ideas into specific questions, surfacing competitors and alternatives you might have missed, prioritizing MVP scope, and drafting user stories. It's also useful for pressure-testing the logic of a business model — "if I charge X, how many downloads do I need per month to cover hosting?" is a calculation it handles well.
Claude can't predict whether an app will actually succeed — nobody can. Its knowledge has a cutoff, so real-time App Store trends, current review guideline nuances, and recent policy changes aren't reliable information. Questions like "does this UI feel intuitive?" have structural limits when asked of a language model rather than an actual user.
The framing that works for me: Claude is a thinking partner, not a market research service. It's most valuable when you bring it a question worth thinking about together, and least valuable when you're hoping it will just confirm you're right.
For ongoing ideation work across multiple conversations, using Claude Projects to maintain context is worth setting up. Storing the app's background — target user, constraints, past decisions — in a project means you don't have to re-explain everything at the start of every session. The conversation picks up with shared context intact.
What to Try Next
If you're sitting with an idea you're not quite sure about, try this: ask Claude to list ten weaknesses of your concept. Not "what could go wrong" in the abstract, but specifically: ten things that could prevent this app from succeeding.
If you read through all ten and still want to build it, that's a meaningful signal. The weaknesses become a design checklist rather than a reason to stop. If the list deflates your enthusiasm quickly, that's valuable information too — better to discover it in a thirty-minute conversation than three weeks into development.
There's more value in talking to Claude before you open your code editor than most developers realize. And the conversation doesn't have to be long — sometimes ten minutes of focused questioning reveals the critical flaw or the crucial angle that makes the difference.
Discovering that changed how I approach the whole process. The code still has to get written, but now I know what it should do before I start.
If you're interested in how Claude fits into creative workflows that span making things and building software, the Claude workflow guide for creator-developers covers that intersection in more depth.