Go-Live and GTM Plan
Status: EXECUTION PLAN — gated, not yet authorized for external launch
Owners: Founder (commercial go/no-go) · Platform (technical release) · Product Marketing (narrative)
Last verified: 2026-07-22
Precedence: Platform Lock v1.0 and the
Architecture Lock govern product and
runtime behavior. The Commercial OS governs
positioning, pricing, and launch claims.
1. Decision and purpose
This is the single operating plan for taking IntegrateWise from a source-ready
platform to a controlled technical release, design-partner proof, and then a
public narrative launch. It deliberately separates those moments:
- Controlled technical availability makes the supported SDK contracts and
governed services available only after their release gates pass. - Commercial proof runs guided ecosystem activation around a material,
governed operational outcome. A specific Workbench or connector may be the
proof path; neither defines the product category. - Public T1 launch introduces the Operational Capability Platform for the
AI Era: people, AI surfaces, systems, Workbenches, governance, and
continuity in one connected product story. It happens only after the proof
gate, not because a date arrived.
Nothing in this plan changes the product contract: the Spine remains the
source of truth; the Twin prepares and proposes but never acts without approval;
and governance is a hard gate. External copy must use the terminology and
claims rules in the Commercial OS.
2. Release scope
Supported public contracts
| Surface | Consumer promise | Boundary |
|---|---|---|
@integratewise/sdk | Typed Gateway client for discovery, preparation, approval, and audit-aware action flows | It does not expose direct provider execution. A caller resolves, prepares, and presents an approval before an action can run. |
@integratewise/spine-schema | Shared TypeScript contracts for canonical Spine entities and workbench projections | It is a schema contract, not a direct database client. |
| Gateway Platform catalogue | Read-only discovery at /api/v1/platform/* for packages, services, endpoints, and OpenAPI | It exposes Gateway contracts only; Worker bindings, service addresses, provider credentials, and tenant data stay private. |
| Gateway and core Worker profile | Governed platform entry point and the supporting runtime path | Workers are deployed test first, production second, with Gateway last. |
Services, connectors, worker internals, and implementation packages remain
private. Frontends use the SDK and the Gateway; they do not import service code
or acquire direct access to a provider.
Explicitly out of scope
- A public claim that the whole product is generally available before the T1
launch gate passes. - Publishing an unverified package version, deploying with configuration
warnings, or overriding isolated-environment safeguards. - Adding product concepts or user-facing architecture labels outside the frozen
product grammar. - Paid acquisition, formal partner programs, or regional expansion before their
Commercial OS gates open.
3. Current readiness record
The following is a dated evidence record, not a claim of launch readiness.
| Area | Evidence as of 2026-07-22 | State | Required next result |
|---|---|---|---|
| Source baseline | Public SDK/schema preparation is on main at e0a4e3e0; the worktree was clean when recorded. | Green | Tag the exact release commit once versions are approved. |
| Package quality | pnpm release:packages:check passed: both public packages typecheck, build, test where applicable, and produce inspected tarballs. | Green | Repeat on the release commit. |
| Static release shape | pnpm release:check -- --environment test and prod passed. | Green | Repeat before each release. |
| npm registry | The active environment is not authenticated to the @integratewise npm scope. No package was published. | Blocked | Authenticate to the correct organization, verify package ownership and new versions, then run the guarded publish workflow. |
| Cloudflare validation | Core test dry-run found seven Wrangler warning sets; the matching prod dry-run found eight. Neither dry run published a Worker. | Blocked | Correct every warning; a warning-free dry-run is mandatory. |
| Test isolation | Core test bindings still share production D1, KV, Queue, Vectorize, and Secrets Store resources; some test service bindings also target legacy names. | Blocked | Provision/use isolated test D1, KV, Queue, R2, Vectorize, Durable Object, secret, and service-binding targets; apply migrations and verify no test/prod resource is shared. |
| Remote rollout | No new test or production release is authorized by this plan. | Pending | Complete the technical go/no-go gates below. |
| Public launch proof | Customer activation, design-partner outcomes, security packet, demo readiness, website, and marketplace status are not yet recorded as complete here. | Not ready | Meet and evidence every T1 launch gate in §7. |
Decision now: technical rollout is No-Go until npm authentication,
warning-free configuration, and strict test/production isolation are evidenced.
Public T1 launch is No-Go until its commercial proof gate is complete.
4. Technical go-live gates
Every item below needs an owner, a dated evidence link, and a recorded result in
the release issue or change record. A failure keeps the release at its current
stage; it is not bypassed with a blanket override.
| Gate | Accountable function | Exit evidence |
|---|---|---|
| Release scope frozen | Founder + Platform | Exact commit, package versions, supported endpoints, and customer-facing change summary approved. |
| Build and package integrity | Platform | pnpm release:packages:check passes on the exact commit; tarballs contain no secrets, environment files, or implementation-only dependencies. |
| Registry authorization | Release owner | @integratewise organization access verified; each package version is new; provenance/access policy is confirmed before publish. |
| Environment separation | Platform | A binding inventory proves test and prod use different D1, KV, Queue, R2, Durable Object, secret, and service-binding targets. Test migrations are applied only to test. |
| Configuration correctness | Platform | pnpm release:check passes for test and prod and Cloudflare dry-runs complete with zero warnings. |
| Test deployment | Platform | Core profile deployed in the locked order to test, with Gateway last; health, route, connector, queue, storage, and service-binding checks pass. |
| Governance proof | Product + Platform | An approved action completes with a receipt; an unapproved action fails closed; audit/provenance is visible. |
| Security and tenancy | Platform + Security owner | Authentication, tenant boundaries, CORS/origin policy, secret rotation path, least-privilege bindings, and public security packet reviewed. |
| Operational readiness | Platform | Dashboards, alerts, on-call contact, incident template, rollback procedure, and an immutable source archive/checksum are ready. |
| Production authorization | Founder | Test evidence reviewed, customer impact assessed, production approval explicitly recorded, and the production confirmation mechanism used. |
Required release sequence
-
Repair configuration before deployment. Produce one environment-binding
inventory per core Worker. Create or select the isolated test resources,
migrate them, seed only synthetic test data, and update every test binding.
Do not reuse production IDs or secrets to make a test dry-run pass. -
Establish a clean test candidate. Run the package checks and both static
release checks. Then run the core test dry-run until it has zero warnings. -
Publish the public package versions. After registry authentication and
package/version confirmation, publish only the two supported packages via the
guarded package workflow. Record package names, exact versions, shasums, and
release commit. -
Deploy and prove test. Deploy the test core profile in canonical order:
pipeline → connector → mcp-connector → connector-sync → knowledge → continuity → intelligence → workflow → l2 → gatewayValidate the Gateway and the full governed path with synthetic tenant data.
-
Review before production. Compare test configuration and behavior with
production without copying test resources into production. Confirm rollback
owner, known limitations, and customer communication path. -
Deploy production only under explicit approval. Use the canonical
prod
environment and production confirmation. Deploy the same sequence with
Gateway last, run post-deploy health checks, and record the deployed Worker
versions and package versions. -
Observe and stabilize. Keep the release owner on the operational cadence
through the agreed stabilization period. Roll back a Worker version or issue
a compatible package patch if a release gate regresses; never erase customer
data to recover from a release.
The detailed commands and guardrails live in
Package and Deployment. This plan owns the
decision gates; that runbook owns the mechanical release procedure.
5. Controlled availability and design-partner motion
The post-technical-release motion is category-led, activation-assisted, and
proof-gated: establish the platform story, activate a bounded connected
ecosystem around a material operational problem, prove a governed outcome, then
expand through more Workbenches, capabilities, and systems. Customer Success,
HubSpot, or any other supported path can supply proof; none is the public
category or mandatory first route. Self-serve is an entry point only where the
activation journey is genuinely supported.
| Stage | Goal | Entry condition | Exit evidence |
|---|---|---|---|
| P0a — controlled availability | Safely serve the supported SDK/Gateway path and first design partners. | All technical gates in §4 pass. | Stable test/prod operation, support route tested, and each external user has an explicit enablement path. |
| P0b — prove | Turn real operational work into verified platform value. | P0a stable. | Permissioned outcomes across more than one applicable operational pattern; a repeatable activation checklist; evidence for expansion. |
| P1 — repeat | Demonstrate a repeatable discovery → activation → first-outcome motion. | P0 exit criteria met. | Consistent sponsor/work-owner/control-owner pattern, delivery capacity, conversion/retention evidence, and approved case material. |
| P2 — compound | Expand from a proven platform motion. | P1 exit criteria met. | Cohort expansion, supportable partner motion, and channel economics meet Commercial OS gates. |
Founder operating cadence during P0
Favor direct learning over volume: customer/operator discovery and guided
activations; category and proof content; technical/security conversations; and
a weekly evidence/claims review. The allocation follows active pipeline and
release readiness, not a fixed Customer Success quota. Partnership work remains
a seed motion until the core activation-to-outcome path is repeatable.
Design-partner evidence packet
For every participant, capture permission and a before/after baseline before
the POV begins. The evidence packet contains:
- ICP fit, connected-system scope, champion, economic buyer, and success
criteria. - Baseline time, cost, risk, and operating context for the selected workflow.
- A recorded governed-action demonstration: evidence → proposal → human
approval → execution receipt. - Activation and usage evidence, including the first completed outcome.
- Outcome measurement, customer quote approval, limitations, and the decision
to convert, extend, or exit.
Only verified, attributed outcomes enter public copy or the claims register.
6. GTM execution plan
Audience, offer, and narrative
| Element | Operating choice |
|---|---|
| Category | The Operational Capability Platform for the AI Era. |
| Primary audience | Executive sponsors, operational leaders across the twelve Workbenches, IT/security/governance, and developers/ecosystem partners. |
| Buying motion | Category demand → qualified operational problem → bounded ecosystem activation → governed outcome → expansion. |
| Core promise | One governed fabric connects people, AI surfaces, systems, data, Workbenches, and approved outcomes. |
| Trust boundary | The Twin prepares; the human approves. Every consequential action is governed and auditable. |
| Calls to action | Explore Platform, Workbenches, Capabilities, Ecosystem, or Developers; start only a supported activation with clear scope. |
Every external asset must show how fragmented AI, people, and systems become a
governed operational capability; carry evidence within two sentences; and give
one next step. Use the platform, Workbench, ecosystem, governance, and
continuity language from the Current GTM Canon.
Do not expose internal runtime labels, provider credentials, or unsupported
coverage claims.
Channel plan
| Channel | P0 action | Gate / measure |
|---|---|---|
| Founder-led sales | Qualify cross-system problems with executive, work-owner, and technical/control champions. | Qualified activation, first outcome, proof, and expansion quality. |
| Founder-led content | Publish platform, Workbench, capability, ecosystem, developer, governance, and continuity proof. | Conversations and qualified demand, not impressions alone. |
| Customer proof | Turn permissioned outcomes into attributable case material only after review. | Evidence across more than one operational pattern before public T1 launch. |
| Community/newsletter | Nurture operators, executives, builders, and control owners solving ecosystem fragmentation. | Subscriber quality, reply/conversation rate, and sourced opportunities. |
| Marketplace | Prepare listings only for supported public integration or activation paths with clear ownership and support. | Listing is optional proof, not a T1 launch requirement. |
| Partners | Warm ecosystem architects and operational/technical partners aligned to supported capabilities. | Seed only; no formal program before direct-motion proof and organic wins. |
| Events | Use precise operating and developer audiences; measure booked conversations and activation quality. | Qualified meetings and follow-up conversion. |
| Paid acquisition | No spend in P0/P1. | Revisit only after activation, conversion, and retention economics are evidenced. |
Asset and enablement backlog
Before an external technical announcement or customer campaign, the accountable
owner must complete and link the following assets:
- Release note and developer quickstart for the supported SDK contracts.
- Current product tour and a backup recording that shows a governed path and
the fail-closed refusal. - Sales, security, procurement, and developer enablement updated for the exact
release scope. - Website information architecture for Platform, Workbenches, Capabilities,
Ecosystem, Developers, Resources, Pricing, sign-in, and activation. - A current claims register covering public counts, logos, certifications,
named providers, authentication, and roadmap language. - Permissioned proof templates, an escalation route, and press/product-launch
assets reserved for the later T1 gate.
7. Public T1 launch gate and run of show
The public launch remains a No-Go until every condition below is marked
complete with evidence. It is the Commercial OS gate, reproduced here so the
technical and GTM teams make one decision.
- The technical go-live gates in §4 remain green in production.
- The public Platform, Workbenches, Capabilities, Ecosystem, Developers,
Resources, and Pricing/activation surfaces reflect current product scope. - A current product tour and fallback recording show a supported path from
context through a governed capability to a human-approved receipt. - At least two permissioned proof cases cover meaningful operational work;
they include limitations as well as outcomes. - Developer documentation and public contracts accurately state package,
Gateway, API, webhook, and capability boundaries. - Security, identity, approval, tenancy, audit, support, incident, and
rollback material is current for the offered scope. - All public counts, logos, certifications, named providers, authentication
claims, and roadmap language have a current evidence record—or are
removed or clearly marked as roadmap.
Once the gate passes, set a launch date and use this relative schedule:
| Window | Deliverable | Accountable function |
|---|---|---|
| D−21 to D−14 | Lock product proof, platform navigation, demo/recording, developer path, security materials, claims, support coverage, and outreach list. | Founder + Platform + PMM |
| D−7 | Publish the platform/category narrative through the site, founder channels, and newsletter. | Founder + PMM |
| D-day | Publish the platform overview and product tour; route executive, operator, technical, and developer audiences to the right proof surface. | Founder + PMM |
| D+1 to D+5 | Publish one proof asset daily: Workbench, capability, ecosystem, developer access, governance, or continuity. | Founder + PMM |
| D+7 | Publish only permissioned case material and an honest operating learnings post. | Founder + Product |
| D+14 | Complete launch retro: audience quality, activation, incidents, evidence gaps, and the next 30-day operating plan. | Founder + all owners |
During launch day, the founder runs 30-minute triage cycles with one owner for
site/product health and one for response/escalation. A product incident uses
the prepared status and incident communication path; a backup product film
keeps the narrative honest while the service is repaired.
8. Scorecard and review rhythm
Technical release scorecard
| Measure | Green condition |
|---|---|
| Package release integrity | Public package checks pass on the shipped commit and published versions resolve/install as expected. |
| Environment safety | No shared test/prod stateful bindings; no warning overrides. |
| Governed execution | Approved actions complete with an auditable receipt; unapproved actions fail closed. |
| Service health | Gateway and core dependencies meet their approved health/readiness checks throughout stabilization. |
| Recovery | Alerts route to an owner and the rollback procedure has been exercised or reviewed for the exact release. |
Commercial scorecard
The P0/P1 phase exit criteria are the primary GTM scoreboard. For the T1 launch,
track qualified platform evaluations by audience, activation requests,
product-tour completion, time to first governed outcome, developer-doc
activation, support response, proof conversion, and any claim corrections
required after launch. Compare every number to the Commercial OS definitions;
do not introduce a public target or claim that has not been verified.
| Cadence | Review | Decision |
|---|---|---|
| Every release candidate | Technical gate review and binding diff. | Advance, remediate, or stop technical rollout. |
| Weekly in P0 | Operational proof outcomes, activation, support signals, and pipeline. | Adjust activation; preserve scope discipline. |
| Monthly | Founder-time allocation, channel quality, proof inventory, and claims freshness. | Reallocate effort only within P0 constraints. |
| At public-launch gate | Evidence review across technical, product, security, and commercial owners. | Set date or retain No-Go. |
| D+14 and D+30 | Launch and activation retrospective. | Feed durable content, sales, product, and ecosystem motions. |
9. Authority, communications, and rollback
| Decision | Decision owner | Required consultation |
|---|---|---|
| Technical test rollout | Platform owner | Product and security owner |
| npm package publication | Release owner | Platform owner and Founder |
| Production rollout | Founder | Platform, product, and security owner |
| External technical announcement | Founder / PMM | Platform validates scope and claims |
| Public T1 launch date | Founder | Platform, PMM, Product, Security, Developer/Ecosystem owner |
| Rollback or incident communication | Platform owner | Founder; customer-facing owner for material impact |
No external announcement may imply that a capability is live before the
matching production gate has passed. No release may use a customer environment
as a test environment. If a technical, security, or governance gate regresses,
pause the campaign, communicate the verified state, and resume only after the
release decision is green again.
10. Immediate next actions
- Create the environment-binding inventory and remediate the seven Cloudflare
warning groups, beginning with the test-to-production Spine D1 overlap. - Provision/migrate isolated test resources and complete a warning-free test
dry-run for the core profile. - Confirm npm organization access, approve the initial public package versions,
and run the guarded public package release on the tagged release commit. - Deploy to test, execute the governed-action and fail-closed acceptance
scenarios, then submit production evidence for explicit approval. - Build the Platform, Workbenches, Capabilities, Ecosystem, Developers,
Resources, and Pricing/activation launch surfaces; reconcile every public
claim with the claims register. - Start/continue guided ecosystem activations and create permissioned evidence
packets; do not schedule public T1 launch until the proof gate is complete.