The Hardening Release

Every release until now has been about what your guests see. This one is not. There is nothing new in your guidebook, nothing to switch on, and nothing to learn.

Two things prompted it. Sign-ups are opening up more widely soon, and more of your guests are arriving from outside the United States than when this started. Both of those raise the same question: is the plumbing ready. So this release is the plumbing.

Your data now leaves the building every hour

Until this week there was one copy of the database and a daily backup held by the same company that holds the database. That is the arrangement most small software companies quietly run on, and it is fine right up until the day it is not.

Now a complete copy is taken every hour and stored somewhere else entirely, under a different provider, using a credential that can read and cannot write. Forty-eight hourly copies and thirty daily ones are kept, and they delete themselves on schedule.

The part I care about more: a backup that has never been restored is a belief, not a backup. So there is now an automated drill that takes the newest copy, rebuilds a working database from it, and checks that everything actually arrived. It runs monthly, and it ran for the first time this week. Every table came back, with the same number of rows as production, in about two seconds.

That gives me something I could not honestly say before: if a guidebook is deleted by accident, or something breaks badly at three in the morning, I can put your account back, and I know how long it takes because I have timed it.

Built for guests who are not American

If a guest joins your list in Berlin or Barcelona, European privacy rules apply to what you collect, and you are the one who collects it. I am the processor sitting underneath. That means the obligations land on both of us, and the parts that are mine to handle should be handled properly rather than assumed.

So the privacy policy now says plainly that backup copies exist, how long they are kept, and what happens if a guest asks to be deleted. Deletion has always been a real deletion here rather than a hidden flag. What is new is that a deletion request is re-applied after any restore, so a backup cannot quietly bring somebody back weeks later. There is a record kept specifically so that can be done, and it stores a fingerprint of the address rather than the address itself.

The policy also names every outside service involved in running the platform, which it did not do in full before. If you are ever asked by a venue, a partner or a corporate client who touches their data, that list is now the honest answer rather than something I would have had to assemble on request.

A proper look under the hood

Ahead of opening sign-ups, I had the code reviewed the way it should be reviewed: not a skim, but a deliberate look at how the database decides who is allowed to see what, account by account.

Some of that was verification. The classic ways this kind of software gets broken into are not present: there is no way to inject commands into the database, no way to run scripts inside somebody else's guidebook, and no credentials sitting where they should not be. Guest media uploads are locked to the account that owns them, and the file types accepted are restricted so nothing executable can be uploaded at all. Access rules are enforced on every table rather than left to the application to remember.

The rest was tightening: access narrowed to exactly what each part of the system needs, and nothing beyond it. The backup credential is a good example. It can read every table and change none of them, so even if it were somehow obtained, it could not be used to alter anything.

Detailed request logging is now switched on as well, which it was not before. That is the difference between believing things are fine and being able to demonstrate it.

The status page was telling me stories

This one is almost funny. The page that tells me whether everything is up had been showing a warning for three months, caused by a check that stopped running back in May. The page kept displaying its last result as though it were current. A status page that is always slightly wrong is worse than not having one, because you learn to ignore it.

It now works out for itself what is being checked, and anything it has not heard from recently is labelled as out of date rather than quietly shown as fine. Downtime alerts changed too: they used to fire on a single failed check, which meant every alert I had ever received was a false alarm. They now need two failures in a row, which is still fast enough to matter and rare enough to trust.

And if a guest ever opens a guidebook where the map does not load, that now tells me directly, from their phone, instead of waiting for someone to mention it.

Why write this up at all

Because you are keeping your guests' contact details in here, and increasingly those guests are covered by rules that did not apply when this was a handful of tours in Chicago. The reasonable question to ask of any software you rely on is not whether it is perfect, it is whether the person running it is paying attention and will tell you what they are doing.

Next release goes back to things you can see.