ROI and how to evaluate Sphere ## The fair comparison Ask: for the same production-ready outcome (same platform or change set you would ship), how do these compare? | KPI | What to count | |-----|----------------| | X — AI capacity | Tokens or subscription AI usage consumed to reach the outcome | | Y — Scope delivered | Production-ready work completed (features/services/checks that ship) | | Z — Human interactions | Prompts, re-contexting, babysitting failed runs, hand-offs between BA/Dev/Architect/QA | Compare Sphere (with coding agents) against driving a coding harness alone (for example Cursor- or Claude-style IDE/CLI agents) on that equal outcome. Do not invent numeric X/Y/Z values in chat or marketing copy unless a published measurement exists. ## Why Sphere tends to improve Z (and often X) - Persistent Architecture as Code — the SCAN/Sphere model is not rebuilt from a blank prompt each turn. - Approvals at goal and plan — people decide once; agents execute against the approved plan. - Built-in verify and fix — failures are diagnosed in the loop instead of becoming new human tickets. - One control plane — BA, Dev, Architect, and QA share board, plans, and runs instead of translating across tools. ## How to run a pilot 1. Pick a bounded, production-relevant change (multi-component preferred). 2. Deliver it once with the team’s current harness-only practice; note capacity used and human touchpoints. 3. Deliver a comparable change with Sphere; note the same KPIs. 4. Compare X, Y, and Z — and qualitative collaboration (who had to watch the tools). ## What not to say - Guaranteed percentages of time or money saved - “Always cheaper than [named product]” without a measured pilot - Inflated case studies or customer counts you cannot share (see sensitive-questions for internal deflection rules — do not quote that file publicly) For pricing structure (not dollar amounts), see plans-and-pricing.md. For approach comparison, see vs-coding-harness.md.