What Not to Buy: High-Risk Signals on Micro App Listings
By Joshua Chen · About / experience · urbanu619@gmail.com
Most bad acquisitions fail the same way: the screenshot looked fine, the transfer did not, and the revenue depended on a rule the platform can change overnight.
Use this as a kill list before deep diligence. Pair it with the full checklist. One hard fail is enough to walk or reprice as scrap.
Category kills (usually do not buy in round one)
1. Businesses that exist only while a platform looks away
Patterns:
- Unofficial story / media downloaders
- Unauthorized IPTV or content bypass tools
- Scrapers and “analytics” that violate a host platform’s ToS
- Automation glued to a single social API with no contractual access
They can show short-term cash. Policy change zeroes the asset. Distribution here is rented without a lease.
2. Famous IP without a transferable license
Names, characters, art, music, sports marks, movie skins — if the seller cannot show:
- Trademark permission
- Asset licenses
- Transferability of that permission to you
- A clean store complaint history
…you are buying a takedown timer.
3. Generic AI shells with no unique data or distribution
Common skins: AI diary, calorie, resume, writing, image, dating assistant — with no proprietary dataset, workflow, or owned channel.
Easy to copy, expensive to acquire users, low switching costs. Price as a weekend prototype, not as a SaaS.
4. “Dev complete” with zero proof of use
UI, source zip, and marketing screenshots are software assets. They are not companies. Compare to rebuild cost (codebase takeover costs); never apply revenue-multiple thinking (asset types).
5. Gray revenue and fuzzy compliance
Do not let a Stripe graph override:
- Copyright
- Privacy and consent
- Right to transfer customer data
- Payments and refunds exposure
- Medical / financial claims
- Age gates
- Store policy history
If compliance is unclear, the downside is not a bad month — it is account loss.
Listing-behavior red flags
Freeze the deal until you have evidence — or leave.
| Signal | Why it matters |
|---|---|
| “No time” and every metric falling | Exit narrative may hide a dying product |
| Huge traffic, tiny revenue, no coherent story | Bot traffic, junk SEO, or broken monetization |
| Screenshots disagree with read-only dashboards | You cannot underwrite fiction |
| Seller blocks read-only verification | No proof, no deal |
| One customer is most of revenue | You are buying a contract, not a product |
| Near-100% churn or extreme refunds | Subscription model is cosplay |
| Critical API or publisher account cannot transfer | You bought a demo |
| Growth dies without the seller’s personal brand | Job, not asset |
| No version history | Forensic and rebuild risk |
| Spike-then-list (revenue juiced into the listing) | Window-dressed trailing twelve |
| Store already warned or dinged the app | Transfer may inherit the problem |
| Depends on scraping or bypassing platform rules | Policy risk is the product |
Soft caution (buy only with a fix you own)
These are not automatic kills if you have a concrete 90-day repair:
- Strong distribution, weak paywall — and you know how to price that niche
- One platform (iOS only) — and you will ship the other
- English-only — and you have a real localization plan into a market you understand
- Tool without content/SEO — and content is your channel
The test: write the fix in one paragraph. If you cannot, you are hoping, not buying.
Fast filter before you open the data room
- Can the store listing, domain, and payment rails transfer under official rules?
- Is revenue verified read-only, with refunds and concentration visible?
- Does the product die if one platform changes a ToS clause?
- Is IP and data transfer documented, not assumed?
- Would you still want the zip at rebuild cost if users and ranking vanished tomorrow?
Two or more “no” → do not spend diligence hours. Build or hire instead.
If nothing on the market clears the bar
That is a product signal, not a personal failure. Many buyers discover they need a custom build with clean ownership from day one — or a rescue of a deal that is good except for engineering debt.
- Custom build / rescue engineering: urbanu619@gmail.com
- Managed ops after a clean close: urbanu619@gmail.com
- Intake: App Rescue Radar
Related:
- Due diligence checklist
- Cost of taking over a codebase
- Three asset types
- Listing patterns (method demo)
- Why micro-SaaS multiples look “cheap”
This page is a screening framework, not legal advice.