How to Create Clickable Demos Without a Fake Backend

Build a clickable demo by combining (1) a high-fidelity prototype for UI-only flows, (2) a machine-readable API contract (OpenAPI) for any API-driven surfaces, and (3) client-side network mocking (Mock Service Worker or MirageJS) when you need the real frontend code to run against realistic, dynamic responses. This avoids maintaining a separate fake backend while letting you choose fidelity where it matters.

When this problem appears

You'll see this need when:

• Sales, marketing, or CS teams want fully clickable demos but you don't want to run and maintain a dedicated staging or fake production environment.
• The demo must be shareable broadly (public link or embed) and stable for on-demand playback.
• You need dynamic behaviors (lists, pagination, conditional flows) that a static screenshot or simple slide deck can't convey.
• You want a single source of truth that's usable across design, testing, and demos.

If you only need to show UI screens or onboarding flows, a prototype may be enough. If the demo must exercise real application logic or varied API responses, bring in API descriptions and client-side mocks.

Decision framework

Use this quick decision tree to pick the right mix:

• Need only UI navigation, animations, or static content?
  • Use a high-fidelity prototype (no code).
• Need the actual frontend code to run and reflect changing data/state?
  • Use client-side mocking (MSW or MirageJS) so the UI talks to mocked endpoints without a backend.
• Need programmatic descriptions of the API surface (for API explorers, documentation, or generating demo harnesses)?
  • Publish an OpenAPI Description (OAD) and, if useful, embed a spec-based explorer like Swagger UI.

Why these pieces work together:

• Prototypes (Figma) give fast, sharable, clickable flows without a server; they're built for stakeholder demos and presentation playback. See Figma's prototyping guide for how flows, overlays, and variables enable rich interactions. (For example, Figma prototypes can present multiple flows from a single file.) Figma prototyping guide
• An OpenAPI Description is a machine-readable contract that tooling can use to render interactive explorers or generate clients-useful when you want viewers to inspect or try API calls without a running backend. OpenAPI Specification
• Mock Service Worker (MSW) and MirageJS intercept requests in-browser and return realistic, dynamic responses without changing UI code, so you can demo the live app behavior without a backend. MSW GitHub README and MirageJS introduction

Step-by-step implementation

Below is a practical workflow you can follow. Each step can be used independently or combined.

1. Map the demo scope

   • Decide which journeys must be clickable (e.g., sign-up, onboarding, checkout) and which need live data (e.g., customer list, analytics).
   • For UI-only acceptance flows, plan Figma flows. For data-driven experiences, plan mocked endpoints.

2. Build the presentation prototype (fast, low-cost)

   • Use Figma to create frames, hotspots, overlays, and multiple flow starting points for each demo path. Anyone with view access can play the prototype in Presentation view, so it's easy to share with sales and marketing. Figma prototyping guide
   • Strengths: speed, presentation polish, shareable link.
   • Limitation: does not run your frontend code or show actual data-driven states.

3. Publish an OpenAPI Description (when API interactions matter)

   • Write or export a minimal OpenAPI document describing the endpoints used in the demo (paths, request/response shapes, examples).
   • Use this spec to power an embedded API explorer (like Swagger UI) or to generate mock servers in tooling. The OpenAPI spec is the standard for describing HTTP APIs and is widely consumable by docs and client-gen tools. OpenAPI Specification
   • Strengths: tooling interoperability, documentation parity.
   • Limitation: spec itself doesn't run responses-pair with a mocker.

4. Add client-side mocking so the actual frontend runs unchanged

   • If you need your real app to behave as if talking to a backend, configure Mock Service Worker (MSW) to intercept network requests in the browser and return predefined responses. MSW intercepts at the network level so your application code does not need modification. See the MSW README for usage examples. MSW GitHub README
   • Alternatively, use MirageJS (a client-side fake server that provides a mock DB, routes, and serializers) when you want richer server-side-like behavior such as models, factories, and relational responses. MirageJS introduction
   • Strengths: runs real code, simulates dynamic server state, reusable across dev and tests.
   • Limitation: requires adding a small mocking layer to the frontend bundle for demo builds.

5. Combine for distribution

   • For public or on-demand demos: export a prototype link for UI walkthroughs, and host a demo build with MSW/Mirage enabled for code-accurate demos.
   • For API-focused demos: embed Swagger UI or link to the OpenAPI-driven explorer so viewers can "try it" against example responses without a server. Swagger UI configuration docs
   • Provide guidance to sales/CS on which demo to use: prototype for quick visuals, demo app with mocks for technical walkthroughs.

6. Keep mocks maintainable

   • Store mock definitions in a shared repo or package so they're reusable across local dev, tests, and demo builds (MSW explicitly encourages reusing handlers across environments).
   • Version your OpenAPI spec and mock data alongside product releases.

Common failure modes

• Building a brittle prototype that doesn't match the shipped UI

  • Fix: keep design files aligned with the frontend and use prototypes for flows, not for pretending to be production code.

• Over-relying on screenshots or static prototypes for scenarios that require dynamic data

  • Fix: use client-side mocking to exercise conditional logic and stateful behavior.

• Mock logic drifting from real backend behavior

  • Fix: publish/maintain an OpenAPI Description and add test coverage that validates mock responses against the schema or contract.

• Shipping demos with hard-coded credentials or sensitive data

  • Fix: sanitize demo data and use controlled example accounts or mocked tokens.

• Too much setup friction for sales reps

  • Fix: provide two paths: an on-demand Figma presentation for quick previews and a single-click demo link (hosted demo with mocks) for deeper technical sessions.

How Rendemo fits and where it does not

Use the contrasts between screenshot demos, HTML demos, and embedded product tours to decide between a prototype-first and a code-first approach. See related guides: Screenshot vs HTML demos, How to choose interactive demo software, and Product tour best practices.

What Rendemo helps with

• Positioning demo types for different audiences (marketing slides vs. technical POCs).
• Choosing tools and workflows that reduce maintenance overhead.
• Playbooks for personalizing demos for prospects (How to personalize a sales demo).

Where Rendemo does not replace tool-specific setup

• Rendemo provides guidance, not the implementation of MSW/Mirage handlers or your OpenAPI spec. Use the official docs (linked above) for implementation details and examples.
• If you need production-grade API virtualization at scale (e.g., multi-tenant, long-running simulated services with persistence across sessions), a hosted virtualization platform or lightweight staging services may still be required.

Closing recommendations

• Start with a prototype for early content and stakeholder alignment.
• Publish an OpenAPI Description for any API surfaces you expect demos to reference.
• Use MSW or MirageJS when you need the real UI to exercise dynamic, conditional behavior without a backend.
• Store mocks and specs in source control so demo code and tests reuse the same definitions.

For quick next steps: create a two-path demo package (1) a Figma presentation link for non-technical audiences and (2) a hosted demo build with MSW/Mirage enabled for technical walkthroughs. Combine that with an OpenAPI spec to make API behavior discoverable and testable.

See also: Screenshot vs HTML demos, How to choose interactive demo software, In-app guided onboarding, How to personalize a sales demo, Product tour best practices