To reverse engineer an app, you pick a product that is already selling, read its one- and two-star reviews to find the specific complaints the developer never fixed, and build the version that fixes them. That review pile is not feedback — it is a free product roadmap written by paying customers. A 19-year-old used exactly this loop to build an AI photo meal tracker and sell it for $30 million in two years.

The part most people skip is what happens after the research. He did not open a code editor next. He fed the research into a Product Requirements Document, and that one document is what turned a pile of complaints into a shippable app.

Get the Free Guide

The free guide walks the entire loop on a real meal tracker app — the exact review-mining prompt, the gap table it produces, and the PRD prompt that turns it into a build plan.

Get the free Reverse-Engineer Playbook →

Why Should You Reverse Engineer an App Instead of Inventing One?

Reverse engineering removes the single most expensive unknown in software: whether anyone wants the thing. A popular app in your niche has already proven demand, proven pricing, and proven distribution — three questions that normally take a year and a lot of money to answer.

Inventing from scratch means you validate an idea and build it at the same time. Remixing means you only have to be better at one specific thing, and the market has already told you which thing that is.

Here is the difference in practice:

This is the same logic behind cloning an $800K app in 15 minutes with Claude Code — you are not stealing a codebase, you are borrowing a validated problem.

How Do You Find the Gap in a Popular App?

You find the gap by reading the negative reviews, because a one-star review is a paying customer describing the exact feature they would switch apps for. Ratings tell you nothing useful; the written complaints are the whole asset.

Take a photo meal tracker — the category that produced the $30 million exit. Open the App Store or Google Play listing for the leading one, filter to one- and two-star reviews, and copy 50 to 100 of them into a text file. Then run them through Claude Code:

1
2
3
4
5
6
7
8
9
10
11
Here are 80 negative reviews for [App Name], a photo-based meal tracking app.

Group them into recurring complaint themes. For each theme, give me:
- the theme in one line
- how many reviews mention it
- 2 verbatim quotes
- what a competing app would have to do to fix it
- whether fixing it is a feature, a pricing change, or an accuracy problem

Rank the themes by how often they appear. Ignore one-off complaints
and anything about a temporary bug or outage.

For meal trackers, the same four themes come back almost every time: the photo recognition guesses portion sizes badly, the free tier caps scans at a number that makes the app useless, restaurant and home-cooked meals are not in the database, and the subscription is hard to cancel. Every one of those is a build instruction.

Your job is to pick one theme and be dramatically better at it — not to fix all four. “The meal tracker that gets portion sizes right because it asks you one follow-up question” is a product. “A better meal tracker” is not.

What Is a PRD and Why Does It Pre-Write Your App?

A Product Requirements Document, or PRD, is a single file that defines who you are building for, the specific pain you are solving, the screens involved, the data model, and the libraries you will use. It matters because Claude Code builds from a spec far more reliably than it builds from a conversation.

The mechanical benefit is the libraries. When the PRD names the authentication provider, the payment provider, the image model, and the database, roughly 20% of your app is already written before you touch a keyboard — it exists as packages you are wiring together rather than code you are authoring.

Feed the research in and ask for the document:

1
2
3
4
5
6
7
8
9
10
11
12
13
Using the complaint analysis above, write a full PRD for a photo meal
tracking app that wins on portion-size accuracy.

Include:
1. Target user in one paragraph (be specific, not "health-conscious people")
2. The one problem we beat the incumbent on, and how we prove it
3. Core feature list for v1 — maximum 5 features, ruthlessly cut
4. Screen-by-screen user flow
5. Data model
6. Recommended libraries and APIs, with why for each
7. What we are deliberately NOT building in v1

Save it as PRD.md in the project root.

Keep PRD.md in the repository root. Every later session of Claude Code reads it and stays on-spec instead of drifting — the same reason a structured Claude Code project setup outperforms freestyling.

What Does the Whole Loop Look Like End to End?

The full loop is five steps and takes an afternoon, not a quarter:

1. Pick the app. Choose a paid or freemium app in your niche with strong download numbers and at least a few hundred reviews.
2. Pull the negative reviews. Copy 50 to 100 one- and two-star reviews into a text file.
3. Cluster the complaints. Run the review-mining prompt above and rank the themes.
4. Pick one gap. Choose the theme you can beat decisively, and write it as a single sentence.
5. Generate the PRD. Run the PRD prompt, save PRD.md, then start building against it.

Most builders do step one and jump straight to code. Six months later they have a half-built app with no clear reason to exist. The three research steps in the middle are the whole difference — and they are the cheapest steps in the list.

If you want the version of this that makes money on unglamorous products, read how boring apps make $80K per month with Claude Code.

FAQ

Is reverse engineering an app legal?

Yes, when you are copying the concept rather than the code or the brand. Building a meal tracker because meal trackers sell well is ordinary competition; copying a competitor’s source code, assets, name, or icon is not.

How many negative reviews do I need to read?

Between 50 and 100 is enough to see the recurring themes clearly. Past that you stop learning anything new, because the same four or five complaints repeat.

Can Claude Code build the whole app from the PRD?

It can build a working first version, but you still direct it. As of July 2026, the reliable pattern is to have Claude Code implement one screen or one feature per session, checking against PRD.md, rather than asking for the entire app in one prompt.

What if the app I want to copy has no bad reviews?

Then look at its support forum, its subreddit, or the comments on its social posts. Complaints always exist somewhere — the app store is just the easiest place to collect them.

Do I need to know how to code?

No, but you need to be able to read what the agent produces and say when it is wrong. That is the actual skill: specifying clearly and reviewing honestly.

Start With Someone Else’s Reviews

You do not need an original idea. You need a proven app, a pile of complaints about it, and a PRD that turns those complaints into a build plan. That sequence is what a 19-year-old turned into a $30 million exit, and none of the three steps requires anything you do not already have access to.

Pick the app in your niche this week, pull the reviews, and let Claude Code write the PRD. If you want the full system — the prompts, the project structure, and the builds — come Join the Vibe Coding Build →.