Reference build · Phase 3 of 4
Build and ship a fictional B2B SaaS launch microsite.
Phase 2 produced the brand foundations. Phase 3 builds the actual launch microsite. Real code, real components, real working waitlist. Threshold is fictional; the build is real.
Demonstration notice
Threshold is a fictional product built to illustrate how the catalog composes from blank brief through research and brand to a deployed launch site. The build is real (real Next.js, real components, real working multi-step form); the product itself is not. The waitlist form on the demo site is local-only; nothing is stored or transmitted.
Mini-deck 1
Architecture.
Path-based, not subdomain. The demo lives at /demo/threshold, not threshold.rampstack.co. No DNS work, no separate Vercel project, no deploy-pipeline split. The microsite is a Next.js route inside the same monorepo and deploys with the rest of the site.
Cross-route imports, not duplication. The demo imports Phase 2's tokens, fonts, and the ThresholdLogo component directly from app/walkthroughs/saas-launch-brand-and-design/. The brand foundations are the single source of truth; the demo applies them. No copy-pasting; if the Phase 2 tokens change, the demo updates with them.
noindex, nofollow. The demo route's layout.tsx sets robots metadata to index: false and follow: false for both general crawlers and Googlebot specifically. A fictional product should never rank for real PLG terms; the framing is teaching artifact, not portfolio claim.
Persistent banner, not dismissible. A sticky navy banner at the top of every demo page names the framing in 30 words and links to this walkthrough. It cannot be hidden. The reader cannot visit the site and forget Threshold is fictional.
Skills used in this section
Mini-deck 2
Composition.
Eight sections, each making a small set of design decisions in service of the brief. The role each section plays, the design decision driving its implementation, and the catalog skill each decision traces back to.
Hero
Role: Position the product in 8 words plus a line of supporting context.
Decision: Headline lifted verbatim from the Phase 1 brief tagline. KPI strip below the buttons grounds the page in three real-feeling numbers (47.3% activation, 4.2 days TTFV, 63% trial-to-paid). All numerics in JetBrains Mono with the ochre highlight from the token system.
Problem
Role: Name the gap PLG teams encounter today.
Decision: Three-column card layout. One card per existing tool category (general-purpose analytics, in-product onboarding, custom dashboards). Each card states what the category is excellent at and where it leaves PLG measurement teams stranded. No disparagement; the framing is positioning.
Wedge
Role: Name what Threshold owns that nobody else does.
Decision: Two-by-two grid of capability cards, each prefixed with a mono numeric (01, 02, 03, 04) in muted teal. Capabilities map directly to the Phase 1 content gaps: pre-built activation funnels, time-to-first-value benchmarking, in-product measurement, PM-owned dashboards.
Comparison
Role: Make the wedge visible across an honest feature matrix.
Decision: Full-section comparison table with 8 rows. Threshold gets a check on capabilities only it offers; competitors get checks where they actually compete; partial-coverage cells get the ochre 'partial' label rather than a binary check. Italic disclaimer below names the framing as positioning, not feature exhaustiveness.
How it works
Role: Walk a reader through the three-step flow.
Decision: Three numbered cards in a horizontal row on desktop, stacked on mobile. Inline SVG arrows connect cards on desktop. Each step pairs a verb (Connect, Define, Measure) with one substantive sentence and one supporting sentence. Accent-color dots mark arrow origins.
Waitlist
Role: Capture qualified intent without being a barrier.
Decision: Five-stage form (role, team size, primary metric, email, confirmation) modeled on the Pulse onboarding wizard from Tooling Showcase 2b. Three qualifying questions before the email gate so cohort assignment is meaningful. Confirmation states demonstration framing explicitly: 'Your answers were not stored or transmitted.'
FAQ
Role: Answer the questions skeptical PMs ask.
Decision: Six native HTML <details>/<summary> elements in a 2-by-3 grid. Zero JavaScript for accordion behavior; the browser handles open/close. Questions are honest, not defensive: 'Why not just use Mixpanel?', 'How is pricing structured?'. Answers acknowledge the tradeoff.
Footer
Role: Reinforce demonstration framing and provide cross-links back to the walkthrough.
Decision: Two-column layout. Logo and tagline left, three placeholder link columns right (Product, Company, Connect). Real links go to the walkthrough and the GitHub source; product and company links are <span> placeholders so nothing pretends to navigate. Bottom strip names this as Phase 3 of 4.
Skills used in this section
Mini-deck 3
Demonstration discipline.
How a fictional product gets built without becoming portfolio-claim territory. Four practices, each working in concert.
Persistent banner across the route
A sticky navy banner sits at the top of every page under /demo/threshold. It names the framing in 30 words and links here. The banner is non-dismissible and high-z-index so the reader cannot scroll past it without registering the framing.
noindex on the route
The route's layout sets robots metadata to index: false and follow: false, both for general crawlers and Googlebot specifically. A fictional product cannot accidentally rank for real PLG terms. Google will not index the demo even if someone external links to it.
Local-only waitlist form
The 5-stage waitlist uses local React state. Nothing is fetched, posted, stored in localStorage, or sent to analytics. The confirmation explicitly states: "Your answers were not stored or transmitted." A reader who fills out the form has the same experience as a reader who reads the source: zero side effects.
Footer disclaimer + walkthrough back-link
The footer carries the full demonstration disclaimer and a real link back to this walkthrough. Product and company column links are <span> placeholders, not anchors, so nothing pretends to navigate. The only real navigation off the demo goes to the walkthrough or the public GitHub source.
Phase 4 hand-off
What the audit phase consumes.
Phase 4 runs the audit suite against the deployed /demo/threshold: accessibility (WCAG AA against the live site), performance (Core Web Vitals on a production Vercel deploy), on-page SEO (despite the noindex, the audit verifies the meta is set correctly). The audit's success criteria come from the Phase 1 brief: headline-in-8-words, first-screen comprehension in 5 seconds, comparison context visible, two real-numbers stats. Findings inform a final round of fixes before the reference build is considered complete.
Skills used in this section
The reference build continues
What's next.
Phase 1
Strategy and research
Brief, real Ahrefs research, competitor profiles, content gap analysis, recommendations.
Read the walkthrough →
Phase 2
Brand and design
Logo, color and type tokens, working components, compositional mockups.
Read the walkthrough →
Phase 4
Audit and optimize
Accessibility, performance, on-page SEO audit on the live site. Validates against the Phase 1 success criteria.
Read the walkthrough →
Demonstration framing
Threshold is a fictional product built to illustrate how the catalog composes from blank brief through research and brand to a deployed launch microsite. The demo at /demo/threshold is real Next.js code, real components, real working multi-step form. The product itself is not. The brief inherited from Phase 1 specifies a fictional B2B SaaS analytics platform named Threshold with the tagline "Know how new users actually get to value.".
Skills used (Phase 3)
Tooling used (Phase 3)
- Next.js App Router for the demo route + layout
- next/font/google via Phase 2 cross-route import
- React useState for the local-only waitlist form state
- Native <details>/<summary> for the FAQ accordion (zero JS)