| 01Model concentration | How tied is the platform to one provider's roadmap? | Several providers are first-class and you can change the default model per task. | Two providers are wrapped; a third needs custom integration work. | One provider's models behind an open-sounding brand. |
|---|
| 02Stack-exit cost | If you leave in 18 months, what comes with you? | Prompts, projects, files and logs export in documented, standard formats. | Prompts export; configurations and tuned assets stay behind. | No export path; everything lives in the vendor's tenant. |
|---|
| 03Governance evidence | What can you verify before the pilot, not after? | Current third-party audit reports, a sub-processor list, a signed DPA, audit logs and role-based access, all provided on request. | A report exists but its scope does not clearly cover the product you will use. | A badge or a marketing page and nothing you can hand to your security team. |
|---|
| 04Multi-model parity | Can a non-engineer try several models on the same task? | Any model is one selection away inside the same surface and conversation flow. | A model picker exists, but each switch means a fresh setup. | One model only; trying another means buying another product. |
|---|
| 05Time to first outcome | How long from signed PO to a real user doing real work? | Days: identity and connectors are configuration, not a project. | Weeks: a partner-led implementation is expected. | Months: every connector is a paid engagement. |
|---|
| 06Price predictability | Seat, credit pool, token meter or negotiated agreement? | Published list price per seat and a clear rule for what happens at the allowance. | Seat plus a meter, with overage you can estimate. | Pure consumption with no ceiling by default. |
|---|
| 07Workforce reach | Does it serve the engineers and the other 90% of staff? | A chat-grade interface for everyone, with an API for builders. | Strong for one group, awkward for the other. | A developer sandbox presented as a company-wide platform. |
|---|