how we score moat depth.
rubric version v3 · last updated 2026-05-02
Tier (WEEKEND / MONTH / DON'T) tells you how long it'd take to build the thing. It doesn't tell you whether the incumbent has anything keeping users from switching to your clone. That's a separate question, and it's the one moat depth answers.
We score every report against six axes, each 0–10. The math is deterministic — derived from the per-report normalization projection (canonical components, capabilities, attributes) and the curated taxonomy (commoditization levels, moat tags). No LLM is in the scoring loop, on purpose. The aggregate is a weighted average of the six.
the six axes.
Capital
What the incumbent had to invest to build the thing. Audits, licensing, banking relationships, training infrastructure — capex you can't shortcut your way around.
how it's scored: Derived from the buildability tier (DON'T = 7, MONTH = 4, WEEKEND = 1), plus a boost for capex-flagged est_cost lines (audit, licensing, regulatory, banking, GPUs, training infra, attorneys, interchange — capped at +3), plus a +2 boost when est_total is a non-numeric descriptive string (the LLM gave up trying to put a number on it). SOC 2 is excluded because it's table-stakes, not a real moat.
Technical
Depth of the incumbent's underlying engineering. The R&D you can't recreate by gluing OSS libraries together.
how it's scored: Inverse of the buildability score (lower score = harder problem) at 0.7 weight, plus a boost from `nightmare`/`hard` challenge counts (capped at +4). The buildability score IS our judgment of how hard the incumbent's R&D is, so we use it directly here.
Note: Capital and Technical deliberately ignore the projection's cost / component data, because that data describes the indie hacker's clone stack, not the incumbent's actual investment. The incumbent's moat is precisely what you can't buy off the shelf.
Network
Users compound users — the product gets more valuable as more people use it.
how it's scored: Counts how many of the report's matched capabilities carry network-effect tags (multi_sided, ugc, marketplace, viral_loop). 1 capability → 4; 2 → 8; 3+ → 10.
Switching
How sticky customer data and workflow state are once they're in.
how it's scored: Counts capabilities tagged for switching cost (data_storage, workflow_lock_in, integration_hub). Same 4-per-capability curve.
Data
Proprietary data that accumulates with use, and would be expensive or impossible for a clone to recreate.
how it's scored: Counts capabilities tagged for data moats (proprietary_dataset, training_data, behavioral). Same 4-per-capability curve.
Regulatory
Real licenses, audits, regulatory exposure that legally bars indie hackers from operating.
how it's scored: Counts capabilities tagged for regulatory moats (hipaa, finra, gdpr_critical, licensed). Same 4-per-capability curve. Note: SOC 2 deliberately does NOT count — every B2B SaaS would otherwise score artificially high.
the aggregate.
Weighted root-mean-square across all six axes. Equal weights — each axis is roughly as important as the others when you're deciding whether to bother attacking an incumbent. RMS rather than arithmetic mean because real moats are often specialist: Stripe's defensibility lives in capital + technical + regulatory, with the other three axes legitimately near zero. Averaging that to 5/10 misrepresents how hard it actually is to displace. RMS rewards concentration without changing anything for products whose strength is spread evenly across the six.
We'll re-tune the weights themselves once we have enough scored reports to see real clustering. When we do, the rubric version bumps and every report's score is recomputed from scratch.
what we don't score.
Distribution and brand are not modeled. They matter — sometimes more than any of the six axes — but you cannot derive distribution moat from a homepage scan. Putting a number on it would weaken the credibility of the rest, so we left it out. When you're looking at a low-aggregate score on a product with obvious distribution dominance, that's the gap to fill in yourself.
Capability of the team behind the product is also not modeled. Same reason. A genuinely brilliant engineering org can hold a moat that the structural axes don't see.
why deterministic.
The point of the score is to be defensible. Every number on a report card can be traced back to a specific component, a specific capability tag, or a specific cost line in the projection. If the score is wrong, the input data is wrong, and the input data is fixable. An LLM-authored score has none of those properties.
The taxonomy itself — which capabilities exist, which moat tags they carry, what each component's commoditization level is — is hand-curated and reviewed in code. The admin tools at /admin/unknowns use Claude to suggest additions, but a human decides.
Source-of-truth: lib/normalization/moat.ts · lib/normalization/taxonomy/