Building a demo that looks alive: the live dashboard behind the "Try live demo" button

When someone lands on a developer tool's homepage, they usually want one thing: to see the actual product. Not a screenshot from eighteen months ago, not a "book a demo" form. The real thing, with real-looking data, in one click.

That's what the "Try live demo" button on Eventra's homepage does (you can open the demo right now). It drops you into a populated, read-only workspace with no signup. This post is about the product side of it: how the demo got there, and why making fake data look believable turned out to be its own piece of work. (The security side, how it stays read-only for strangers, is in a separate dev.to article.)

Why I built it: evaluating a tool like this normally takes real effort. You register, install the SDK, send an event and wait. That is too much to ask of someone who only wants to know what the product is, so a visitor should be able to see it first. The product page makes claims, and the demo lets anyone check each one against the real dashboard. I prefer a page where everything matches what it promises over loud marketing.

It started as a seed script

The first demo-related commit is from February 24, in the same week as the ops dashboard, just "add demo". Early March has "seed demo". At that point it was a script I used for myself: fill the database with some plausible events so the charts weren't empty while I built the dashboard. A developer's demo, in other words.

On April 5 the landing page got a demo section, and on April 8 there's a commit called "live demo". For a few months that was the state of things: a showcase on the homepage, with the data behind it living in my seed script.

On August 27 it became a real public account: one click, straight into the actual dashboard, read-only. A showcase you can poke at is different from a picture of a showcase.

Fake data has to tell a story

Over the next month I reworked the seed, because the first version only produced numbers. Events, users, dates. It looked fine in a quick glance and fell apart when you used it.

Eventra's whole pitch is that it finds dead, declining and never-seen features. A demo that doesn't show those isn't a demo of Eventra. So the seed had to be designed around the story the product tells:

• Dead features, grouped by how long they've been silent.
• Declining features, a profile where activity over the last 14 days drops to a fraction of the earlier level, deliberately well below the "half or less" rule so the dashboard flags it. I added names that sound like real leftovers: classic_editor_opened, legacy_reports_opened, tablet_layout_used.
• Never-seen features, found in code and never sent an event, which look like what's left after a CLI sync with nothing behind it: export_to_notion, sso_login_started, apple_watch_sync.

Then there were the places where the data was technically there but the page was empty. The seed did not include per-user activity at all, so everything that depends on users over time (the Users page, a feature's users, the before-and-after in Declining) would have shown zeros in the demo. A visitor who clicks on "Users" and sees nothing doesn't think "the seed is incomplete". They think "this product doesn't work".

A bug in my own demo numbers

While I was preparing the demo, I found that some of the demo's numbers were counted twice. The demo data goes through the real pipeline on purpose, and that is exactly how the double count showed up: on the first local run, 173 demo rows were counted again. I fixed it before the demo shipped.

I am glad I found it in the demo before I found it in a customer's numbers.

The screenshots had to change too

The homepage has a carousel of dashboard screens. After the demo data changed, all nine screenshots were out of date, so I re-shot every one from the re-seeded demo and added four new ones: Declining, Never seen, Users and User detail.

Going from nine screens to thirteen also broke the carousel layout, which had only looked right by coincidence with nine. I fixed that too.

What I'd tell someone building a demo

• A demo is part of the product, and it needs the same care. If it's the first thing people see, it's the thing they judge you by.
• Build the data around the story. Think about which three or four things you want a visitor to understand, and make sure the demo shows them without anyone having to hunt.
• Run the demo through the real pipeline. It's tempting to write the final numbers directly, but then the demo can't catch the bugs a real customer would hit.
• Check every page, not just the overview. The empty one is the one people will click.