How this is built

The company is invented: Atlantica, a resort-wear house selling to properties across the Caribbean, Mexico and Florida. The properties, the buyers, the phone numbers and the email addresses are all fictional. Nothing in here belongs to a real customer, and no real customer’s data has ever been in it.

What it holds: the properties and the people at them, deals, quotes and orders, visit write-ups, tasks, and a health reading for each account with the sentences that explain it. Every one of the thirty-one properties carries a history rather than a name over an empty panel — its own contacts, orders, visits, timeline and reading — so a screen opened at random during a demo has something true on it.

The company is described once, in a single committed document, and the numbers on the screens are derived from it rather than typed beside it. A health reading is computed from the facts that produced it; a line total is its quantity times its price; the timeline names events that actually exist. Each of those is enforced by a check that runs before anything ships, so the demo cannot quietly drift into saying something the data does not support.

Anyone invited to this app can rebuild the sample company exactly as it started — not an administrator, anyone who can open the app at all. It takes two steps, because the sample company is shared: rebuilding it changes what everyone else looking at it right now can see, and the second step says so in those words before anything happens. It rebuilds from that one committed description rather than from a backup, so what comes back is the same world every time, and every press is recorded.

The world re-dates itself. Whenever it is rebuilt, the whole company is shifted onto today by a whole number of days — so a visit that happened the morning of the ticket still happened the morning of the ticket, an order placed four days before the follow-up is still four days before it, and every interval the screens describe is the interval they always were. Only the calendar moves. That is why a ticket opened days ago does not read as “open for months” to someone shown this next spring.

You can take these records out whenever you like. The download is not a report — it is the actual shape of how they are stored: one file per table, with the real column names and the real empty values, plus a note listing every file, how many rows it holds and a fingerprint of its contents. Every count in that note was counted from the rows written to the file beside it, so it is a receipt rather than a claim.

The same bundle loads back in. That is what makes it a way to move a book in rather than only a way to look at one: an export you cannot load anywhere is a file, not a way out. Loading matches each record on the identifier its table is actually keyed by, so loading the same bundle twice changes nothing the second time, and nothing is ever deleted — a record already on file with the same identifier is updated in place, and one that is not there is added.

Two things a file is never allowed to decide: which business the records belong to, and whether a business exists at all. Both come from the account you are signed in as, so a bundle exported from somewhere else lands here, under this business, rather than quietly creating another one. If a bundle disagrees with its own note about how many rows it holds, none of it is loaded and the reply says which file and by how much.