Our screenshots use a demo tenant

The easy mistake

The most persuasive screenshot is always the real one. Real density, real mess, real names. It looks like a product people use, because it is.

It is also a publication of employee data. An attendance percentage next to a name is a fact about that person. A leave type next to a name can be a medical fact. A support ticket subject can be a grievance.

Blurring is not a fix. Blur is reversible often enough to be a bad plan, and half-blurred screens read as evasive anyway.

What a demo tenant gets you that a mockup does not

A drawn mockup shows what a designer wanted. A demo tenant shows what the software does.

Seeded data goes through the same code. The same table, the same empty states, the same column widths when a name is long, the same rounding on a percentage.

That matters because the gap between a marketing screen and the real one is where trust is lost. A buyer who sees the actual interface in a demo, having seen a nicer one on the site, discounts everything else the site said.

The discipline that keeps it honest

A demo tenant can drift into fiction as easily as a mockup. Some rules keep it useful.

Seed a realistic shape, not a flattering one. Pending items in the approvals queue. A project that needs attention. An unmapped user on the device mapping screen. A real instance always has some of each.

Never invent a customer. A seeded company name inside a screenshot is a label on demo data. It is not a logo wall, and it must never be presented as one.

And never seed a number that would read as traction. A demo tenant with four hundred employees in it is a claim, whatever the caption says.

• Seeded data, never production data.
• Realistic mess: pending queues, warnings, unmapped rows.
• A seeded company name is a label, never a customer claim.
• No seeded figure that could be read as scale or traction.

What this costs and why we pay it

Building and maintaining a seeded tenant is real work, and it has to be redone as the product changes or the screenshots go stale.

The alternative is cheaper and worse. Publish real employee data, or publish drawings. One breaks trust with your own team. The other breaks it with a buyer, discovered later.

How to read any vendor's screenshots

The same reasoning works in reverse when you are the one being sold to.

Look for the empty states and the awkward rows. A product only ever photographed at its fullest is hiding how it looks on day one, which is the state you will actually meet.

Look for numbers that flatter. A screenshot with a hundred perfect rows and no pending anything is a set, not a workspace.

And ask for a live screen. A vendor who can show you the real interface, on their own seeded data, in a call, is telling you the site was honest.

The rule underneath all of this

A marketing page is allowed to choose what it shows. It is not allowed to show something that is not the product.

That line is easy to state and easy to apply. A seeded record is the product. An invented customer count is not. A redrawn interface is not, however faithful the designer was.

Most of the arguments about screenshots dissolve once the line is drawn there, because the remaining decisions are about which real screen best explains the thing.

And it has one useful side effect. A page constrained to real screens cannot promise a feature the product does not have, because there would be nothing to photograph.

Keeping the tenant from going stale

A seeded tenant decays faster than most people expect, and a stale screenshot is its own kind of dishonesty.

Columns get added. A screen gets rebuilt. A label changes. None of that updates the image sitting on a marketing page, and a buyer who meets the real screen notices immediately.

So the seed belongs in version control, next to the code, and regenerating it should be one command rather than an afternoon.

The screenshots themselves need a check that catches drift. Ours are checked by a build step, which is less about rigour than about the fact that nobody remembers to look.

A screenshot is a claim with a date on it. Treating it like any other claim is the whole discipline.