Stainless Transition Demo-Call Playbook

Internal use only. Use this checklist for Stainless-related discovery, inbound handling, and demo calls so the team can move quickly without overclaiming under live pressure.

Fit Honesty Opener

Start every serious Stainless-transition conversation with this framing:

Valkyr is not a one-for-one Stainless clone. Stainless is strongest as a spec-to-SDK/interface layer. Valkyr is built around spec-to-secure-running-stack: generated backend, TypeScript client surfaces, runtime controls, RBAC posture, memory, deployment, and operational proof.

Use this as a qualification filter, not a disclaimer dump. If the buyer wants broad multi-language SDK/docs parity only, we may be the wrong first call today. If the buyer has runtime, security, memory, workflow, or app-generation pain, keep going.

Approved Contrast

Topic	Stainless	Valkyr
Primary promise	Spec-to-SDK/interface	Spec-to-secure-running-stack
Center of gravity	SDKs, docs, MCP/server interface generation	Generated Spring backend, TypeScript client, workflow runtime, RBAC, GrayMatter memory, deployment controls
Best-fit buyer pain	Client-library and docs continuity	Need a running governed app stack from an OpenAPI contract
Proof burden	SDK quality, language coverage, docs freshness	Runtime behavior, generated client freshness, RBAC/security posture, isolated instance readiness
Honest boundary	Do not imply Valkyr has full Stainless language parity unless verified	Do not sell Valkyr as only an SDK generator

Matrix Prompts

Use these prompts to classify capabilities live. Label incomplete features clearly.

Status	Prompt	Example use
Ready	Can we show it in the current product or repo with evidence?	TypeScript client freshness check, ThorAPI-generated backend, OpenAPI-driven model surface
In progress	Is there an active issue or PR with a credible path?	Security hardening, GrayMatter RBAC fixes, isolated instance polish
Planned	Is it on the roadmap but not demoable?	Broader SDK language parity if not currently verified
Not fit	Would claiming fit distort what the product is?	Pure SDK/docs migration where runtime/security/memory are out of scope

Qualification Questions

1. Are you trying to preserve SDK/docs/MCP continuity, or are you trying to produce a governed running service from the spec?
2. Which languages and docs outputs are hard requirements, and which are nice-to-have?
3. Does your spec already describe auth, tenancy, billing, files, workflows, or privileged operations?
4. What breaks if generated clients drift from the OpenAPI contract?
5. Do you need tenant isolation, RBAC policy evidence, SecureField posture, and audit-ready workflow history?
6. Do agents need durable schema-aware memory tied to business objects, or are chat transcripts enough?
7. Are you blocked by production readiness, security review, deployment repeatability, or internal proof?
8. Who signs off on fit: platform engineering, security, product, founder, or procurement?

20-Minute Spec-to-Stack Mapping Call

1. First two minutes: state the fit honesty opener and ask for the buyer's real risk.
2. Minutes 2-6: map their current Stainless/SDK/docs/MCP dependency and must-keep outputs.
3. Minutes 6-10: map runtime pain: auth, tenancy, RBAC, billing, files, workflows, deployment, and observability.
4. Minutes 10-15: show the Valkyr path from OpenAPI spec to generated stack, TypeScript client, GrayMatter memory, and TrustFabric/RBAC/SecureField posture.
5. Minutes 15-18: classify gaps as Ready, In progress, Planned, or Not fit.
6. Final two minutes: agree on one next step: pilot spec, proof gap, architecture review, or polite no-fit close.

Demo Evidence Checklist

• Spec-to-stack readiness: use the Spec-to-Stack Readiness Matrix as the canonical call reference.
• OpenAPI spec: show the source contract that drives generation.
• ThorAPI stack: show generated backend/runtime artifacts and where custom behavior stays thin.
• TypeScript client freshness: show the freshness or drift-proof path tracked by issue #3178 and related CI evidence when available.
• GrayMatter memory: explain it as schema-aware operational memory tied to real business objects, not abstract "AI memory" magic.
• TrustFabric/RBAC/SecureField posture: show auth boundaries, RBAC/ACL intent, and sensitive-field posture without claiming unverified certifications.
• Isolated instance status: show whether the customer runtime path is ready, in progress, or planned.
• Proof gaps: name missing evidence before the buyer has to ask.

Objection Handling

"Anthropic bought Stainless, so should we move now?"

Do not fear-pitch Anthropic. Say that acquisition news can trigger dependency review, but the right decision depends on whether the buyer needs SDK/docs continuity, generated runtime, or governed app-stack delivery.

"We need broad SDK parity."

Ask which languages are contractual. If broad multi-language parity is the core requirement and Valkyr cannot prove it today, label that as Not fit or Planned. Pivot only if runtime/security/memory pain is also present.

"MCP already solves this."

Agree that MCP is valuable for tool and app boundaries. Then separate interface access from governed runtime: MCP does not automatically provide tenant isolation, RBAC policy proof, generated backend behavior, billing, deployment, or memory provenance.

"Is this production ready?"

Answer by surface, not by blanket confidence. Use Ready / In progress / Planned / Not fit. For each production-critical claim, point to evidence: tests, PRs, staging status, or a named proof gap.

"GrayMatter sounds abstract."

Translate it into a business object graph: memory entries, retrieval receipts, semantic context, projects, workflows, customers, opportunities, files, and agent state under RBAC. Avoid metaphors when the buyer is asking for operational proof.

"We can build this ourselves."

Assume they can. The question is time-to-proof and maintenance burden: generated contract discipline, drift checks, RBAC, deployment, memory, and support workflows. Offer a pilot if their internal build cost is uncertain.

Escalation Rules

• Founder-led reply: strategic buyer, acquisition-sensitive context, pricing/partnership request, or narrative risk.
• Product/docs gap: missing public explanation, unclear matrix state, or buyer asks for a shareable artifact we cannot send cleanly.
• Engineering proof gap: buyer asks for a specific security, runtime, generated-client, deployment, or tenant-isolation claim that lacks current evidence.
• Poor-fit prospect: pure broad SDK parity, procurement-only fishing, or no runtime/security/memory pain.

Trust Guardrails

• Do not claim any company used Stainless unless publicly verified or stated by the prospect.
• Do not fear-pitch Anthropic.
• Do not imply multi-language SDK/docs/MCP parity unless verified.
• Label incomplete features clearly.
• Use verified public competitor claims only and keep evidence links in the war-room packet.
• Say "I do not know" or "we need to verify that" when evidence is missing.

Related Routes

• Public FAQ/capability matrix: #3453
• Readiness/limitations matrix: #3311
• GrayMatter quickstart: #3310
• MCP safety checklist: #3231
• Spec drift / contract-test proof: #3178
• CRM/api-0 RBAC follow-through blocker: #3325