Sixty-eight modules, zero customers. That is not a product, that is a demo farm — 68 shallow features breeding maintenance debt with no user ever validating one. Why is this not the classic feature-factory failure?

The full executive answer

It is the right challenge, and I will not pretend the risk is zero. Here is why the breadth was deliberate rather than undisciplined. First, the modules are not 68 independent products — they are views over one shared engine: one assessment substrate, one AI pipeline with shared prompts, schemas and safety layers, one signals registry, one export system. The marginal module is a new lens on shared plumbing, not a new codebase. That is why one person could build it and why maintenance does not scale linearly with module count.

Second, breadth is the category bet. Our closest competitor overlaps us at roughly 51% — the whole thesis is that boards need the full decision arc in one governed place, and you cannot demonstrate an operating system with six apps. The tiering enforces focus in practice: a Trial user meets only 10 modules, Basic 16, Pro 40 — the surface a real user experiences is curated by tier, and the tier map is itself our prioritisation hypothesis about which jobs matter first.

Third — the honest part — you are right that none of it is usage-validated, so the kill discipline is pre-committed: every module’s usage is telemetered from day one, the health score already tracks feature breadth per account, and modules that show no engagement across early cohorts get MoSCoW-downgraded and folded back or retired rather than defended. In Kano terms, launch breadth was about ensuring the delighters exist somewhere in the surface; the first hundred users tell us which ones they were, and the rest are candidates for pruning, not pride.