Why a backup can't be a buttonWhy a backup can't be a button

"Can I get my data out?" is a question every owner of an accounting product asks sooner or later. Tigg's answer is a full company backup: products, contacts, the chart of accounts, ledger transactions and stock movements, packaged by the server as a downloadable file.

The obvious design is a "Backup Now" button with a spinner, and it would lie in ordinary situations. A full backup is a server job that runs in several parts and can take minutes. During that time the admin opens an invoice, reloads the page, switches to another organisation, or loses the connection for a moment. A button-and-spinner page forgets the job at each of those moments, even though the server keeps working.

So I designed the backup as a lifecycle: requested, preparing, ready, downloaded, deleted or expired, and sometimes failed. The page is only one view of that lifecycle, and it doesn't own the job.

I designed the backup page and built all of its frontend, plus the public page that an emailed link opens, between February and March 2026. The backend team built the backup job itself, the email and the retention rule.

Three decisions follow from "the backup outlives the page":

• The job is remembered. When a backup starts, the browser saves a small pointer: which job, for which organisation. Coming back to the page, or reloading it, shows "Reconnecting to backup status…" and picks up where it left off. The pointer is kept only if the organisation matches. Each organisation has its own address, and an accountant who works for several clients shouldn't see one client's backup on another client's page.
• The link arrives by email too. The backend emails a download link when the backup is ready, so nobody has to wait on the page. Small backups finish while the admin watches; large ones don't hold them there.
• One dropped check isn't a failure. The page checks the job's status in the background. A single failed check is ignored; four in a row are tolerated; only the fifth ends the wait.

My first version, on 11 February, listened to a live status stream from the server, and each step of the job updated the message on screen. Within the hour I replaced the inline delete confirmation with a proper dialog and added the saved pointer, so a reload no longer lost the job. Two days later I added the email-link download page.

Then the backend side ran into trouble. The senior backend engineer flagged problems with the live stream, so on 27 February I switched the page to asking for the status at intervals. On release day, 17 March, I tuned how often it asks: the checks settled at 3 seconds, then 10, then every 30. A small job reports back within seconds, and a long one costs only two requests a minute.

Polling made progress coarse. The server reports how many of its parts are done, usually seven. Between checks, the bar would sit still for up to 30 seconds and then jump, which looks broken.

So the bar is partly estimated. It shows the larger of two numbers: the real share of parts completed, and a simulated value that creeps up in small random steps. The simulated value stops at a cap, and the real number is held at 99% until the server says the backup is complete, because the final step comes after the last part. At first the cap was 91%. It came down to 61% on release day, a change that also grew out of the backend problems the senior backend engineer raised. Looking back, the lower cap also stops the estimate promising "nearly done" while the job is still early.

I'm not fully comfortable with it. For most of a typical wait, the number is invented. The status messages cycle through a fixed set rather than following the real stage, so "Compressing data…" can appear before "Exporting products…". My first version tied each message to the part just completed, and I'd go back to that: show real stage names, keep the bar indeterminate until the server reports finer progress, and add a line saying it's safe to leave because the link will arrive by email.

When the job completes, the bar reaches 100%, a toast confirms it, and the new backup appears in the history table with its time, the person who started it, its status, and a download link. The download asks the server for a short-lived link at the moment of the click and then opens it.

The emailed link opens a public page that works on a phone, because that's where emails often get read. It has four outcomes: the link is invalid, the download is being prepared, the link has expired, or "Download started". If the person isn't signed in, they're sent to sign in and then brought back to the same link.

Deleting a backup opens a confirmation that repeats which backup is going ("Backup from 12-03-2026 10:14:05"), because the rows look alike, and says it can't be undone. Failed backups have no delete action. On release day I added the retention rule right above the table: "Backups expire after 5 days and will be removed from this list." Rows that disappear without warning look like lost data.

The backup shipped in a beta release on 16 March 2026 and in a tagged release the next day, and it's in production. Measured outcome: none. I have no figures on how long backups take, how often people leave and come back, how often the page gives up while the server finishes anyway, or how many links expire unused. Those four numbers are what I'd instrument first.

Separate activity from measurement. The simulated fill made the wait feel alive, but for most of it the number was invented. Showing that work is happening doesn't require claiming how much.

Design the long wait around leaving. Resuming and the emailed link matter more than the bar, because they're what lets someone stop watching.

Name every ending. A long job can end in more ways than done or failed: the page can lose contact, or the server can forget the job. Each ending deserves its own sentence for the admin, for example "We lost contact. Your backup may still finish; check the history."