# 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`.