AI Monetization Evaluator
A decision aid for "should I build this to make money?" — applies a fixed rubric so the answer is grounded in demand reality, not enthusiasm.
Inspired by the patterns catalogued in bleedline/aimoneyhunter (a popular Chinese-language collection of AI side-hustle methods). This skill is an original rubric, not a copy of that content.
When to Use
- User pitches a product / side-project / SaaS / browser-extension idea and asks if it'll sell
- User wants a go/no-go before investing build time
- User is choosing between several monetization directions
- User has a built product that isn't making money and wants to know why
Core Principle
The bottleneck of a money-making product is almost never the code — it's demand. Most failed AI products are technically fine but solve a problem nobody pays for. So evaluate demand before praising the build.
The single most important question, asked first, every time:
"What does the user currently do instead, and why is that painful enough to pay to avoid?"
If there is no painful status quo, the idea is a "nice to have" and will struggle to convert — say so plainly.
The Rubric (score each 0–2)
Walk the idea through five axes. Score honestly; a high total with an honest zero on "demand hardness" still fails.
| # | Axis | 0 (red) | 1 (amber) | 2 (green) |
|---|---|---|---|---|
| 1 | Demand hardness | "nice to have", free substitutes everywhere | mild recurring annoyance | "can't work without it" / costs real money/time today |
| 2 | Niche focus | broad platform ("an AI that does everything") | semi-vertical | one sharp use-case for one clear user |
| 3 | Payment willingness | users expect it free | unclear | comparable tools already charge & people pay |
| 4 | Distribution | "build it and they'll come" | one untested channel | a concrete, reachable channel where the target user already gathers |
| 5 | Unfair advantage | anyone can clone it in a weekend | minor edge | real moat (skill, access, data, audience, hard-won know-how) |
Scoring guide:
- 8–10 — Strong. Pursue, but still validate payment with a real test before heavy build.
- 5–7 — Mixed. Identify the lowest axis and fix that before building more. Usually demand or distribution.
- 0–4 — Weak as stated. Either re-sharpen the niche/demand, or drop it. Don't out-engineer a demand problem.
Workflow
- Restate the idea in one sentence — force clarity. If you can't, the idea is too vague to evaluate; ask the user to narrow it.
- Ask the core question (status quo + pain). Don't skip — this gates everything.
- Score all five axes, one line of reasoning each. Be the skeptic, not the cheerleader.
- Name the weakest axis — that's the real bottleneck.
- Give 1–3 concrete validation steps that test the weakest axis cheaply (a landing page, a manual-service MVP, a pre-sale, a poll in the target community) — never "go build the whole thing".
- Verdict: pursue / re-sharpen / drop, with the total score and the one thing to fix first.
Anti-patterns to Call Out
- "GPT wrapper for everything" → no niche, no moat. Push for one vertical.
- Building before validating demand → the most expensive mistake. Validate payment willingness with the smallest possible test first.
- Confusing "launched" with "discovered" → being on an app store ≠ having users. Distribution is a separate, harder problem than building.
- Pricing by gut → if pricing wasn't tested against a comparable, flag it.
- Grey-area plays (reselling API keys/accounts, ToS-violating arbitrage) → flag the compliance/sustainability risk; don't recommend as a core business.
Output Shape
Keep it tight:
Idea (one line): …
Status quo & pain: …
Scores:
Demand hardness X/2 — …
Niche focus X/2 — …
Payment willing. X/2 — …
Distribution X/2 — …
Unfair advantage X/2 — …
Total: X/10
Weakest axis: …
Validate first: 1) … 2) …
Verdict: pursue / re-sharpen / drop — fix [X] first.