Is Your App Idea Worth Building? A 2026 Evaluation Framework

The AI dev velocity that makes shipping apps fast also makes it easy to build the wrong thing fast. This post is the practical 2026 framework I'd use for any new app idea: is this worth my time, can it make money, what would honest revenue look like, and when should I cut it before committing weeks?

Why evaluation matters now more than ever

Pre-AI, "wasting 6 months on the wrong app" was a real career risk. With Claude Code + Cowork + the modern toolchain, you can ship an MVP in 1-3 weeks. That cuts the cost of building the wrong thing — but it also means you can produce many wrong things quickly. Evaluation discipline replaces the natural friction of slow development.

Finding a niche

"Niche" doesn't mean tiny — it means specific. A specific audience with a specific problem they'll pay to solve.

Where good app niches come from:

• Your own irritants. Things that bug you weekly that no existing app solves well. Your RDR2 Companion was exactly this — gap left when Rockstar's official app was delisted.
• Communities you're already in. Subreddits, Discord servers, X/Bluesky niches you participate in. Notice the unsolved problems being discussed.
• Profession-adjacent gaps. Tools for nurses, restaurant managers, contractors, real-estate agents, teachers — specialized tools have less competition than general consumer.
• "Companion" patterns. Established product/community with no good companion app: games, sports, hobbies.
• AI-now-possible niches. Workflows that needed an expensive specialist before but are AI-able now.

What makes a niche worth pursuing:

• The audience is identifiable and reachable (a community exists; you can find them).
• They already pay for adjacent tools (signals willingness to pay).
• The problem is recurring, not one-time.
• The audience is large enough — "at least 10,000 plausible buyers" is a reasonable floor.
• The existing solutions are visibly bad (real complaints in reviews / forums).

Ideation with Claude Cowork

Once you have a niche, Cowork is the right tool for sharpening the idea before any code gets written. The workflow:

1. Brief Claude with the niche: audience, problem, why you think it's underserved. Be specific. "Game companions for $game" not "I want to build an app."
2. Ask for 5-10 concept variations. Different angles on the same audience. Different feature sets. Different monetization.
3. Have Cowork generate visual mockups for the 2-3 most interesting variations. Home screen, key feature screen, paywall.
4. Critique each one ruthlessly. What does this solve? Who would pay? What's the daily-use loop? What does the second-week-user see that brings them back?
5. Show the top 2 mockups to 5-10 people in the target audience. Their reactions tell you more than any market research.
6. Pick one and write a one-page "App Brief" with: target user, core problem, MVP feature set, pricing model, success metric, abandonment criteria.

Time investment: a Cowork ideation session is 2-4 hours. Cutting bad ideas here saves weeks later.

Market sizing — top-down + bottom-up

Two independent methods; if they roughly agree, your number is reasonable.

Top-down

Start with the addressable market and work down:

• Total people in the niche (e.g., "iOS users who play RDR2 globally" ≈ several million)
• × % who'd actively use a companion app (~5-10% for niche utilities)
• × % you can realistically reach (~1-5% in year 1 of a small app)
• = your realistic year-1 user pool

Bottom-up

Start with the customer and work up:

• How many people in this audience can you reach via channels you actually have? (community moderators, niche YouTube creators, your own network)
• What conversion rate would those channels deliver? (1-5% click-through, 10-30% of those install, 5-15% of installs pay)
• Result: month-by-month projected paid users for the first 6-12 months

For most niche apps, bottom-up is more honest. Top-down is the optimistic ceiling.

Competition check

Before building, do the 30-minute competitive audit:

1. App Store search. 3-5 most relevant search terms. Note the top 5 apps for each.
2. Read 1-star and 3-star reviews on the top competitors. This is where the underserved demand is. 1-stars are noise; 3-stars are diagnostic.
3. App rank and rating trends — SensorTower or AppFigures (paid) or Mobbin (free) for trajectory data.
4. Pricing landscape. Free? Paid? Subscription? What's the median price?
5. Recent updates. When did the leader last ship? An app that hasn't updated in 18 months is vulnerable.
6. Owner reputation. Is the leader an indie / a small studio / a corporate brand? Each implies different competitive dynamics.

Green flag: top apps have multiple bad reviews about the same missing feature. Red flag: top app is well-loved, frequently updated, and owned by a brand — this is a no-go niche unless you have a specific advantage.

Realistic download projections

Most indie iOS apps in 2026 do far fewer downloads than founders expect. Honest reference points:

• App with no marketing budget, no audience: 100-1,000 lifetime downloads. Most apps live here.
• Indie with small audience (newsletter / 5K-50K social): 1,000-10,000 in year one.
• Indie with strong audience or category hit: 10,000-100,000 in year one.
• App Store featuring (rare for indies): 50,000-500,000+ depending on slot duration.
• Genuine viral hit: 500,000+ — very rare, usually requires a moment + capable scaling response.

For the RDR2 Companion: realistic year-1 ceiling without significant marketing is probably 5,000-20,000 downloads, with conversion at 3-7% to paid. That's 150-1,400 paying users at $2.99 — revenue of $400-$4,000 / year. Modest but real, and the marginal effort to ship sequels (GTA V, etc.) is small once the platform exists.

The economics work when (a) you've reused the core across multiple apps, (b) you pick niches the audience already exists in, and (c) your costs are tightly controlled (low backend + AI bills).

Kill criteria

Define these before you build. Otherwise sunk cost will pull you forward past the point of sanity.

• Week 1: if Cowork mockups don't get any "yes I'd pay for that" from real audience members, kill or pivot.
• Week 2: if competitive audit reveals a well-loved incumbent with no real gap, kill.
• Month 1 post-launch: if you can't get 100 downloads with the channels available, the niche is wrong or the positioning is wrong — pause and diagnose.
• Month 3 post-launch: if downloads are growing but conversion to paid is < 1%, the monetization doesn't fit. Iterate or kill.
• Month 6 post-launch: if monthly net revenue < $50 with no clear path to growth, accept this is a portfolio / learning project, not a business.

Killing is not failure. Killing fast is the discipline that lets you ship the next thing that works.

10-minute Go/No-Go worksheet

Answer these in writing before committing time:

1. Who is the user? (Specific, not "everyone.")
2. What problem are they facing today, and how are they solving it currently?
3. Why does that current solution fail them?
4. What's the smallest version of your idea that improves their day?
5. How will they find your app? (Be specific. "App Store search" is rarely enough.)
6. Why would they pay for it / use it weekly?
7. What's the strongest competitor and why are you better?
8. What does $500/month in revenue look like in users? Can you reach that user count?
9. What would make you kill this in 30 days?
10. What's your unfair advantage? (Knowledge of the niche, existing audience, technical edge, etc.)

If you can answer #5 (distribution) and #10 (advantage) honestly, you have a real shot. If not, you're hoping — that's a no-go.

Validation playbook (before writing code)

1. Pre-MVP landing page. A single page describing the app, value prop, planned features. Email signup. Share in the niche communities. Measure interest.
2. Show Cowork mockups to 10 target users. Watch their reactions. Note the questions they ask — those are the things to address.
3. Get 100 email signups before writing Swift. If you can't, distribution is the real problem and the app won't fix it.
4. Pre-launch waitlist. Offer beta access in exchange for early feedback. Real users beta-testing find the product issues fast.
5. Then build. By the time you ship, you have an audience waiting.

This sequence sounds slow but is fast in real terms — the day you launch, you have users instead of crickets. The apps that flop loudly on launch usually skipped this step.

Once an idea passes evaluation: iOS App Cost, App Economics Framework, Profitability Calculator. For getting people to find the app: Marketing Fundamentals.