The Handover Test
Twelve questions to ask about software your business already runs on. For each one: the answer that should worry you, and the check that fixes it for good. These are the same checks we put into client software, written so you can use them this week without us.
Each check says how it’s enforced. That matters. In our work with Viya, checks the computer enforced held every single time. Checks that relied on someone remembering failed on the next new feature, every time.
Free to keep. No form, no email, nothing to sign. Hand it to your team.
Could one customer’s data show up for another customer?
● Enforced by the databaseWorrying answer: “Our code filters by customer.” The fix: the database itself refuses any request for shared data that doesn’t name the customer. The code’s filter is the first line of defense. This is the backstop for the day someone, or an AI tool, writes a rushed query.
Do this first if you serve more than one customer, site or branch from one database.
When someone adds a new table of customer data, does anything make sure it’s protected?
● Enforced by a testWorrying answer: “Developers know to register it.” The fix: every table of customer data is listed in one central place, and a test fails if a new one is missing. On Viya’s platform, forgetting this meant data could cross between customers. The test caught a real miss within two weeks of being written.
Where is money calculated, and can you trust it?
● Enforced by the databaseWorrying answer: “The app works out the totals.” The fix: totals, tax and discounts are recalculated where the data is stored, in whole cents, never in decimals that can round wrong. If the app and the database disagree, the save fails instead of quietly recording the wrong number.
When someone leaves, does their access end everywhere?
● Enforced by a testWorrying answer: “We disable their login.” Disabling a login often misses the session they’re still signed into, their access keys, shared folders and scheduled exports. The fix: a test that removes a person and then tries each of those. This is the most common gap we find in small company software.
Is permission checked when an action happens, or just by hiding the button?
◐ Partly enforcedWorrying answer: “Staff can’t see the button.” Hiding a button isn’t security. The check belongs on the server, when the action runs. Denying everything by default and allowing each action on purpose gets you most of the way. A person has to review the rest.
Could a password or access key end up in your code?
● Enforced by the release processWorrying answer: “We’re careful.” The fix: a scanner checks every change and blocks any that contains a password or key. Change any password that was ever saved in the code, including in old versions. Deleting it from the latest version doesn’t delete it from history.
If two people save the same record at once, does one change quietly disappear?
● Enforced by the databaseWorrying answer: “That doesn’t really happen.” The fix: each record carries a version number, and a save based on an old version is refused. The person is told their copy is out of date. Nobody notices this problem until a number is wrong and nobody can explain why.
If a multi-step process fails halfway, what’s left behind?
◐ Partly enforcedWorrying answer: “We clean it up by hand.” The fix: steps that belong together either all succeed or all undo. Where that isn’t possible, each step can be safely run again without doubling up. Half-finished orders are the most expensive data to clean up, because by the time you find them, someone has already invoiced from them.
When the app says “saved,” has it actually saved?
● Enforced by a testWorrying answer: “The screen confirms it.” AI tools build a convincing screen faster than the work behind it, so a screen can happily confirm something that never happened. The fix: save, read it back, and only then tell the user it worked.
Can someone in a hurry skip the checks?
● Enforced by the release processWorrying answer: “Only in emergencies.” If the person in a hurry can override a check, it isn’t a check. It’s a suggestion. The fix: overriding needs a second person, and it leaves a record.
Has anyone actually restored a backup?
◐ Partly enforcedWorrying answer: “Backups run every night.” A backup nobody has restored is a hope, not a backup. The fix: restore it into a test copy, check a record you recognize, and write down the date. Then put a reminder in the calendar. That part depends on a person.
When something goes wrong twice, do you add a check, or another reminder?
● The rule about rulesWorrying answer: “We added it to the checklist.” The fix: shared code and an automatic check, never another note in a document. This is why a review that’s working finds less each time, instead of finding the same things forever.
What a full set adds: rules fitted to your software, placed inside the risky parts of your own code so they reach whoever is building, each with a named owner. This list is the part that applies to everyone.