You are not going to read the code, and you should not have to. But you are the person who has to decide whether to spend money on this system, and the usual sources are unhelpful: the developer says it is fine, the salesperson says it needs rebuilding, and neither answer comes with anything you can check.
These five questions can be asked by anyone. Each has a right answer, a common answer, and a bad answer. Ask them in writing, ask for dates rather than reassurance, and write down what comes back.
1. Is the software our server runs on still receiving security updates, and when does that stop?
Right answer: a date in the future, for each layer — the operating system, the language the software is written in, the database.
Common answer: “I think so.” Nobody has checked, which is not the same as it being bad.
Bad answer: a date in the past, or no answer at all.
Software is maintained for a defined period. After that date, flaws keep being found and published, and no fix is ever written for your version again. Nothing happens on that day. The system just stops being defended, quietly, and stays that way.
This is also the question on your cyber insurance renewal, which is why it is worth having a real answer rather than a guess. What it looks like when the answer has been “in the past” for three years — including a login that had absorbed 45,878 failed attempts and a disk that was weeks from filling up.
2. Where is the second copy of our data, and when did somebody last bring one back from it?
Right answer: a location, a schedule, and a date when a restore was actually performed.
Common answer: “we have backups.”
Bad answer: silence, or a routine nobody has looked at in years.
The second half of that question is the whole question. A backup nobody has restored from is a belief. We have seen a copy routine that had been reporting success for years into a destination that had been deleted — everything looked healthy right up until somebody checked. In that case the entire archive of customer files, 640 gigabytes of it, existed on exactly one machine. The write-up is here.
Ask for the date of the last real restore. If there isn’t one, that is your first piece of work, and it is small.
3. What happens to somebody who is signed in and working when we release an update?
Right answer: nothing; they keep working and do not notice.
Common answer: “we do releases in the evening.”
Bad answer: “everyone gets logged out.”
This one looks like a convenience question and is actually a question about how fast you can fix things. If updating throws all your staff out mid-task, updates move to the evening, then to the weekend, then to whenever it is unavoidable. Changes pile up, each release carries more of them, and the risk of any single release goes up — so you release even less. The organization describes itself as careful when what it is, is stuck.
The fix is well understood and does not touch your features. Here is what it changed for one company: releases now happen mid-morning and nobody in the office can tell.
4. What ends up in our logs when something goes wrong, and who can read them?
Right answer: a description of what is deliberately recorded, plus who has access and for how long it is kept.
Common answer: “whatever the error was.”
Bad answer: “I’d have to look.”
Logs are where software writes down what it did. In most systems they are also a second copy of your customers’ personal details — held somewhere with weaker access control than the database, readable by more people, and kept for however long a default decided.
The reason this happens is structural rather than careless: what is safe to write down gets decided hundreds of times, by different people, in the middle of fixing something else. Which is why “be careful what you log” does not work, and why the fix belongs in one place that every error already passes through. That piece of work is here, including the second version of the same problem that was invisible to the logging settings entirely.
5. If a customer asks our system for a record, what stops it handing over somebody else’s?
Right answer: the check is built into the way records are fetched, so a new screen inherits it automatically.
Common answer: “every screen does its own check.”
Bad answer: “what do you mean?”
If your software serves several client organizations from one system — which almost all subscription software does — this is the rule that must hold everywhere, every time. The failure mode is silent. Nothing crashes; somebody simply sees a row belonging to another company, and most of the time nobody notices.
If the answer is “every screen does its own check”, the follow-up is: how do we know every screen does? On one platform, the honest number was fifteen places where the check was missing, all of them in screens written by people who knew the rule perfectly well and were not thinking about it that afternoon. Nobody had reported a single one.
What to do with the answers
Five answers, written down, with dates. That is more than most businesses have about their own systems, and it took an afternoon and no technical knowledge.
Some of what comes back will be reassuring. Some of it will be “I don’t know”, which is the most common answer to all five and is not a sign of a bad developer — these are questions nobody is asked until something has already gone wrong.
If two or more of the answers worry you, the sensible next step is not a rebuild. It is a proper read of the system by somebody who does this for a living, ending in a document that says what exists, what is dangerous, and what each fix would cost. What that costs is published here.
Or describe what breaks in your own words and a person will reply within one business day with what we think is going on. That part is free, and it will tell you honestly if the answer is that you do not need us.