• Apple App Store vs Google Play is not really an either-or. With Claude Code and Expo, one codebase ships to both stores from a single EAS pipeline.
• Apple has a stricter human review and the Guideline 4.3 clone check. Google has the 14-day, 12-tester closed test for new personal accounts.
• Both are worth it: 2.5 billion active Apple devices and 850 million weekly App Store users on one side, 2 billion-plus active Android devices on the other.

The Real Answer - You Do Not Have to Choose

The Apple-versus-Google question assumes you can only afford one. That was true when each store meant a separate codebase in a separate language. It is not true anymore. With Expo, one codebase becomes both an iOS app and an Android app, and EAS Build and Submit push to both stores from a single pipeline. So the honest answer is both, and the comparison below is about knowing each store's gates, not about picking a side.

The reach on each side is why both matter. Apple has 2.5 billion active devices and 850 million weekly App Store users. Google Play reaches 2 billion-plus active Android devices. Skipping either one leaves a large audience on the table for no real benefit once your codebase already builds for both.

How the Two Stores Differ

The two big first-launch gates are different in kind. Apple's is a judgment call, mostly the Guideline 4.3 distinctiveness check and compliance paperwork, handled by a human reviewer. Google's is a policy timer, the 14-day closed test with 12 testers for new personal accounts. Neither is a code problem, and both are covered by the course so neither surprises you.

If You Truly Had to Pick One First

You do not have to, but if you wanted to sequence them, think about your gates. Google's closed test takes 14 continuous days, so starting it early keeps that clock running in the background. Apple's review is faster once your app is compliant and distinct. A common rhythm is to kick off the Google closed test early so its timer runs while you finish, then submit to Apple when the app is store-ready, and let both approvals land close together.

TIP: Start the Google closed test early because of its 14-day clock, and submit to Apple once the app is compliant. Sequencing around each store's gate lets both approvals land near the same time instead of stacking end to end.

One Pipeline, Both Stores

The reason this stays manageable for a solo builder is EAS. The EAS Submit playbook builds and submits to both stores from one pipeline, one command, no Mac required. You are not maintaining two projects or learning two toolchains. You maintain one Expo codebase and push it to both stores, which is what makes shipping to Apple and Google at once realistic for a first-time builder.

FAQ

Should my first app go to the Apple App Store or Google Play?

Both. With Claude Code and Expo you build one codebase that ships to both stores from a single EAS pipeline, so choosing one means leaving a large audience behind for no real benefit. The comparison matters for knowing each store's gates, not for picking a side.

What is the main difference between Apple and Google review?

Apple runs a stricter human review with the Guideline 4.3 distinctiveness check and compliance paperwork. Google adds a policy timer for new personal accounts: a 14-day closed test with 12 testers before you can go live. Apple's gate is a judgment call, Google's is a timed requirement, and neither is a code problem.

Which store reaches more people?

They reach different large audiences. Apple has 2.5 billion active devices and 850 million weekly App Store users. Google Play reaches 2 billion-plus active Android devices. Because one codebase ships to both, the practical move is to reach all of them rather than compare which is bigger.

Do I keep the same share of revenue on both stores?

Yes, when you enroll in each store's Small Business program you keep about 85% of revenue on both. Both Apple and Google offer the reduced commission for qualifying developers, so the revenue math is similar across the two stores once you have signed up for each program.

If I had to launch on one store first, which should it be?

You do not have to, but if you sequence them, start the Google closed test early because its 14-day clock runs in the background, then submit to Apple once the app is compliant and distinct. That way both approvals can land near the same time instead of stacking one after the other.

Is it really one codebase for both the App Store and Google Play?

Yes. Expo produces one codebase that builds native iOS and Android apps, and EAS Build and Submit pushes to both stores from a single pipeline, one command, no Mac required. You maintain one project, not two, which is what makes launching on both stores realistic for a solo builder.

• Getting approved is not getting found. With 5M+ apps across both stores, App Store Optimization is how a brand-new app shows up in search at all.
• The keyword system finds the search gaps the big apps left open, so your app ranks for terms real people type but the leaders ignore.
• Your screenshots are the ad. Most installs are decided by the first two or three screenshots, so treat them as the pitch, not an afterthought.

Approved Is Not Found

The quiet disappointment of a first launch is going live and hearing nothing. Approval only means your app can be installed. It does not mean anyone can find it. With more than 5 million apps across the Apple App Store and Google Play, an app with no App Store Optimization is invisible in search, and store search is where most discovery happens. Growth is its own stage in the path for this reason.

App Store Optimization is the practice of making your app rank and convert in store search. It has two halves: getting found, which is keywords, and getting the tap, which is your icon, title, and screenshots. A brand-new app needs both, because ranking for a term you cannot convert is wasted, and a great listing nobody sees never gets the chance.

The Keyword System - Find the Gaps

A new app cannot outrank the category giant for a broad, competitive keyword, so do not try. The ASO keyword system finds the search gaps the big apps left open, the specific phrases real people type that the leaders do not target. This is the same niche work you did in validation, now aimed at search.

1. List the exact phrases your ideal user would type into store search, in their words, not yours.
2. Check how competitive each phrase is. Skip the broad, saturated terms the giants own.
3. Find the specific phrases with real demand and weak results. Those are your gaps.
4. Put your strongest keywords into your title and subtitle, where they carry the most ranking weight.

TIP: A brand-new app wins on specific keywords, not broad ones. Ranking number one for a phrase 500 of the right people search beats ranking number 200 for a phrase a million people search. The keyword system is about owning the open gaps.

Screenshots Are the Ad

Once search brings someone to your listing, your screenshots decide whether they install. Most people decide from the first two or three screenshots without ever reading the full description, so those images are your actual pitch. A screenshot that just shows a raw screen wastes the slot. A screenshot with a short caption that names the benefit sells it.

• Lead with your single strongest benefit in the first screenshot, with a short caption a scanner can read in a second.
• Show the real app, not a fake mockup. The screenshots must match what the reviewer and the user actually get.
• Use captions that name benefits, not feature labels. 'Log a set in one tap' beats 'Workout screen.'
• Order them as a story: the promise first, then how it works, then the payoff.

ASO Is Ongoing, Not One-and-Done

App Store Optimization is not a launch-day task you finish. Watch which keywords bring installs, test new screenshots, and refine your title and captions over time. Ratings and reviews feed ranking too, so prompting happy users to review at the right moment is part of the same system. Small, steady tuning is how a new app climbs from invisible to discoverable.

NOTE: Treat your first listing as version one, not final. The builders who get found keep testing screenshots and keywords after launch. The ones who set it and forget it stay invisible no matter how good the app is.

FAQ

What is App Store Optimization and why does a new app need it?

App Store Optimization is making your app rank and convert in store search. With 5M+ apps across both stores, a new app with no ASO is invisible in search, and store search is where most discovery happens. Getting approved only means your app can be installed. ASO is how people actually find it.

How do I pick keywords for a brand-new app?

Do not chase broad terms the giants own. The keyword system finds the search gaps the big apps left: specific phrases real people type that the leaders ignore. List your user's exact words, skip the saturated terms, find phrases with real demand and weak results, and put your strongest ones in your title and subtitle.

How important are the screenshots?

They are the ad. Most people decide whether to install from the first two or three screenshots without reading the full description, so those images are your real pitch. Lead with your strongest benefit, use captions that name benefits rather than feature labels, and show the real app, not a fake mockup.

Can a new app outrank the big apps in search?

Not on broad, competitive keywords, and you should not try. You outrank them on specific phrases they ignore. Ranking first for a term 500 of the right people search beats ranking two-hundredth for a term a million people search. Owning the open gaps is how a small app gets found.

Is App Store Optimization a one-time task?

No. ASO is ongoing. Watch which keywords bring installs, test new screenshots, and refine your title and captions over time. Ratings and reviews also feed ranking, so prompting happy users to review is part of it. The builders who get found keep tuning after launch instead of setting it and forgetting it.

Do ratings and reviews affect App Store search ranking?

Yes. Ratings and reviews are a signal both stores use, alongside keywords and install behavior, so a well-rated app tends to rank and convert better. Prompt happy users to leave a review at a good moment, such as right after a positive experience in the app, and make it part of your ongoing ASO.

• In-app subscriptions must go through Apple and Google's own payment systems for digital goods. RevenueCat sits on top of both and wires the paywall into your Expo app.
• Enroll in Apple's and Google's Small Business programs and you keep 85% of revenue on the qualifying tier instead of 70%.
• Wire and test the paywall before you submit, not after. A broken or missing subscription flow is a rejection and a lost first customer.

Why You Cannot Just Use Stripe

The first thing that surprises new app builders: for digital subscriptions inside an app, Apple and Google require you to use their own in-app purchase systems, not Stripe or your own checkout. This is a rule, not a preference, and trying to route around it is a fast rejection. Monetization is its own stage in the path because it works differently from web payments in ways you have to know up front.

That does not mean you have to hand-code Apple's StoreKit and Google's billing library yourself. That is what RevenueCat is for. It sits on top of both stores' payment systems and gives you one clean way to manage subscriptions across iOS and Android from your single Expo codebase.

What RevenueCat Actually Does

RevenueCat is the layer that turns two complicated store billing systems into one paywall you can wire into your Expo app. You define your subscription products once, and RevenueCat handles the purchase, the receipt validation, and knowing whether a given user currently has an active subscription, on both stores.

• Define your subscription products in App Store Connect and the Google Play Console.
• Connect them to RevenueCat so both stores are managed from one place.
• Wire the paywall into your Expo app: the onboarding into free-trial into subscription flow.
• Check subscription status in your app so paying users unlock the paid features and everyone else sees the paywall.

NOTE: The paywall flow in App Store Launch Club is the wired onboarding into free trial into subscription setup with RevenueCat, tested before you submit. Getting the sequence right is what turns a downloader into a paying subscriber.

Keep 85% of Revenue, Not 70%

Both stores take a cut of your subscription revenue. The default is a larger cut, but Apple and Google each run a Small Business program that drops their commission for qualifying developers, and enrolling means you keep 85% of revenue instead of 70%. On a small app that is the difference between the numbers working and not.

TIP: Enroll in Apple's and Google's Small Business programs before you launch. Keeping 85% instead of 70% is free money you leave on the table if you skip the paperwork, and it is a one-time setup.

Test the Paywall Before You Submit

The most expensive paywall bug is the one you find after launch, when a real customer taps subscribe and nothing happens. Both stores give you sandbox and test environments to run a full purchase without spending real money. Run the entire flow, onboarding through trial through active subscription, and confirm the paid features actually unlock before you submit.

A broken subscription flow is also a review risk. If a reviewer taps your paywall and it fails, that is a rejection. Wiring and testing the paywall before submission is part of getting store-ready, not an afterthought for later.

FAQ

Can I use Stripe for in-app subscriptions?

No, not for digital subscriptions inside the app. Apple and Google require you to use their own in-app purchase systems for digital goods, and routing around that is a fast rejection. RevenueCat sits on top of both stores' systems so you get one clean paywall without hand-coding each store's billing library.

What does RevenueCat do in an Expo app?

RevenueCat turns Apple's and Google's separate billing systems into one paywall you wire into your Expo app. You define your subscription products once, and RevenueCat handles the purchase, receipt validation, and knowing whether a user has an active subscription, across both iOS and Android from your single codebase.

How do I keep 85% of my app revenue instead of 70%?

Enroll in Apple's and Google's Small Business programs. Qualifying developers pay roughly 15% commission instead of 30%, so you keep about 85% of revenue instead of 70%. It is a one-time setup, so do it before you launch rather than leaving the difference on the table.

Should I build the paywall before or after I submit?

Before. Wire and test the full onboarding into free-trial into subscription flow before you submit. A broken or missing paywall is both a lost first customer and a review risk, because if a reviewer taps subscribe and it fails, that is a rejection. Getting the paywall right is part of getting store-ready.

How do I test in-app subscriptions without spending money?

Both stores provide sandbox and test environments so you can run a complete purchase flow without real charges. Run the entire sequence, from onboarding through trial to an active subscription, and confirm the paid features unlock. Finding a paywall bug in the sandbox is free. Finding it after launch costs you real customers.

Do I need a separate paywall for iOS and Android?

No. Because you build from one Expo codebase and RevenueCat manages both stores, you wire one paywall that works across iOS and Android. You define the products in each store's console once and connect them to RevenueCat, then check subscription status in a single place in your app.

• Google Play requires new personal developer accounts to run a closed test with 12 testers for 14 continuous days before you can apply for production access.
• This wall stops more first Android launches than any bug, because most solo builders do not have 12 people to test their app.
• The fix is a tester pool. App Store Launch Club uses the club itself as your 12 testers, so the requirement stops being a wall and becomes a checkbox.

What the Rule Actually Is

Google Play added a requirement for new personal developer accounts: before you can apply for production access and go live, you have to run a closed test with at least 12 testers for 14 continuous days. It is not optional and there is no way to code around it. It is a policy gate, and it sits right before the finish line where it does the most damage to momentum.

Understanding this is why Google Play closed testing is its own topic in the course. Nobody tells first-time builders about it, so they build a great Android app, hit submit, and discover a two-week wall they did not plan for.

Why It Stops So Many First Launches

The wall is not technical, it is social. Most solo builders simply do not have 12 people who will install a test build and keep it on their phone for 14 days. Friends and family install it, forget about it, and the test never completes. The 14 days are continuous, so a tester dropping out can reset your progress. That is how a finished app sits unlaunched for weeks.

WARNING: The 14-day clock wants continuous participation from your testers. If your test pool falls apart mid-window, you can lose the progress you made. This is why a reliable pool of testers matters more than a big one.

The Fix - A Real Tester Pool

The requirement is only a wall if you are alone. The solution is a pool of people who will actually opt in and keep the app installed for the full window. App Store Launch Club uses the club itself as your tester pool, so you post your closed test, other builders opt in, and you return the favor for theirs. The 12-tester system turns a two-week roadblock into a scheduled step.

1. Set up a closed testing track in the Google Play Console and add your testers by email or opt-in link.
2. Recruit 12 real testers who will keep the app installed for the full 14 continuous days. The club is your pool.
3. Start the 14-day clock and keep your testers engaged so the window completes without resetting.
4. Once the window is complete, apply for production access and prepare to go live.

Plan the 14 Days Into Your Timeline

Because the closed test takes 14 days, the move is to start it early, not at the end. In the 90-day path, you recruit testers and kick off the closed test in the middle weeks while you finish other work, so the clock is already running by the time everything else is ready. That way the 14 days overlap with your build instead of being tacked on after it.

TIP: Start your Google closed test in week two to four, not at the finish. If the 14-day clock is already running while you polish the app, the requirement never becomes the thing standing between you and launch.

FAQ

What is the Google Play 12-tester requirement?

Google Play requires new personal developer accounts to run a closed test with at least 12 testers for 14 continuous days before applying for production access. It is a policy gate, not a technical step, and there is no way to code around it. You have to complete the test to go live.

Why does the 12-tester rule stop so many first launches?

Because most solo builders do not have 12 people who will install a test build and keep it for 14 continuous days. Friends install it and forget, the window resets, and a finished app sits unlaunched for weeks. The wall is social, not technical, which is why a reliable tester pool solves it.

How do I get 12 testers for my Google Play closed test?

You need a pool of people who will opt in and keep the app installed for the full window. App Store Launch Club uses the club itself as your tester pool: you post your test, other builders opt in, and you return the favor. The 12-tester system turns the requirement into a scheduled step.

Do the 14 days have to be continuous?

Yes. The closed test runs over a 14-day continuous window with active testers. If your pool falls apart mid-window you can lose progress, which is why a committed, reliable group of testers matters more than a large one. Plan to keep them engaged for the full two weeks.

When should I start the closed test in my timeline?

Early, not at the end. Start the closed test in the middle weeks of your build so the 14-day clock is already running while you finish other work. If you wait until the app is done, the two-week window becomes the thing standing between you and launch instead of overlapping with your build.

Does the Apple App Store have the same 12-tester rule?

No. This closed-testing requirement is specific to new personal Google Play developer accounts. Apple has its own review process, including the Guideline 4.3 distinctiveness check. The two stores have different gates, which is why the course covers each separately so neither one surprises you at launch.

• Guideline 4.3 (spam and clone apps) is the number one reason first apps get rejected. Apple wants something distinct, not another copy of an existing app.
• Most rejections are compliance, not code: missing privacy policy, wrong data-safety answers, thin or copycat functionality, or an incomplete listing.
• A rejection is not the end. Read the exact reason Apple gives, fix that one thing, and resubmit. The Rejection-Fix Vault covers the common ones with the exact fix.

What Apple Is Actually Reviewing

Apple App Review is not a code review. A human tester opens your app and checks whether it does what the listing says, whether it is distinct and useful, and whether the legal and privacy pieces are in place. Most first-app rejections are not about broken code. They are about compliance and distinctiveness, the parts first-timers do not know to prepare.

Getting store-ready is its own stage in the 9-stage path for exactly this reason. Privacy, compliance, screenshots, and the 4.3 distinctiveness check are where launches stall, and they are all learnable before you ever hit submit.

Guideline 4.3 - The Clone Rejection

Guideline 4.3 covers spam and clone apps, and it is the single most common reason a first app gets rejected. Apple does not want the ten-thousandth generic flashlight, calculator, or wallpaper app. If your app looks like a template someone else already shipped, or like a thin copy of a popular app, 4.3 is what stops you.

• Solve a specific problem for a specific audience, the gap you found during validation, not a broad copy of a leader.
• Make the app genuinely distinct in features and design, not a reskin of a common template.
• Give it real functionality. A single-screen app that just wraps a website reads as spam to a reviewer.
• Write a listing that matches what the app does, so the reviewer sees consistency, not marketing that oversells a thin app.

WARNING: The Apple 4.3 Rulebook comes down to one rule: build something distinct. Validate a sharp niche first, and you clear 4.3 almost by default, because a genuinely useful app for a specific audience is the opposite of a clone.

The Compliance Checklist Most First-Timers Miss

After distinctiveness, most rejections are missing paperwork. None of it is hard once you know it exists, and all of it is on the store-ready checklist.

1. A privacy policy URL that is live and accurate.
2. Data-safety and privacy answers that truthfully match what your app collects.
3. A content rating that fits your app.
4. Complete metadata: accurate description, screenshots that show the real app, and correct keywords.
5. A working demo account or login if your app is behind a sign-in, so the reviewer can actually get in.

NOTE: A reviewer who cannot log in will reject you. If your app has accounts, hand Apple a working demo login in the review notes. This one missing detail rejects more first apps than any bug.

You Got Rejected - Now What

A rejection feels like a wall, but it is a to-do item. Apple tells you which guideline you failed and usually why. Read that reason carefully, fix that one specific thing, and resubmit. Most first apps that eventually ship were rejected at least once. The difference between the people who launch and the people who quit is that the launchers treat the rejection as a fix, not a verdict.

This is exactly what the Rejection-Fix Vault is for: the most common Apple and Google rejections, each paired with the exact fix. You get rejected, you open the vault, you find your rejection reason, you apply the fix, and you resubmit. It turns a scary email into a checklist item.

FAQ

What is Guideline 4.3 and why does it reject so many first apps?

Guideline 4.3 is Apple's rule against spam and clone apps, and it is the number one reason first apps get rejected. Apple does not want thin copies of popular apps or generic template apps. The fix is to build something distinct for a specific audience, which is why validating a sharp niche first clears 4.3 almost automatically.

How do I avoid a Guideline 4.3 rejection?

Solve a specific problem for a specific audience, make the app genuinely distinct in features and design, give it real functionality rather than wrapping a website, and write a listing that matches what the app actually does. A useful app for a defined niche is the opposite of a clone, which is what 4.3 targets.

What compliance items get first apps rejected besides 4.3?

A missing or inaccurate privacy policy, data-safety answers that do not match what the app collects, a wrong content rating, incomplete metadata, and no working demo login for apps behind a sign-in. None are hard once you know they exist, and all are on the store-ready checklist.

My app was rejected. Is it over?

No. A rejection is a to-do item, not a verdict. Apple tells you which guideline you failed and usually why. Read the reason, fix that one thing, and resubmit. Most first apps that eventually ship were rejected at least once, and the Rejection-Fix Vault pairs the common rejections with the exact fix.

Does the reviewer need a login to my app?

Yes, if your app is behind a sign-in. A reviewer who cannot get in will reject you. Provide a working demo account in the review notes so Apple can actually test the app. A missing demo login rejects more first apps than most bugs do.

How long does Apple App Review take?

It varies, but reviews commonly turn around within a day or two once your submission is complete. Times shift, so treat any specific number as an estimate rather than a promise. The way to avoid delays is to submit a complete, compliant app the first time so you do not loop through rejection and resubmission.

• You can ship your first app in 7 days with Claude Code because you describe the app in plain English and Claude Code writes the native code for you.
• The stack is Claude Code plus Expo, so one codebase becomes both an Apple App Store and a Google Play app. No Swift, no Kotlin, no $10K developer.
• Week one is not about a finished product. It is about a real, working app on your own phone by the end of the week, which is the moment most people quit believing they cannot build.

Why 7 Days Is Realistic Now

A year ago, shipping your first app in 7 days would have been a fantasy. You would have spent that week learning what a build tool even is. That is no longer the constraint. With Claude Code and Expo, you type what you want in plain English and Claude Code writes the native app. The tool does the part that used to take months of learning Swift or Kotlin, so your week is spent on decisions, not syntax.

Inside App Store Launch Club this is the First-App Sprint: a guided week that puts a real, working app on your phone by the end of week one. It is not a toy in a browser. It is a native app running on your actual device, which is the moment the whole thing stops feeling impossible.

Day 1 - Set Up the Build Machine

Day one is installing the machine that turns English into an app: Claude Code plus Expo. This is the setup stage of the 9-stage path, and it is the single most important day because everything after it runs on this foundation. Once it is in place, you can type a sentence and see a screen appear on your phone.

1. Install Claude Code and start a new Expo project. Claude Code scaffolds it for you.
2. Enroll in both stores on day one: the Apple Developer Program and the Google Play Console. Approval can take a day or two, so start the clock now.
3. Run the app on your own phone with Expo so you see live changes as you build.
4. Commit early with git so every step is saved and reversible.

TIP: Enroll in both developer accounts on day one, not the day you submit. Apple and Google both take time to approve you, and there is no reason for that wait to block your launch at the finish line.

Days 2 to 3 - Validate and Design Before You Build

The biggest week-one mistake is building the wrong thing fast. Before Claude Code writes a single screen, prove someone actually wants the app and sketch what it looks like. Validation is a stage of its own for a reason: it is cheaper to kill a bad idea on day two than after 90 days of building.

Then design. The AI design method is simple: mock up every screen before Claude writes a line, so Claude Code builds from a blueprint instead of a guess. A rough mockup of your three or four core screens is enough to keep the build focused and stop it from wandering.

Days 4 to 6 - Build With Copy-Paste Prompts

This is where the app takes shape. App Store Launch Club ships 69 copy-paste build prompts, one per build step, so you paste a prompt into Claude Code and the app writes itself from the first screen forward. You are not guessing at what to type. You are working through a sequence that has already been mapped.

Because the whole course is 88 lessons and 124 teaching diagrams, one visual for every lesson, you are never decoding a wall of text. You see the step, paste the prompt, and watch the screen update on your phone. By day six you have a working core: onboarding into your main screens, running on your device.

NOTE: Keep week one narrow. One core feature done well beats five half-built ones. You can add screens after the app is real. The goal this week is a working app you can open, not a finished product.

Day 7 - A Real App in Your Hand

By the end of the week you have a real, working native app on your phone that Claude Code wrote from your plain-English description. It is not submitted yet, and that is fine. Submission, the paywall, and store approval come in the weeks after, along the 90-day path. Week one is about proving to yourself that you can build, because that belief is what carries you to launch.

Everything after this stacks on the same foundation: wire the RevenueCat paywall, get store-ready with privacy and ASO, then EAS submit to both stores from one pipeline. But none of it matters until you have held your own app in your hand, and that happens in 7 days.

FAQ

Do I need to know how to code to ship an app in 7 days?

No. With Claude Code and Expo you describe the app in plain English and Claude Code writes the native code. App Store Launch Club includes 69 copy-paste build prompts so you paste a prompt and the app writes itself. You are making product decisions, not writing Swift or Kotlin from scratch.

Does 7 days mean my app is live on the App Store in a week?

No, and any course that promises that is not being honest. Week one puts a real, working app on your own phone. Submission, the paywall, store compliance, and approval come over the following weeks along the 90-day path. The 7-day milestone is proof you can build, which is the wall most people never get past.

Do I need a Mac to build an app with Claude Code and Expo?

No. Expo and EAS Build let you build and submit to both stores from any computer, so no Mac is required. You run the app on your own phone with Expo while you build, and EAS handles the native builds in the cloud when it is time to submit.

What do I actually get done in the first week?

You set up Claude Code plus Expo, enroll in both developer accounts, validate your idea, mock up your screens, and build a working core with copy-paste prompts. By day seven you have a native app running on your phone. It is a foundation, not a finished product, and it is the hardest step to reach on your own.

Why enroll in the Apple and Google accounts on day one?

Because both take time to approve you. If you wait until you are ready to submit, that approval wait blocks your launch at the finish line. Starting the enrollment on day one means the accounts are ready when your app is, so nothing external stands between you and shipping.

Can I really build a native app, not just a website?

Yes. Expo produces a real native app that ships to the Apple App Store and Google Play, not a web page in a wrapper. The same single codebase becomes both an iOS app and an Android app, which is why one build reaches both stores.

• Validate an app idea before you build so you do not spend 90 days shipping something nobody wanted. It is cheaper to kill a bad idea on paper than in code.
• Look for a specific problem, a searchable audience, and a gap the big apps left. There are 5M+ apps across both stores, so an idea with no gap is a hard start.
• You do not need to build anything to validate. You need a clear problem, a few real conversations, and search demand you can point to before Claude Code writes a screen.

Why Validation Comes Before the Build

Validation is its own stage in the 9-stage path for one reason: building is now so fast with Claude Code that the real risk moved. The old risk was you could not build the app. The new risk is you build the wrong one beautifully. Proving demand before you write a screen is what keeps your 90 days pointed at something people will actually install.

There are more than 5 million apps across the Apple App Store and Google Play. That is not a reason to quit, it is a map. It means almost every broad idea is taken, and the openings are in the specific gaps the big apps left. Validation is how you find that gap before you commit.

The Three Signals of a Validated Idea

1. A specific problem. Not 'a fitness app' but 'a way for powerlifters to log warm-up sets fast between lifts.' Specific problems have specific, findable people.
2. A searchable audience. Real people are already typing something into the store search bar looking for this. If nobody searches for it, nobody finds your app.
3. A gap the big apps left. The category leader is too broad, too bloated, or ignores your niche. That gap is your opening against 5M+ apps.

TIP: The sharper your niche, the easier everything downstream gets: validation, App Store keyword research, screenshots, and your paywall pitch. Broad ideas fight 5M apps. Sharp ideas own a corner nobody defended.

How to Test Demand Without Building

You can validate an idea before Claude Code writes a single line. The point is to spend hours, not weeks, finding out whether the demand is real.

• Search both stores for your idea. Read the reviews of the closest existing apps and note what users beg for and complain about. Those complaints are your feature list.
• Look at store search terms. If people are searching a phrase and the current results are weak, that is a gap you can fill.
• Talk to five people who have the problem. Not friends being nice, real people who feel the pain. Ask what they use today and what they hate about it.
• Write the store listing first. If you cannot write a one-line pitch that makes the right person want it, the idea is not sharp enough yet.

Reading the Competition Honestly

The apps already in your space are the best free research you will ever get. A one-star review is a feature request. A wall of complaints about the leader being slow, bloated, or expensive is an invitation. You are not looking to copy the leader, because Apple rejects clones under Guideline 4.3. You are looking for what they got wrong and who they ignored.

WARNING: Do not validate by planning to clone a popular app. Apple's Guideline 4.3 rejects spam and clone apps, and it is the number one reason first apps get rejected. Build something distinct, aimed at the gap, not a copy of the leader.

When to Stop Validating and Start Building

Validation can become a place to hide. Once you have a specific problem, a searchable audience, and a clear gap, you have enough. Commit to one idea and move to the design stage. The First-App Sprint puts a working app on your phone in 7 days, so the fastest way to fully validate is often to build the sharp, small version and put it in front of real users.

The goal was never a perfect prediction. It was to avoid the obvious mistake of building something nobody wanted, and to walk into your build with conviction instead of a guess.

FAQ

How do I validate an app idea if I have never built an app?

You do not build anything to validate. You search both stores for similar apps and read their reviews, check whether people are searching for your idea, talk to five real people with the problem, and write the store listing first. If those signals are strong, the idea is worth building. If they are weak, you just saved yourself 90 days.

What makes an app idea worth building?

Three signals: a specific problem, a searchable audience already looking for a solution, and a gap the big apps left open. Across 5M+ apps on both stores, the openings are in sharp niches, not broad categories. An idea with all three is worth committing to.

Can I just clone a popular app that is doing well?

No. Apple's Guideline 4.3 rejects spam and clone apps, and it is the number one reason first apps get rejected. Study the leaders to find what they got wrong and who they ignored, then build something distinct aimed at that gap.

How do I know if there is search demand for my app?

Look at what people type into the store search bar and whether the current results are weak. If people are searching a phrase and the existing apps do not serve it well, that is a validated gap. This is also the foundation of App Store keyword research, so the same work pays off twice.

How long should validation take?

Hours to a few days, not weeks. Once you have a specific problem, a searchable audience, and a clear gap, you have enough. Validation can become a place to hide, so commit to one idea and move to design. The First-App Sprint then puts a working version on your phone in 7 days.

What if I cannot find any gap in my idea?

That is useful information, not failure. If the category leaders already do your idea well and reviews are strong, the market is saturated and you should sharpen the niche or pick a different problem. It is far cheaper to learn this before you build than after 90 days of work.