SaaS Demo Data: Show One Complete Workflow

#webdev #saas #ux

A useful SaaS demo gives visitors a small, believable task they can finish with sample data. Start with one coherent scenario, keep its records consistent across screens, and make it easy to return to the starting state. A crowded dashboard can show features while leaving the product's purpose unclear.

For an early product, demo data is part of the explanation. It tells the visitor who they are, what needs attention, and what a successful result looks like.

Choose the task before generating records

Write the task in one sentence. For a fictional client-review tool, it might be: find the design waiting for feedback, leave a comment, and mark the review complete.

That sentence tells you which data you need. You need a project, a reviewable file, a pending status, and a place for feedback. You probably do not need fifty customers or a year's worth of activity.

Use the same task to check the demo later. If the visitor cannot reach its result, more realistic names and avatars will not repair the missing path.

Keep the sample story consistent

Create a small set of records you control. The following JavaScript object is an illustrative fixture, meaning a repeatable set of sample data. It is not a complete application or a production data model.

const demo = {
  project: { id: "project-demo", name: "Sample studio website" },
  review: {
    id: "review-demo",
    projectId: "project-demo",
    fileName: "Homepage draft",
    status: "waiting_for_feedback"
  }
};

The names and IDs are fictional. The useful part is the relationship: the review belongs to the project, and its status gives the visitor a reason to act.

Use those same records on the project list, review screen, and activity view. If one screen says the review is waiting while another calls it complete, the visitor has to solve a data puzzle before understanding the product.

Include the state that explains the value

Perfectly finished data leaves nothing to do. Give the scenario one clear open task and enough surrounding context to make it believable.

For the sample review tool, include a prior comment and a design that still needs a decision. After the visitor completes the task, show what changed. The new status and comment should be visible where a person would look for confirmation.

Keep an empty state available as a separate example when it matters. A visitor should also be able to understand what starting a new project would involve. Do not mix unrelated states into the same story merely to fill every component.

Make the demo easy to reset

Choose a reset approach that fits the implementation. A local interactive demo might rebuild its state from the fixture. A hosted demo could create a separate sample workspace for each session. Treat those as design options, not interchangeable security solutions.

Define what the reset restores: records, comments, statuses, and any sample uploads. Then try the whole task twice. A second visitor should not inherit a confusing half-finished review from the first.

Keep demo actions separate from real customer operations. If a button would normally send an email or charge a card, explain what it does in the demo and prevent it from triggering the real operation.

Label the limits of what people are seeing

The GOV.UK guide to making prototypes distinguishes realistic interactions from production-ready code. Apply that distinction clearly: a convincing sample screen is not evidence that every underlying service is ready.

Tell visitors that the workspace uses sample data. Label simulated actions and show which parts they can actually try. Avoid using real customer exports as a shortcut to a busy-looking screen.

Before sharing, open a fresh session and complete the task without your usual explanation. Check the links, reset behavior, and final state. The demo is ready when the sample story still makes sense after someone interacts with it.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

DEV Community