One score to route founders into the right next step.
The DQ Score should decide what unlocks, who gets routed to which lane, and where human reviewers spend time.
68 / 100 · Build
Close the deployment and proof gaps before you try to accelerate into investor traffic.
Suggested scoring model
Weights are illustrative placeholders. Tune them after observing real operator decisions.
Before any “fast-track” capital route
- Pilot target with named customer profile
- Deployment architecture: edge + cloud diagram
- KPI sheet: latency, cost per unit, throughput
- Unit economics snapshot
- TRL 6 → 7 roadmap over 3–6 months
- No external deployment target
- No customer validation or buyer signal
- No production QA assumptions
- Confusing TRL maturity with market traction
How score maps to product state
These labels are useful in UX, gamification, community and route logic.
0–39 · Explore
Idea shaping only. No routes beyond basic learning and templates.
40–59 · Build
Prototype forming. Unlock quest board, score feedback and perks prep.
60–74 · Pilot-ready
Strong enough to package for real deployment conversations.
75–100 · Capital-ready
Qualified for curated routes, manual review and high-touch service offers.
Operator-recommended actions
Turn the score into a weekly plan so the user always knows where value comes from.
Name the deployment use case
Avoid broad categories. Pin the product to one environment and one measurable pain.
Generate the KPI sheet
Even placeholder metrics are better than abstract claims when they are clearly labelled.
Upload the architecture
This is the turning point from concept theatre into deployment readiness.
Target the right route
Only after the proof exists should the founder see fast-track capital suggestions.