Twelve apps, four spreadsheets, an old server, and Michael

---

Owners think of their systems as an asset because they paid for them. A buyer reads the same systems as a list of future bills: the platform only one person can maintain, the backups nobody has tested, the former staff who still have logins, and the client data somebody pasted into a public AI tool.

---

Somewhere in due diligence, usually once the financials have settled down, the buyer’s technology people ask for a list of the systems the business runs on. It’s often the first time anyone has written one down. What comes back tends to look much the same: 12 software subscriptions, four spreadsheets that hold more of the business than anyone likes to admit, an old server, two custom integrations built by whoever was available at the time, and a developer named Michael who hasn’t documented anything since 2019.

The business works, and has for years. The buyer’s question is what all of it will cost them once it’s theirs.

Spending isn’t capability

Technology is one of the easiest places to confuse what you spent with what you’ve got. Every subscription, custom build, and upgrade was real money, and money spent feels like value accumulated. A business can spend a fortune on software and still have poor technology. Another can run well on fairly ordinary systems, because they’re set up properly, looked after, and right for the business.

A buyer doesn’t award points for the number of applications you subscribe to. They want to know whether the technology supports the operation, and what they’ll inherit. The second part is a forecast. Each system is either something that keeps working without much attention, or a bill that arrives after completion. If the buyer expects to spend $1 million replacing or integrating your systems once they own them, don’t be surprised when that changes how they think about the deal.

How the debt builds up

Technology debt accumulates the same way operational debt does, quietly and for good reasons. A temporary fix becomes permanent. A new system arrives and the old one is never switched off. Two applications get joined by whoever was free that week. The same customer data lives in three places, slightly differently in each. Nobody can remember why one of the subscriptions exists, and nobody wants to be the person who cancels it.

None of that is fatal, and most businesses carry some of it. It does have a cost, and the cost shows up the moment someone tries to fold the business into a larger one. A buyer with established finance, HR, CRM, and security platforms of their own will want to know whether your systems can sit alongside theirs, whether the data can move across cleanly, and how much disruption the move will cause.

Rebuilding everything to suit a buyer you haven’t met would be foolish. The sensible minimum is knowing exactly what you have.

The system only Michael can fix

The last item on that list is the one to start with.

Custom technology can be a genuine competitive advantage. The danger is a critical system that has become inseparable from the person who built it. Work through what happens if Michael is unavailable tomorrow: whether anyone else can get into the code, whether the passwords sit with the company or only with Michael, whether another competent developer could understand how it all fits together, whether the backups are current, and whether the technology underneath is still supported.

The same dependency turns up well outside software. One employee is the only person who knows how the accounting system is configured. An outside consultant controls the cloud environment. Someone in finance understands how data moves between the CRM and the accounting platform, and nobody else does.

These arrangements usually develop innocently. They’re still risks, and the fix is redundancy: more than one person able to administer every critical system, credentials held by the company, documentation that exists, and outside providers on proper agreements. A buyer shouldn’t have to acquire Michael along with the software just to keep the lights on.

The questions nobody asked five years ago

Technology due diligence has widened a long way. A buyer will now often look at cybersecurity, privacy, access controls, backups and recovery, the third parties who can see your data, and how your people use AI. These belong in your own review before a buyer runs theirs, and some of the answers are uncomfortable.

Former staff who still have logins. Administrator access held by people who stopped needing it years ago. Multifactor authentication switched on for some systems and not others. Backups that run every night and have never once been restored to see whether they work. Customer or employee information sitting in places nobody would have chosen. Cloud applications staff signed up for on their own. Confidential company or client information pasted into public AI tools, and nobody quite sure how much.

Every business carries some cyber risk, and a buyer knows it. They want to see a business that understands its own, has sensible controls, and can respond when something goes wrong. That’s about the past as much as the future, because a buyer may be inheriting exposure from incidents that have already happened. A serious breach discovered after completion brings disruption, regulatory trouble, unhappy customers, and damage to the name they’ve just paid for. If there has been an incident, have the record of how it was handled ready before anyone asks.

The same goes for data. If part of the value rests on your customer information or a database you’ve built, the buyer needs to be confident it’s accurate, protected, and legally usable. Data that can’t be trusted isn’t much of an asset.

The automation nobody can repair

Automation deserves the same scrutiny, because it’s where good intentions do the quietest damage. A business automates one task, then another. Someone connects two applications with a third-party tool. A spreadsheet triggers an email, the email triggers an automation, the automation updates the CRM, and the CRM sets off another workflow. Nobody writes down the dependencies, because the person who built it understands how it all works. Then that person leaves.

The process is now automated, and the business is more fragile than it was when people did it by hand. For each important automation, a buyer will want to know what happens when it fails, who finds out, whether someone can finish the job manually in the meantime, who knows how to repair it, and whether it runs on an employee’s personal account.

AI in the workflow needs the same treatment. Use it where it improves the operation, and know where it’s being used, what information it can reach, and what happens when the output is wrong. Automation should remove unnecessary effort. It shouldn’t remove the business’s understanding of itself.

If you’re raising money rather than selling, an investor’s technical review asks the same questions, and the answers tell them how much of their money goes on fixing things before any of it goes on growth.

If you are the buyer here: ask for the list of who holds administrator access before you ask for a demonstration. Then ask which system only one person can repair.

What to do this week

Start an application register. One line for each significant system: what it’s for, who owns it, who administers it, what it costs, when the contract renews, what data it holds, what it connects to, and how critical it is. A spreadsheet will do.

Then mark three things on it: every system only one person can administer or repair, every account a former employee can still get into, and the last date anyone restored a backup to prove it works. Deal with the material ones first. Clarity is worth more to a buyer than a cosmetic upgrade.

The full technology review, from the systems landscape to the questions to ask of every automation, is in Maximising Operational and Technological Efficiency, free to download from the Download Vault: manolutions.com/downloads.