Blog Software DevelopmentAugust 24, 2026

How I Find My Next Mobile App Project

Finding the next mobile app is often harder than building it. Here's the process I use to look for a real problem, a reachable market, and a realistic chance of building something better.

Finding the next mobile app project is often harder than building it.

As a software engineer, I don’t usually struggle with the question:

“Can I build this?”

I struggle with a much more important question:

“Is this worth building?”

I can open X, Reddit, Product Hunt, App Store charts, Google Play, or an AI chatbot and get hundreds of app ideas in a few minutes.

That’s not the problem anymore.

The problem is finding an idea where the problem is real, the market exists, users can be reached, and I have a realistic chance of building something better.

I’ve spent quite a lot of time thinking about this, especially because mobile development has become dramatically faster. AI-assisted development makes it possible to go from an idea to a working prototype in days rather than weeks or months. RevenueCat’s 2025 research describes this shift directly: AI-assisted development has made launching and iterating on subscription apps much faster, while competition has increased at the same time.

That changes the game.

The bottleneck isn’t always development anymore.

The bottleneck is choosing what to build.

So this is the process I use when I’m looking for my next mobile app project.

I don’t start with ideas

This might sound strange, but I don’t start by asking:

“What app should I build?”

I start with:

“What problems are people repeatedly trying to solve?”

There’s a big difference.

If I start with ideas, I tend to generate features:

AI calendar
AI photo editor
habit tracker
finance app
workout app
productivity app

Most of these sound reasonable.

But they don’t tell me whether there’s an opportunity.

Instead, I start with problems.

For example:

“People traveling internationally don’t understand how much mobile data they’ll need.”

That’s a problem.

Then I can investigate:

Who has this problem?
How frequently?
How do they solve it today?
What do they pay?
What do existing apps do badly?
Is mobile the right platform?
Can I reach these users?

Now I have something to investigate.

The mobile market is still huge — but that doesn’t mean every app is a good opportunity

The overall mobile market remains enormous.

Appfigures estimated that global App Store and Google Play downloads reached about 106.9 billion in 2025, while consumer spending reached approximately $155.8 billion. Downloads declined, but spending increased substantially.

That tells me something important.

I don’t necessarily need to find an app that will get 10 million downloads.

There are businesses inside much smaller niches.

But the market is also becoming more competitive.

RevenueCat’s 2026 subscription-app research uses data from more than 115,000 apps representing over $16 billion in revenue and describes a market where new apps continue to flood the stores while revenue remains heavily concentrated among established winners.

Adapty’s 2026 research paints a similar picture: the number of subscription apps increased substantially, while median revenue per new app decreased. It reports that the top 10% of apps capture 94.5% of subscription revenue.

So I don’t interpret the growing app market as:

“There are more opportunities than ever.”

I interpret it as:

“There are more opportunities than ever, but there is also more competition than ever.”

That’s why I care so much about the process I use to find the project.

Step 1: I look for markets before products

My first question is:

Where is there already money, attention, or rapidly increasing demand?

I don’t necessarily want to create a new category.

In fact, I usually prefer the opposite.

If people are already paying for something, that’s useful information.

Competition isn’t automatically bad.

If there are ten successful apps solving a problem, I’ve learned something:

People care about the problem.

The real question becomes:

Can I build a meaningfully different solution for a specific segment?

This is much more interesting than entering a category where nobody has built anything.

I look at the App Store like a market researcher

The App Store itself contains a surprising amount of information.

Apple says App Store search ranking is influenced by factors including textual relevance, downloads, ratings, and customer behavior. Apple also exposes trending searches and multiple discovery surfaces.

That means I can investigate:

What people search for
Which categories are crowded
Which apps dominate a category
What language competitors use
What users complain about
Which features are emphasized
Which monetization models are common

I don’t just look at the top apps.

I look for movement.

Appfigures’ Market Trends product, for example, specifically tracks trending apps, rising apps, soft launches, new apps, and declining apps. Its Mobile Market Index also provides normalized download and revenue trends by category and country.

That’s exactly the kind of data I want when I’m asking:

“Is this category actually moving?”

Step 2: I look for growing categories, not just popular categories

A category being popular doesn’t necessarily mean it’s a good place for a new entrant.

Imagine:

Category A
Huge market
Flat growth
Extremely mature
Dominated by 5 companies

Category B
Smaller market
Fast growth
Fragmented competition
Poor UX

Category C
Tiny market
No growth
Very few users

I’d probably investigate B first.

I’m looking for momentum + pain + fragmentation.

That’s a much more interesting combination.

For example, AI is obviously a major current trend.

But “AI app” isn’t an idea.

It’s a technology.

RevenueCat’s 2025 data showed AI apps generating significantly higher revenue per install than the overall median, but it also emphasized that simply adding AI isn’t enough; differentiation matters.

So instead of asking:

“What AI app can I build?”

I’d ask:

“What existing workflow is painful enough that AI can make it dramatically better?”

That’s a much stronger starting point.

Step 3: I study successful apps

Once I find an interesting category, I start studying the leaders.

I want to understand:

Their positioning
Their onboarding
Their paywall
Their pricing
Their App Store screenshots
Their reviews
Their feature set
Their target audience
Their acquisition strategy
Their monetization model

Apple’s App Store analytics are useful here conceptually because the platform itself treats acquisition as a funnel: impressions → product page views → downloads → engagement → purchases and subscriptions.

I try to reconstruct that funnel for competitors.

For example:

Search
  ↓
App Store page
  ↓
Install
  ↓
Onboarding
  ↓
First value
  ↓
Paywall
  ↓
Subscription

Then I ask:

“Where is this product particularly strong?”

and:

“Where does the experience fall apart?”

The second question is usually more valuable.

Step 4: I read the one-star reviews

This is probably one of my favorite research techniques.

If I’m researching a category, I don’t spend most of my time reading five-star reviews.

I read the one-star and two-star reviews.

Because users are effectively writing my product roadmap for me.

I’ll look for repeated complaints:

“Too complicated.”

“I only wanted X, but I have to configure ten things.”

“The subscription is too expensive.”

“It doesn’t support Y.”

“The app crashes when…”

“I can’t export…”

“The free version is useless.”

“The feature I need is missing.”

One complaint isn’t particularly interesting.

Twenty similar complaints are.

That’s when I start writing them down.

Complaint                    Frequency

Missing feature X             ██████████
Too complicated               ████████
Expensive                     ██████
Poor onboarding               █████
Slow                          ███

Now I have something more valuable than an app idea.

I have evidence of dissatisfaction.

Step 5: I search Reddit for problems, not ideas

Reddit is particularly useful because people naturally describe frustrations in their own language.

I search things like:

"Is there an app for..."
"How do you manage..."
"I hate that..."
"Does anyone know..."
"Why is there no..."
"Alternative to..."
"How do you track..."
"What's the best app for..."

I’m not primarily looking for people asking:

“What app should I build?”

I’m looking for people who are already trying to solve something.

That distinction is huge.

Recent discussions among indie developers repeatedly point toward the same practical validation methods: finding real complaints, studying existing competitors, talking to potential users, and testing demand before spending months building.

I also pay attention to the language people use.

If ten people describe the same problem in ten different ways, I have learned something about positioning.

If everyone uses exactly the same terminology, I’ve learned something about search demand.

Both are useful.

Step 6: I don’t automatically reject an idea because competitors exist

This is a mistake I see quite often.

Someone says:

“There are already five apps doing this.”

And then they throw away the idea.

I don’t.

Competition can be evidence of demand.

If I search for:

“budget planner”

and find:

20 apps
subscription products
millions of reviews
YouTube videos
Reddit discussions
Google searches

I know something.

People care about budgeting.

Now I need to find a wedge.

Maybe I don’t want to build:

“Another budgeting app.”

Maybe I want:

“The simplest budgeting app for couples who share expenses.”

Or:

“A budgeting app for freelancers with irregular income.”

Or:

“A budget tracker designed specifically for international students.”

The opportunity isn’t necessarily the category.

The opportunity is the underserved segment inside the category.

Step 7: I look for a wedge

I call this the wedge.

It’s the specific reason someone would choose my product instead of an established competitor.

A wedge can be:

Audience

Built specifically for photographers.

Workflow

Turns receipts into expenses automatically.

Distribution

Designed for users coming from a specific community.

Technology

Uses on-device AI instead of uploading data.

Experience

Does one thing extremely well.

Business model

One-time purchase instead of subscription.

Localization

Designed for a specific country or language.

Integration

Works deeply with an existing workflow.

The important thing is that I don’t need to beat the incumbent at everything.

I need to be significantly better at one thing that matters to a particular user.

Step 8: I check whether mobile is actually the right platform

This is something developers often skip.

Just because I can build an app doesn’t mean the product should be an app.

I ask:

“Why does this need to live on a phone?”

Good mobile opportunities often have some combination of:

Frequent usage
Notifications
Camera
GPS
Sensors
Offline access
Personal data
On-device processing
Quick interactions
Contextual usage
Habitual behavior

For example:

A receipt scanner makes sense on mobile because I can take a photo immediately.

A running coach makes sense because the phone is with me while running.

A travel utility makes sense because I’m using it while moving around.

A desktop dashboard forced into an iPhone isn’t automatically a mobile product.

Step 9: I check distribution before I write code

This might be the biggest change in my thinking.

I used to ask:

“Can I build it?”

Now I ask:

“How will the first 1,000 people find it?”

If I can’t answer that question, I become much more cautious.

Because building the product is only one part of the problem.

Imagine I build an incredible app.

Then I publish it.

And…

Nothing happens.

The App Store has enormous discovery potential, but competition means I can’t simply assume organic downloads will appear. Apple provides acquisition analytics across App Store Search, Browse, referrals, web referrers, and campaigns precisely because acquisition sources matter.

So I ask:

Who are my users?
       ↓
Where do they already spend time?
       ↓
How can I reach them?
       ↓
Why would they click?
       ↓
Why would they install?

I prefer ideas with an obvious distribution channel

For example:

Community-driven

There is already a Reddit, Discord, Facebook, Slack, or niche community.

Search-driven

People actively search for the problem.

TikTok / Instagram-driven

The result is visually interesting and easy to demonstrate.

App Store-driven

The problem maps naturally to high-intent searches.

Content-driven

I can create useful content around the problem.

Partnership-driven

There are companies, creators, or communities that already have the audience.

Existing product-driven

I already have users from another product who might want this.

I don’t need all seven.

But I want at least one strong channel.

Step 10: I use the App Store as a validation tool

One thing I like about mobile is that the distribution platform itself gives me experimentation infrastructure.

Apple’s Product Page Optimization lets developers test product-page variants, including screenshots, app previews, descriptions, and icons.

Custom Product Pages let me create different versions of the App Store page for specific audiences or campaigns and measure not only downloads but downstream sales and subscription performance.

Google Play has a similar concept through Store Listing Experiments, where developers can test graphics and localized store listings against the current listing. Google also provides estimates around experiment duration and sample requirements.

This changes how I think about an app launch.

The App Store page isn’t just marketing.

It’s an experiment.

Step 11: I check monetization surprisingly early

I don’t want to build for three months and then ask:

“How do I make money from this?”

I want to ask it during research.

For subscription apps, this is particularly important.

RevenueCat’s 2025 report found that the top 5% of newly launched apps generated more than 400x the revenue of the bottom 25% after two years.

That’s an enormous distribution.

It means:

“The market is growing” doesn’t mean my app will make money.

I need to understand the economics of the particular idea.

I ask:

Who pays?
Why do they pay?
How often do they need the product?
Is the value recurring?
Is subscription appropriate?
Could a lifetime purchase work?
Could consumables work?
Is advertising realistic?
What does acquisition cost?
What might LTV look like?

Adapty’s 2025 and 2026 benchmark research also shows that monetization patterns vary significantly by category. Weekly plans, annual plans, trials, pricing, and LTV behave differently depending on the type of app.

That’s why I don’t blindly copy the monetization strategy of another category.

I look at the category’s economics

Suppose I discover two interesting categories.

Category A

High downloads
Low willingness to pay
High churn
Ad-supported competitors

Category B

Lower downloads
Strong subscription behavior
Frequent usage
Clear professional value

I’d probably investigate B first.

I don’t necessarily want the biggest market.

I want a market where a small number of users can support a viable business.

This is especially important for solo developers.

I don’t need 5 million users if:

2,000 paying users
×
€10/month
=
€20,000 MRR

Of course, reaching those 2,000 users is still difficult.

But the economics are easier to reason about.

Step 12: I look for recurring problems

A recurring problem is usually more interesting than a one-time problem if I’m considering subscriptions.

Compare:

“I need to convert this PDF once.”

with:

“I manage hundreds of PDFs every month.”

The second problem has more potential for:

Subscription
Retention
Habit formation
Automation
Upselling

This is one reason I like workflows.

Instead of:

“What tool can I sell?”

I ask:

“What workflow can I own?”

That’s a much stronger business opportunity.

Step 13: I look at frequency

I often score an idea by asking how frequently the user experiences the problem.

Once per year          ❌
Once per month         🟡
Once per week          🟢
Every day              🟢🟢
Multiple times/day     🟢🟢🟢

Frequency isn’t everything.

A once-a-year problem can still be valuable if the transaction is worth hundreds of euros.

But for consumer subscription apps, frequent usage usually gives me more opportunities to demonstrate value and retain the user.

RevenueCat’s benchmark data reinforces this relationship: categories with habitual use cases tend to perform better on conversion and retention than purely occasional-use products.

Step 14: I search for the “manual workaround”

This is one of my favorite signals.

If people aren’t using an app, I ask:

“What are they doing instead?”

Maybe they’re using:

Excel
Google Sheets
Notes
Notion
WhatsApp
Telegram
Email
Paper
screenshots
bookmarks
copy/paste
complicated workflows

That’s interesting.

A manual workaround means:

The problem exists.

If people are spending 30 minutes every week doing something manually, there might be an opportunity to turn it into a 30-second mobile workflow.

Step 15: I talk to people before building

This is where I try to escape my own assumptions.

I’ll talk to potential users and ask:

“How do you solve this today?”

Not:

“Would you use my app?”

The second question is almost useless.

People are polite.

They say:

“Yeah, that’s cool.”

That doesn’t mean they’ll pay.

Instead, I want to hear about their current behavior.

I ask:

When did you last have this problem?
What did you do?
What tool did you use?
How long did it take?
What was frustrating?
Have you paid for a solution?
What did you dislike about it?
What would make you switch?

Behavior is much more valuable than hypothetical enthusiasm.

Step 16: I build the smallest possible validation

I don’t always build the MVP first.

Sometimes I build a fake version of the business.

For example, imagine I’m considering an AI assistant that analyzes documents.

Before building the complete AI pipeline, I could:

Create a landing page.
Explain the benefit.
Let users upload a document.
Manually process the first 20 documents.
Deliver the result.
Ask whether they’d pay.

This is ugly.

That’s fine.

I’m not trying to build the product.

I’m trying to answer:

“Does anybody actually care?”

The MVP isn’t necessarily the smallest app

I think the phrase “MVP” is often misunderstood.

People interpret it as:

“Build the smallest version of the software.”

I interpret it as:

“Build the smallest experiment that can answer the biggest unknown.”

Those are very different things.

If my biggest uncertainty is:

“Will people pay?”

I need a payment experiment.

If my biggest uncertainty is:

“Can this AI produce useful results?”

I need a quality experiment.

If my biggest uncertainty is:

“Can I acquire users?”

I need a distribution experiment.

I don’t necessarily need a full application.

Step 17: I create a simple opportunity score

When I have several ideas, I like putting them into a simple scoring system.

Something like:

Factor	Score
Problem severity	1–5
Frequency	1–5
Existing demand	1–5
Willingness to pay	1–5
Competition	1–5
Differentiation opportunity	1–5
Distribution potential	1–5
Technical feasibility	1–5
Personal interest	1–5
Time to MVP	1–5

But I don’t blindly add everything together.

Some factors matter more than others.

For me, the most important questions are usually:

Real problem?
    ↓
Existing demand?
    ↓
Clear user?
    ↓
Distribution?
    ↓
Monetization?
    ↓
Can I differentiate?
    ↓
Can I build it quickly?

If an idea fails badly in one of those areas, I don’t try to rescue it with a high technical-feasibility score.

I especially like “boring” ideas

I’ve become increasingly interested in boring software.

Not because boring products are exciting.

Because boring problems can be valuable.

For example:

Expense tracking for a specific profession
Compliance reminders
Inventory for a niche business
Specialized calculators
Document workflows
Field inspection tools
Scheduling
Reporting
Professional education
Industry-specific utilities

These products don’t necessarily go viral.

That’s okay.

I don’t need every project to become the next TikTok.

Sometimes I want:

500 users who absolutely love the product.

rather than:

500,000 users who installed it once.

I look for “small pain, high frequency”

One pattern I particularly like is:

Small pain × high frequency

Imagine something takes users 3 minutes every day.

That’s not a catastrophic problem.

But:

3 minutes × 365 days
=
1,095 minutes/year
=
18.25 hours/year

Now the problem looks different.

If I can reduce that to 10 seconds, I’ve created meaningful value.

This is where mobile can be extremely powerful.

A phone is always available.

The best mobile products often remove tiny amounts of friction repeatedly.

I also look for “high pain, low frequency”

The opposite can work too.

For example:

Tax preparation
Immigration paperwork
Buying a house
Moving
International travel
Insurance claims
Vehicle sales

These might happen rarely.

But when they happen, the user really cares.

The monetization model may simply need to be different.

Instead of a subscription, perhaps:

One-time purchase
Transaction fee
Lead generation
Professional service
Affiliate revenue

This is why I don’t decide on monetization before understanding the problem.

I use current market data to avoid building into a shrinking category

This is where tools such as Appfigures become particularly useful.

Its Mobile Market Index tracks normalized download and revenue trends across categories and countries, while its Market Trends product highlights rising and declining apps.

I want to know:

Is this category growing?
       ↓
Are downloads growing?
       ↓
Is revenue growing?
       ↓
Are new apps appearing?
       ↓
Are users paying?

A category with falling downloads but increasing revenue can still be interesting.

A category with increasing downloads but collapsing monetization might be less attractive.

Again:

Downloads are not the business.

I don’t blindly chase AI

AI is probably the easiest example of this problem.

I can build:

AI writer
AI photo editor
AI planner
AI therapist
AI coach
AI translator
AI notes
AI search
AI assistant

incredibly quickly.

That doesn’t mean I should.

RevenueCat’s 2026 research specifically warns that AI apps are churning quickly and that the market is becoming harder for undifferentiated products.

The question I want to answer is:

“Why does this product need AI?”

If the answer is:

“Because AI is popular.”

I don’t build it.

If the answer is:

“This task was previously impossible or painfully manual, and AI changes the economics or UX.”

Now I’m interested.

Step 18: I check whether I personally understand the user

This is underrated.

If I understand the user, I have an advantage.

Maybe I:

Have the same problem.
Work in the industry.
Know people in the industry.
Participate in the community.
Understand the terminology.
Know the existing workflows.
Know what competitors get wrong.

That gives me an unfair advantage.

And I like unfair advantages.

I don’t necessarily want to enter a market where I know nothing and compete against companies that have spent ten years learning the customer.

Step 19: I ask whether I can ship in weeks, not months

The faster I can get to a real user, the faster I can learn.

This doesn’t mean rushing a production-quality product.

It means controlling scope aggressively.

For example, my first version might have:

1 platform
1 core workflow
1 user type
1 acquisition channel
1 monetization model
1 primary metric

That’s enough.

I don’t need:

iOS
Android
Web
Desktop
20 integrations
10 languages
AI agents
social features
team accounts
enterprise billing

on day one.

I want the first version to answer one question

When I’m building the first version, I ask:

“What is the one thing this product must prove?”

For example:

Product hypothesis

People will pay to automatically turn voice notes into structured meeting summaries.

The MVP only needs to prove:

Voice note
   ↓
Useful summary
   ↓
User comes back
   ↓
User pays

Everything else can wait.

Step 20: I launch earlier than feels comfortable

At some point, research becomes procrastination.

I’ve been there.

I can spend:

another day studying competitors
another week analyzing keywords
another month refining the idea

and feel productive.

But eventually I need reality.

A real user interacting with the product teaches me more than another 20 competitor screenshots.

So I try to reach this point quickly:

Idea
 ↓
Research
 ↓
Hypothesis
 ↓
Tiny prototype
 ↓
Real users
 ↓
Feedback

Then I iterate.

My “next app” research workflow

If I were starting from zero today, this is roughly how I’d approach it.

Day 1 — Market discovery

I would browse:

App Store categories
Google Play categories
Appfigures
App Store rankings
Product Hunt
Reddit
Indie Hackers
Google Trends
competitor apps

The goal isn’t to find the idea.

It’s to find interesting markets.

Apple’s App Store discovery documentation, Google Play’s Store Listing Experiments, and App Store analytics are particularly useful because they show how much information exists around acquisition and store conversion.

Day 2 — Competitor research

For each interesting market:

Top 10 apps
↓
Pricing
↓
Reviews
↓
1-star complaints
↓
Features
↓
Positioning
↓
Distribution

Then I write down repeated problems.

Day 3 — User research

I find actual people experiencing those problems.

I ask how they solve them today.

Day 4 — Distribution research

I answer:

“How will I get my first 100 users?”

If I don’t have a convincing answer, I downgrade the idea.

Day 5 — Monetization

I investigate:

pricing
subscription behavior
competitors
willingness to pay
category benchmarks

RevenueCat and Adapty are useful here because their benchmark datasets provide category-level information about conversion, pricing, retention, and revenue.

Day 6–7 — Prototype

I build the smallest thing that can test the core assumption.

Not the full product.

Where I look for ideas

I have a few places I repeatedly come back to.

1. App Store rankings

I look for categories where several apps are doing well.

I’m especially interested in apps that are:

relatively new
growing quickly
simple
highly monetized
targeting a specific niche

Appfigures specifically provides market-trend signals around new, trending, declining, and soft-launched apps.

2. Reddit

I search for complaints.

Not startup ideas.

I want to hear:

“Why is this so difficult?”

That’s often a much better signal.

Recent 2026 discussions from indie developers repeatedly mention Reddit, communities, competitor reviews, and direct conversations as practical sources of app opportunities and validation.

3. Product Hunt

I use Product Hunt differently from how I used to.

I don’t ask:

“What’s the coolest product today?”

I ask:

“What problem are developers currently trying to solve?”

Then I look for categories with repeated launches.

Repeated launches can reveal:

emerging categories
new technology
user demand
distribution opportunities
competitive gaps

4. Google Trends

Google Trends is useful for checking whether interest around a problem is:

Growing
───────╱

or:

Declining
╲───────

or:

Seasonal
╱╲╱╲╱╲

I don’t treat search volume as proof of a business.

But it is useful context.

5. App Store search

Search suggestions are surprisingly valuable.

If I start typing:

invoice...

and get:

invoice maker
invoice scanner
invoice generator
invoice tracker
invoice app

I now have several problem statements to investigate.

Apple explicitly notes that App Store search suggestions and Trending Searches can help reveal what customers are searching for in their region.

The signal I care about most: people already spending money

If I find an app with:

lots of users
subscriptions
bad reviews
poor UX
outdated design
obvious missing features

I get very interested.

Why?

Because I don’t have to prove that people want the category.

Someone already proved it.

My job becomes:

Can I build a substantially better product for a specific audience?

That’s a much lower-risk question.

But I don’t clone apps

There’s a difference between:

“This market is validated.”

and:

“I’ll copy this app.”

I don’t want to clone.

I want to understand the underlying demand.

For example:

Existing product:
Photo editing for everyone

My opportunity:
Fast professional headshots for job seekers

Same general technology.

Different customer.

Different positioning.

Different workflow.

Different acquisition.

Different product.

I look for underserved users

Sometimes the product isn’t bad.

The audience is simply too broad.

“Fitness app” is extremely broad.

But:

“Strength training for women over 50”

is specific.

“Language learning” is broad.

But:

“English pronunciation training for German-speaking professionals”

is specific.

“Finance app” is broad.

But:

“Tax tracking for freelancers who work across EU countries”

is specific.

Specificity gives me somewhere to start.

I can always expand later.

The idea doesn’t need to be unique

This is another mindset shift I’ve developed.

I don’t need:

An idea nobody has ever thought of.

I need:

A problem I can solve better for a group of people I can reach.

There are millions of restaurants.

That doesn’t mean another restaurant cannot exist.

There are thousands of note-taking apps.

That doesn’t mean every possible note-taking workflow has been solved.

The important question is not:

“Has this been built?”

It’s:

“Has this been solved well enough for this particular user?”

My final filter

Before committing serious time to a mobile app, I try to get comfortable answering these questions:

Problem

What painful problem am I solving?

User

Who specifically has it?

Frequency

How often do they experience it?

Existing solution

What do they do today?

Competition

Who already makes money solving it?

Gap

What do those products get wrong?

Wedge

Why would someone choose mine?

Distribution

How will I get the first 100 users?

Monetization

Why would someone pay?

Mobile

Why should this be an app?

Speed

Can I test the core assumption in weeks?

If I can’t answer most of these, I probably don’t have an app idea yet.

I have a feature idea.

And those are very different things.

What I actually want from my next project

At this point, I don’t expect to discover a magical idea that nobody else has seen.

That’s not what I’m looking for.

I want something more practical:

A real problem
      +
A clear user
      +
Existing demand
      +
A meaningful gap
      +
A distribution channel
      +
A reasonable business model
      +
A product I can build quickly

That’s enough.

The mobile ecosystem is still enormous, and consumer spending continues to grow even while downloads have become more difficult to acquire.

But the market is also becoming more concentrated. RevenueCat and Adapty’s recent research both show how much of the subscription economy is captured by a relatively small group of winners.

That makes me less interested in chasing whatever happens to be trending this week.

Instead, I want to find small, specific problems with strong signals of demand.

Then I want to validate them quickly.

Then I want to build.

Then I want to put the product in front of real users.

And then — probably most importantly — I want to be willing to kill it if reality tells me I’m wrong.

Because finding my next mobile app project isn’t really about finding the perfect idea.

It’s about finding a good enough problem, validating it faster than I can fall in love with it, and giving myself enough room to discover what the product should actually become.