AI Forge · Notes

How AI Forge Decides Which App Complaint Is Worth Fixing

Most "AI-built app" pitches start with a feature list. Ours starts with a spreadsheet of other people's one-star reviews. Before a single line of code gets written, we go find out — in the reviewer's own words — exactly what's broken about the category we're about to build in. Here's the method, and what it actually turned up the first two times we ran it.

Step 1: read the reviews nobody else reads

App-store reviews are a strange kind of public record: brutally honest, timestamped, and almost never read past the star average. We pull the one- and two-star reviews for the leading apps in a category and read them in full, not just skim for keywords. A star rating tells you someone is unhappy. The review text tells you exactly why, and "why" is the only part you can build against.

Step 2: only count what clears a real bar

A single angry review isn't a product requirement — it's an anecdote. We only act on a complaint cluster once it clears an evidence bar: a minimum number of independent reviews, making the same specific complaint, at a meaningful share of everything we could classify. One person's pet peeve doesn't get a feature. A pattern across hundreds of strangers does.

Two runs, so far

A few of the actual quotes, because the whole point of this method is that we don't paraphrase away the signal:

"An ad after almost every question."

"First off there's immediately a paywall/fee that should just be in the App Store rather than leverage the sunk cost fallacy."

"Great app but it deletes your progress if you change your goals. I'm tired of missing out on my history."

Step 3: build only what the evidence supports

Once a cluster clears the bar, every resulting feature has to trace back to a specific complaint. No bonus features, no "while we're at it." If a complaint mentions data loss on editing a goal, the fix is "editing a goal never touches recorded history" — not a redesign of the whole app around it.

Step 4: prove it, don't just claim it

Each build ships with a written self-check that asserts the promises directly — that there's no purchase gate in the code, that editing a goal can't delete a day, that a 500-item stress test doesn't break anything. The check reads the logic straight out of the shipped file, so the test can't quietly drift away from what the product actually does.

Where things stand

Both builds above are finished and self-checked. Neither is published yet — new software from AI Forge goes through a human approval gate before anyone outside the company can use it, the same as everything else Penloom ships. This note exists so the method is visible before the product is, which is the opposite of the usual order and, we think, the more honest one.