You built the app and know it works on your phone, but Apple rejects it without making the problem obvious. Solo founders face a specific version of this problem: full responsibility for app quality with no QA staff and no structured process for catching bugs before users do.
A recent annual transparency report showed that in 2024, reviewers examined over 9.1 million app submissions and rejected more than 2 million of them, roughly 23%. Performance violations, including crashes and incomplete features, were the largest category of App Store rejections. Most of those rejections are preventable with a simple process.
Performance bugs cause more rejections than everything else combined
Performance bugs deserve your first QA pass because store review often fails on basic app quality before anything else. Focus limited testing time on crashes and broken core flows first.
A 2024 detailed breakdown recorded 1,235,471 performance-related rejections, out of roughly 1.9 million total rejections. Legal, design, business, and safety violations together did not match that number. Crashes and non-functional screens are common reasons apps fail review.
Google Play applies similar standards. In 2025, over 1.75 million policy-violating apps were prevented from reaching Google Play. Android apps also face specific crash and ANR (Application Not Responding) rate thresholds tracked through Android Vitals. Exceeding those thresholds can negatively affect your app's ranking and discoverability on Google Play.
For solo founders, functional testing of your core features is the gate between you and the app stores.
Match testing intensity to your product stage
Your QA process should match the maturity of the product. Too much process too early wastes time, and too little process after launch creates failures that are harder to recover from.
Indie builder discussions show a practical pattern: scale QA effort to product maturity. That approach fits solo teams because it keeps effort tied to risk.
MVP stage
Test by using the app yourself. Click every button and fill every form. If something crashes, fix it. Do not write automated tests or build formal processes. Your goal is validation.
V1.0 stage
This is prime time. Real users will interact with real data. Build a plain-English testing checklist, then use beta testers and physical devices to run it. Invest time proportional to the damage a bug would cause.
Iteration stage
Add new test cases to your existing checklist for each feature. Do not rebuild QA from scratch with every update.
Healthcare and finance apps warrant rigorous testing at every stage; the same rule applies to any safety-critical app.
A testing workflow built for one-person teams
Run solo QA as a repeatable system before every launch and update. A living checklist and adversarial self-testing, guided by clear priorities, will catch more bugs than occasional deep testing.
Build a plain-English checklist
Use a simple document with checkboxes covering every page, form, button, and integration in the app. One Indie Hackers post described the method as deliberately minimal: simple enough to maintain, useful enough to prevent forgotten edge cases.
Before your first test pass, walk through the app and list:
- Every screen and navigation path
- Every form, including signup, login, and content creation
- Every button that triggers a backend action
- Every third-party integration, including payment providers and email or API services
This checklist gives you a baseline for every future release. Update it with each new feature instead of starting over.
Try to break your own app
Before anyone else touches it, act like a confused or hostile user. Use the same community thread for adversarial prompts like these:
- Enter invalid data in every form field: empty inputs, special characters, maximum-length strings
- Upload wrong file types to any upload field
- Start a payment flow, then cancel it mid-process
- Disconnect your network connection during a transaction
- Log in as two different users and try to access each other's data by editing IDs in the URL
These checks surface fragile assumptions fast. They also expose security and state-management problems before real users do.
That last test catches authorization gaps immediately. If user A can see user B's data by changing a number in the URL, you have a serious problem.
Prioritize by damage, not coverage
You can not test everything equally. Concentrate effort on the paths where failure costs the most:
- Authentication and authorization. Can someone access data they should not see?
- Payment flows. Initiation, completion, cancellation, and failure states.
- Core value feature. The primary thing your app exists to do.
- Data integrity. Does user data save and load correctly?
This order keeps your effort tied to user impact. A cosmetic bug on a settings page will not sink your launch. A broken checkout will.
Free tools that replace paid QA infrastructure
A small stack of free or low-cost tools can cover web UI tests, beta distribution, device testing, API checks, and production monitoring. Pick tools based on the job each one does.
For web UI testing, Playwright is fully free with no paid tier. It supports Chromium, WebKit, and Firefox, includes mobile emulation, and runs tests in parallel. Setup takes one terminal command.
For iOS beta distribution, TestFlight supports external testers with built-in screenshot feedback and crash reporting. It requires the Apple Developer Program membership but has no additional cost.
For Android device testing, Firebase Test Lab runs your app on real physical devices in Google data centers. Its Robo test automatically crawls your Android app with no pre-written test code. Upload an APK to run automated UI crawling through the Robo test feature.
For API testing, Hoppscotch offers unlimited workspaces, collections, and requests on its free plan. It works offline as a PWA and can be self-hosted for full data control.
For error monitoring in production, Sentry.io provides frontend and backend error tracking on a free tier. Sentry lets you detect and fix production issues within minutes after launch.
What Apple and Google require before you publish
Store approval depends on more than whether the app works on your device. Missing review requirements can block submission even when the product feels ready. Small omissions here often cause avoidable rejection.
Apple App Store requirements
- The app must be tested on a physical device, with simulator testing treated as insufficient
- All placeholder text and template content must be removed
- A working demo account must be provided if the app requires login
- Backend services and app functionality should be available during the review window, and reviewers test the submitted build using the access you provide, such as demo accounts or reviewer instructions
- A privacy policy URL is mandatory for all apps
- Apps whose code or third-party SDKs access Apple's Required Reason APIs must include a privacy manifest file; this requirement has been in effect since May 1, 2024.
If your app depends on login or remote services, including private APIs, verify each item before every submission.
Google Play requirements
- New personal developer accounts (created after November 2023) must complete a closed testing period: 12 opted-in testers for at least 14 continuous days before production publishing
- New apps must target Android 15 (API level 35) or higher as of August 31, 2025
- Apps targeting Android 15 or higher must support 16 KB page sizes as of November 1, 2025
These requirements affect your launch schedule as much as your build settings. The 14-day closed testing requirement deserves special attention. Assemble your tester group before your build is ready. Build this timeline into your launch schedule from day one.
Use Google Play's free pre-launch report
When you upload a build to the closed testing track, the platform can automatically run it against a range of real Android devices. This free report checks stability and performance, including accessibility problems, across hardware you likely do not own. Upload to the internal testing track before promoting to production. It is the minimum viable device compatibility check.
Turn beta testers into your QA layer
Other people will break your app in ways you will not predict. Beta testers extend your coverage across different devices and usage patterns, and they are the closest thing a solo founder has to a QA team.
Beta testers often find bugs you miss alone. They use the app in ways you did not anticipate, on devices you do not own, with assumptions you do not share.
Recruit from your waitlist and from social or niche communities. An Indie Hackers post described a rhythm that worked: every new TestFlight build triggered a community post about the smallest visible change. Consistent updates gave people a reason to keep testing.
Feedback collection matters as much as recruitment. A dedicated Slack channel per tester, fully async, can support a small weekly time commitment. No forms, no ticketing system. At early stages, unstructured conversation produces more useful signal than formal bug reports.
Expect ghosting from Reddit and forum recruitment. One analysis discussed the dynamics of helping people in Reddit threads. Reframe your ask: instead of "beta test my app," try "can I show you one specific thing for 10 minutes?" Lower commitment often yields higher follow-through.
Built-in QA features when building with Anything
If you build with Anything, we handle several QA fundamentals for you, so you can spend more time testing app logic and release risk. We support an iterative text to app workflow instead of one-shot generation. Every project includes separate preview and production databases, so test data never touches your live app. You get an in-browser app preview, and you can test on a real device through Expo Go by scanning a QR code.
We also support standard iOS testing pipelines. iOS builds route through TestFlight for beta testing before App Store submission. Android is still in development, so use the general Google Play testing guidance in this article for Android planning.
On the Max plan, we go further. Max acts as an AI agent that opens your app in a real browser, identifies visual and layout issues, and runs end-to-end tests of flows like checkout and signup. You can prompt it to "test my app and fix anything that is broken" or "walk through the signup flow and make sure everything works."
If you are on the Free or Pro plans, supplement with the free tools covered earlier: Playwright for web testing, Hoppscotch for API testing, and Sentry for production error monitoring. The combination covers the gaps.
Catch the bugs that cause crashes or block app store approval, especially when user data is involved. A simple checklist backed by adversarial self-testing gets you there faster when a small beta group is using each build. Get started with Anything and ship something worth testing.
