Twelve questions across security, data, scale and maintainability. You do not need to be technical to ask them, and you do not need to answer all of them well. What matters is how many you cannot answer at all.
At a glance
You do not need a developer to work out whether your software is in trouble. You need to ask the right questions and notice which ones produce a blank look.
Nobody scores twelve out of twelve. That is not the point. The point is that a question you cannot answer is a decision nobody made.
Security
1. Can one customer see another customer's data?
Test it rather than assuming. Two accounts, open a record in the first, note the number in the address bar, request that number while logged in as the second. You should be refused. This is the most common serious flaw we find, and the test takes five minutes.
2. Where are your passwords and keys kept?
The wrong answers are "in the code" and "I do not know". Credentials sitting in the codebase get copied everywhere the code goes, including places you have forgotten about.
3. If someone accessed data they should not have, would you know?
Not prevention, detection. If you cannot reconstruct who looked at what, then in the event of a problem you cannot tell customers what happened, which is usually the expensive half.
Your data
4. If the database vanished right now, what would you lose?
The real question is not whether backups exist. It is when someone last restored one and confirmed it worked. Untested backups fail at exactly the moment you need them.
5. Can the same thing be stored twice?
Two invoices with the same number, one customer with two accounts, a booking sold twice. If nothing at the database level prevents it, then correctness depends on every piece of code remembering to be careful, which they never all do.
6. What happens if something fails halfway through?
An order that takes payment, reduces stock and sends a confirmation is three things that must succeed or fail together. If the process can die between them, you will eventually find orders that are paid but do not exist.
Scale
7. What happens with a hundred times more data?
Not a hypothetical. If it is slow now with a modest amount, it is unusable later. Slowness that crept in gradually is the standard symptom.
8. What happens if two people do the same thing at the same moment?
If the honest answer is "nobody has thought about it", assume the answer is "something wrong, occasionally, and more often as you get busier".
9. What is your busiest realistic hour, and has anything ever been tested at that level?
Most applications have never seen their own peak until the day it happens, which is a poor time to find out.
Maintainability
10. Who can change this if you are unavailable for a month?
If the answer is nobody, that is a business risk rather than a technical one, and it is the one investors ask about.
11. How do you know when something breaks?
If the answer is "a customer emails me", you are using your customers as a monitoring system, and they will get tired of the job.
12. If you had to leave the platform this was built on, could you?
Do you have the code? Could someone else run it somewhere else? This one costs nothing while the answer is yes and a great deal when it is no.
How to read your score
Answered ten or more confidently: you are in better shape than most. Fix the gaps at your leisure.
Answered six to nine: normal for software built quickly. Nothing is on fire, but the gaps are worth closing before you grow into them.
Answered five or fewer: not a disaster, and not unusual either. It does mean a lot of decisions were never consciously made, and you would benefit from someone spending a few days telling you which of them matter.
Question 1 was a yes: ignore the rest of the score and deal with that today.
What to do with this
The value is not in the score. It is in noticing which questions made you uncomfortable, because discomfort is a reasonably accurate detector of unresolved risk.
Every one of these twelve questions is a decision, and decisions are the half of software that a brilliant typist and a terrible architect was never going to make for you.
Would rather a person went through it than a questionnaire? Get in touch and we'll answer all twelve properly.
