Shipping velocity – the demo-hub pattern

demo-hub is one Next.js app with one route per demo. Every demo is self-contained – no cross-demo imports, no shared components. All routes are noindex. Prospect attribution runs through /t/<token> tracking redirects so a demo URL can be sent by email and the click surfaces.

The discipline is that when a demo turns into a live client product, it moves out. fabrication-quoting spun out of demo-hub on 2026-08-10 into its own repo when the quoting demo turned into a live tool for a Nordic fabrication client. faraway spun out on 2026-08-04 into its own .no site when the travel demo became a real brand. The demos that stay in demo-hub are the ones that either haven't converted yet or serve a specific ongoing sales conversation.

• demo-hub: 20+ production deploys over the last quarter. Weekly cadence of new features or new prospect variants.
• fabrication-quoting: first commit to auth-gated live tool serving the client's estimator in under four weeks. Weekly major feature since.
• faraway: extracted from demo-hub on 4 August, live at faraway.no within a week (27 commits over six days).
• stratas-website: 70+ commits with active multi-region SEO work.
• agent-fleet-dashboard: 294 commits over four months, daily use by both founders.

Velocity is not the goal; it is the byproduct of a discipline that lets us stop worrying about whether the current demo will get in the way of the next one.

1. Every demo is self-contained. No shared components across demos. This is inefficient in the code-reuse sense and correct in every other sense – a demo cannot be broken by a change to another demo.
2. All demos are noindex. Prospect-specific work does not appear in search.
3. When a demo becomes a product, it moves. The spinout is a deliberate step, not a nice-to-have. The moment fabrication-quoting had authenticated users, it left demo-hub and got its own private repo, its own domain, and its own Supabase migrations.
4. The demo hub is not a design system. It is a router. The design system, if we ever build one, will be extracted from the products that survived spinout, not from the demos that lived under one roof.
5. Prospect attribution runs through the URL, not the app. /t/<token> redirects give us a click record without instrumenting every demo separately.

The pattern hardens the boundary between "prospect conversation artefact" and "client-owned product". A demo can be aggressive with promises because it is a proposal in a browser; a spun-out product has to earn its keep as software. The spinout event forces the honest-cost conversation: real repo, real deployment, real Supabase migrations, real cost tags in the fleet dashboard. Nothing that hasn't survived that transition should be labelled as a product.

Every pitch conversation is a competition against the prospect's status quo (usually a spreadsheet) and the prospect's other pitches (usually a slide deck). A live URL under a specific-to-them subdomain, in their industry vocabulary, using their real data – wins that competition often enough to have paid for the demo-hub build ten times over. That is the whole justification.