A freshly installed app is a blank screen. You cannot tell whether an email assistant is any good from an empty inbox, or whether a dashboard is any good with nothing to chart. So before you arrive, we fill the app with a company that does not exist.
This is the part that takes the work. Most demo data is generated separately for each app, so the customer in the invoicing tool has never heard of the customer in the helpdesk. Ours is written once, and one person turns up wherever they should.
A quiet week is the wrong test for a lot of software. You cannot judge a tool that catches fraud against clean books, or one that watches for outages against a system that never breaks. So a demo will be able to ask for a week where something is badly wrong — and because it is one company, the trouble would show up everywhere at once rather than as a flag on a row.
Today every demo runs the same quiet week. This is what the second scenario is being written to do, and it is written here as a plan rather than left to read like a feature.
Six apps, six fragments, one thing that happened. Whether the software helps you notice is the entire question — and the reason this is worth building rather than a longer list of rows.
A software company is the wrong backdrop for half of what people self-host. A photo library needs somebody's life in it, not a balance sheet.
One world is live today. The rest are being written.
This page is about the data. For the things it lives in — the mail server, the object store, the vendor APIs — see what the app is talking to →
Everyone in it is invented. Every address ends in .droplive.test, a suffix that can never resolve, so none of it can be mistaken for a real person or reach one.