Self-Serve Activation & PLG Plan — "Build your agent, see it live, then deploy"

Status: Internal product + growth strategy draft (not a persona×angle marketing asset). Owner sign-off required before it drives roadmap. Date: 2026-08-01 One-line bet: Move the activation "aha" from "here's a widget in our sandbox" to "here's YOUR agent acting on YOUR real product in your own browser — in minutes" — then convert that belief into a customer-facing deploy.

1. TL;DR — the three moves

1. Persist the discovery. The agentic opportunities we already find (G2, docs, Reddit) must be saved as draft Actions + Navigation routes + Knowledge on a real agent — a portable Agent Spec. Today we discover and discard. This single fix closes Gap 1 and becomes the shared contract every other surface reads from.
2. Let the admin SEE it act on their real product — no deploy — via the Chrome extension. The extension runs the agent in the admin's own browser, overlaid on their real app. It's the evaluation/testing surface where belief converts, before a single line ships to customers. (Admin-only; not customer-facing.)
3. Split the deploy path by who's holding the keys — both ship an SDK.
   • No-code (PM / Growth) — Remote plugin / remote actions: actions are assembled into the SDK by Foldspace; the user doesn't hand-write handlers. To go customer-facing they deploy the SDK (the snippet).
   • Developer (has source) — Developer plugin: the Claude Code plugin + Foldspace MCP reads the Agent Spec and vibe-codes native, framework-aware handlers; the SDK ships as part of their app via a PR.

The freemium engine: discover + build + test-in-your-own-browser is free and ungated; deploying the SDK customer-facing, removing branding, Conversational Analytics, seats, and Trust Lab (early access) are the paid gates.

2. Where we are, precisely

Today's flow

Enter product → discover agentic opportunities (G2 / docs / Reddit) → auto-suggest docs URL → build agent (knowledge + actions) → show agent widget (in our sandbox).

What the live product primitives actually support

(From product-reference/.)

The two gaps, named

• Gap 1 — discovery is discarded. The suggested agentic experiences are never persisted as draft Actions/Routes/Knowledge. The "wow" evaporates; there's nothing to return to, iterate on, or hand to a developer.
• Gap 2 — the admin can't see the agent in their own product. The agent only runs in our sandbox against our idea of their app. The admin never watches it act on their real UI, so belief never crosses from "neat demo" to "this works on my product" — and today the only way to get there is a full customer-facing deploy, which is a huge ask for an evaluation.

The through-line: knowledge and navigation are already no-code. What we discard is the actions, and what's missing is a low-commitment way for the admin to witness the agent on their real product before committing to a deploy. The Chrome extension solves the second; persisting the Agent Spec solves the first.

3. Strategic frame — the activation spine

One ladder. Everything below serves moving the admin up it faster, then converting to a deploy.

North-star activation event: R3 — the admin watches the agent act on their real product in their own browser. That's when belief converts. R5 (customer-facing SDK deploy) is the monetization event.

Aha target: R0 → R3 in under 10 minutes, self-serve, no deploy required.

4. Keystone — persist discovery as a portable Agent Spec (closes Gap 1)

This is the foundation; build it first. Everything else reads from it.

What: at the end of discovery, write the results to a real agent, not a throwaway preview:

• Discovered opportunities → Draft Actions (create_action), each with description + trigger instructions + inferred inputs, marked Draft, tagged source: discovery.
• Discovered pages → Navigation routes (create_navigation_route / bulk).
• Suggested docs URL → Knowledge source (crawl), synced.
• Product name + description → agent Setup fields.

The Agent Spec = this saved bundle {agent, knowledge, routes, draft actions, product context}. It is the single contract that the Chrome extension (testing), the remote-actions SDK build, and the Claude Code MCP all read from. Portable, versioned, one source of truth.

Why it matters beyond "save button":

• Creates the returnable artifact PLG needs (email "your agent is ready," re-engagement, resumable session).
• Turns discovery output into draft work items the extension can test and a developer can finish — the hand-off between the two deploy tracks.
• Gives us the retention hook: an account with a half-built agent is a lead; today it's nothing.

Action items: lightweight account at R1 (email/SSO, no CC); auto-create agent; map discovery JSON → draft actions/routes/knowledge; "Your agent + N suggested actions are saved" confirmation.

5. The two deploy tracks (same spec, different action build)

The fork is: does the user control the front-end source code? It changes how actions are built and shipped — knowledge and navigation are identical either way, and both tracks deploy an SDK to reach real customers.

Track A — No-code (PM / Growth) → Remote plugin / remote actions

Principle: the user never writes handler code.

• Actions are assembled into the SDK by Foldspace ("remote actions") — the action logic is handled generically (remote calls / configured endpoints) rather than woven into the app's own code.
• Configured/edited in Studio (or inherited as drafts from discovery). Remote API actions can be defined by describing the endpoint + auth (or importing an OpenAPI/Swagger URL).
• Go-live = deploy the SDK (the <script> snippet before </body>). This is the one real deploy step for the no-code user; it may still need whoever can add a tag/snippet to the site.

Net: a Growth PM goes discovery → configured remote actions → tests it in their own browser via the extension → deploys the SDK when ready. No IDE, no handler code.

Track B — Developer (has source) → Developer plugin (Claude Code + MCP)

Principle: don't inject generic logic into a codebase the team owns — generate native, framework-aware code they'd have written themselves.

Flow:

1. Developer installs the Claude Code plugin (about to be approved) in their repo; it connects to the Foldspace MCP.
2. MCP exposes the saved Agent Spec — the draft actions/routes/knowledge from onboarding — as work items (list_actions, get_action, discover_actions, generate_action_handler).
3. Claude Code vibe-codes native handlers: uses their real API client, router, auth, types, and design system; wires the Foldspace SDK using each action's Action Key; registers navigation with their router.
4. Runs against their local dev server — agent is native, real, in-context.
5. Publishes actions (publish_action) and opens a PR. Merge = SDK shipped as part of their app (R5).

Net: the developer gets idiomatic, native code instead of a generic assembled bundle, and onboarding's discovered actions become real SDK-wired capabilities — no re-typing what discovery already found.

The bridge

Both tracks consume the same Agent Spec (§4). A PM can start no-code with remote actions, hit a limit (an action needs real backend logic native to the app), and hand the same draft actions to a developer who finishes them in Track B — no re-discovery, no re-spec. That continuity is a differentiator and the natural expansion path (PM lands → dev expands).

6. "See it in action" — the Chrome extension (closes Gap 2)

The Chrome extension is the admin's testing surface, and only that.

• Runs the agent from the saved Agent Spec in the admin's own browser, overlaid on their real, authenticated product.
• Lets the evaluator reach R2 (agent answers on the real page) and R3 (agent navigates/acts on the real UI) with zero deploy — the whole point is to remove the "deploy to customers just to try it" blocker.
• Admin-only, admin's browser. It is not a customer-facing delivery channel and does not put the agent in front of the user's customers. Customer-facing always goes through an SDK deploy (§5).

Framing/guardrail: because it executes in the admin's own session on their own product, keep an explicit "this is running in your browser for testing" indicator, and honor action confirmation messages for anything irreversible.

Developer parallel: for Track B, the equivalent "see it before you ship" moment is the Claude Code plugin running against the local dev server — native, real, pre-PR.

7. Freemium / PLG packaging

Design principle: discover → build → test-in-your-own-browser is free and ungated. We only charge at the point where the agent goes in front of the user's customers (SDK deploy) or delivers compounding value. Never gate the aha.

Free (self-serve, no card)

• Discovery + saved Agent Spec (R0–R1).
• Chrome-extension testing — agent acting on your real product in your own browser (R2–R3).
• 1 agent, capped actions, capped test volume.
• Claude Code plugin build access.
• Foldspace-branded widget.
• Community support.

Paid gates (upgrade triggers, in likely order of being hit)

Monetization notes

• The deploy is the paywall. Everything up to a customer-facing SDK deploy is free; the value of reaching customers is what converts. Keep the test experience generous so admins reliably hit R3.
• Usage-aligned metering on conversations/actions post-deploy gives a non-punitive expansion curve.
• Conversational Analytics (GA) is the expansion engine, not the entry point — it only has value once real traffic flows, so it sits above the deploy gate. Feeds the AI-First Growth story (intent = ranked demand for net-new value).
• Trust Lab stays early-access framing everywhere — never "available now."
• PM-lands-dev-expands account motion: no-code admin proves value in-browser → deploys remote-actions SDK → developer makes actions native/production-grade → seats + analytics + Trust Lab.

8. Funnel & metrics

Funnel: Visit → Discovery started (R0) → Agent saved / account (R1) → Tested in real product, own browser (R2) → Real action performed in browser (R3 = ACTIVATED) → Project revisited (R4) → SDK deployed customer-facing (R5 = MONETIZED) → Analytics/seats/Trust Lab (R6 = EXPANDED).

Instrument every rung. Today we can't even measure R1 because nothing is saved — §4 fixes that first.

• North-star: # of agents that reached R3 (real action on real product, in-browser) per week.
• Primary activation rate: R0 → R3 conversion; target median time-to-R3 < 10 min.
• Retention proxy: R4 revisit rate within 7 days (measurable only once the Agent Spec is saved).
• Monetization: R3 → R5 (SDK deploy) conversion; time-to-deploy.
• Expansion: R5 → R6 attach rate; PM→dev handoff rate.
• Track split: % choosing no-code vs developer at the fork; completion rate per track (watch where each stalls).

9. Roadmap — Now / Next / Later

NOW (unblock activation — ~first cycle)

1. Persist discovery → Agent Spec (§4). Draft actions + routes + knowledge saved to a real agent; lightweight account at R1. Closes Gap 1. Prerequisite for everything.
2. Chrome-extension testing (R2/R3) (§6). Agent from the saved spec runs in the admin's browser on their real product; read + navigation + action working. Closes Gap 2, delivers the aha with no deploy.
3. Instrument R0–R3 so we can see the funnel at all.

NEXT (deploy paths + monetization)

4. Remote actions in the SDK — actions assembled into the SDK; OpenAPI/endpoint import for remote API actions; one-step SDK deploy for the no-code user (§5A).
5. Claude Code plugin ↔ Agent Spec via MCP — reads draft actions, vibe-codes native handlers, opens PR (§5B). Track B end-to-end.
6. Deploy gate + Starter tier — the first paywall at R5 (customer-facing SDK deploy); remove-branding.
7. The build-path fork UX — ask/infer no-code vs developer; route accordingly.

LATER (compounding + expansion)

8. Conversational Analytics attach at R6 (GA) + seats/roles.
9. PM→dev handoff flow — one click to send draft actions from Track A to a developer's Claude Code plugin.
10. Trust Lab early-access offer in-funnel for risk-averse buyers.

10. Risks & open questions

• Extension is admin-only by design — good for trust (runs in the admin's own authenticated session, their own product, for testing). Keep the "running in your browser for testing" framing explicit and honor confirmation on irreversible actions. Don't let it be mistaken for a customer-facing delivery path.
• The SDK deploy is the real conversion step for no-code users, and it may still require someone who can add a snippet/tag to the site. Smooth this (tag-manager guide, one-line install, "send to your developer" flow) or the R3→R5 drop-off will be steep.
• The fork question friction. Asking "do you have source code?" may confuse non-technical users. Prefer to infer (entry surface: extension/Studio vs Claude Code plugin) and keep both paths open.
• Free-cap calibration. Too tight → admins never reach R3 and churn; too loose → no pressure to deploy. Needs a usage model once we can measure R3→R5.
• Naming. Keep canonical: Remote plugin / remote actions (no-codebase) / Developer plugin (in-codebase), Product Agent, Conversational Analytics (GA), Trust Lab (early access), AI-First Growth for the growth-lens framing.