Twelve questions will get a non-technical buyer most of the way there, before anyone bills you for deep software diligence. They hold whether the system is a paper ledger, a spreadsheet, an off-the-shelf tool, or custom software.
1. Which workflows stop revenue, delivery, or compliance if the system goes down?2. Who can run, repair, or change that workflow today?3. Who can diagnose a failure without calling the seller or one key employee?4. Does the company control the source code repository?5. Does it control the cloud, domain, app store, database, and vendor admin accounts, or the only working paper records?6. Are the employee and contractor IP assignments signed?7. Which licenses or vendor agreements have to transfer at close?8. When did someone last restore a backup and confirm it worked?9. What broke in the last twelve months, and who fixed it?10. Which customers run their own version, and which manual workarounds or one-off integrations does someone maintain by hand?11. Can the company export its own data in a format you can use?12. What does the seller or the current developer have to hand over before day one?
For each answer, ask what evidence backs it and whether someone other than the seller can reproduce it.
None of this replaces a technical review. It tells you whether you need one, where to point it, and which gaps belong in the price, the closing conditions, the seller's transition duties, or the first 100 days of budget.
The answer I worry about most is some version of: only one person knows.
Which question has changed how you saw a deal?