PLG 0→1 Platform architecture

A first
PLG-led demo

Sales couldn't show the real product without a bespoke setup, and the guided-tour tool showed a product that no longer existed. I defined and drove a self-serve demo platform (the real app, guarded and seeded), shifting the demo motion from "watch a tour" to "try it yourself."

My role

Product: strategy, ICPs, priorities, metrics; not delivery

Where

B2B spend-management scale-up

Dependencies

5 teams: web core, backend, SRE, auth, all product teams

80%

north star: share of core SMB product surface demoable without sales intervention

core flows in the MVP: issue card, expense, approve, invoice, export

−30%

target reduction in custom demo-build requests per deal

01Situation

Every first impression ran through sales

Prospects had two options: wait for a bespoke demo account hand-built by the demo team, or click through a guided tour built in a third-party tool: curated screenshots of a product that kept evolving underneath it. As the company shifted toward product-led growth, the demo motion was still entirely sales-led.

02Problem

Four failure modes, compounding

Demo drift

Click-throughs frozen at a point in time diverged from the real product. A misrepresentation risk in live deals.

Wrong persona coverage

The guided tour served passive buyers. The "active explorer", who wants to test real flows, had nothing.

Sales bottleneck

Every bespoke demo needed manual setup by one team; sales couldn't run demos independently.

No data lifecycle

Demo mock data broke after every release: fragile environments, reactive fixes, eroding trust.

03Goal

Self-serve exploration of the real product

Let the "active explorer" prospect test real flows, with no company setup, no onboarding and no sales call, covering 80%+ of core flows for the 50–499-employee ICP in a stable, production-near environment, with demo data that maintains itself.

04My role

Product owner of the demo experience: set the strategy, defined the ICP presets, prioritised requirements P0→P2, owned success metrics and coordinated five teams' dependencies. Explicitly not the engineering delivery owner; the platform had to be owned by the product development process, not one heroic team.

05Team

Web core (guards, routing, subdomain), backend core (mock-data API), SRE (hosting, uptime, session isolation), auth (demo auth model), and every product team, each owning their slice of demo data as part of Definition of Done.

06Diagnosis

The persona nobody served

Mapping the funnel showed a missing persona: the active explorer: a finance lead or founder who has seen the pitch, done the guided tour, and now wants to do things: submit an expense, upload an invoice, approve a request. They either waited days for a bespoke account or churned on a stale tour. A full flow inventory (onboarding, wallet, cards, expenses, approvals, invoices, export, controls, reporting) prioritised what they'd actually need first.

07Decision making

Real app, guarded. Not a better tour

The obvious path was extending the incumbent guided-tour tool. We evaluated it and rejected it: its architecture is optimised for curated click-throughs and can't support interactive, real-app exploration. The decision: run the real product on a demo subdomain with action/navigation guards, accepting the harder infrastructure problem in exchange for a demo that can never drift from reality. Flows were prioritised by value story, buyer relevance, feasibility, and the Pay → Manage → Control → Optimise narrative arc.

08Solution

DemoX: three layers

Guard-based real-app exploration

The production web app on a dedicated demo subdomain; guards block unfinished states; a persistent demo banner; sessions reset to baseline in under 5 seconds.

Seeded mock-data layer

Versioned JSON fixtures served by a dedicated API (<200ms), with ICP persona presets like an 80-person tech company or a 120-person hospitality business.

Mock-data lifecycle infrastructure

Demo data generated from teams' existing test mocks; each team owns its slice via Definition of Done; CI schema-drift detection alerts before sales ever sees a break.

The MVP: five flows, in narrative order

1Issue card + limit

→

2Expense + receipt

→

3Approve / review

→

4Invoice upload + AP

→

5Export to accounting

"Control without friction" in the first 3–5 clicks, closing the loop at month-end export. The flows AEs actually show, made self-serve.

09Trade-offs

A demo, not a trial

Explicit non-goals kept v1 shippable: no real money movement (demo, not sandbox), data freshness tied to release cycles not daily parity, SMB ICP only (enterprise multi-entity deferred), web only (mobile later). Each cut something sales wanted eventually, in exchange for something they could trust now.

10Impact

Measured at two levels

Platform health: sessions growing +20% MoM, ≥60% of sessions completing a core flow, 99.5% uptime, break incidents reported by sales down to ≤2/month within 60 days. Business impact: 30% fewer custom demo builds per deal by Q3 and win-rate lift tracked against a control group. Built ground-up with AI-assisted development, from blank page to launched v1 in two months.

11Learning

A demo that lies is worse than no demo

Demo drift looks like a tooling nuisance; it's actually a trust problem. The durable fix wasn't better screenshots. It was making demo data a first-class part of the development process, so the demo cannot diverge from the product. And the platform only works if it's owned by everyone: that's why the DoD clause mattered more than any feature.

"From 'watch a tour' to 'try it yourself.'"