8 things a technology audit during a business sale reveals about your software stack

A buyer's technical reviewer will learn things about your software that you forgot were true. Not because you hid them. Because nobody looks at the plumbing until someone offers to buy the house. Due diligence is the first time most owners see their whole stack written down on one page, and the page is rarely flattering.

This matters more than it used to. Software is no longer a line item under office expenses. It's how your work gets done, and buyers price it that way.

Ten years ago, a technology section in a diligence request list meant servers and licenses. Now it means operations. A buyer is paying for your revenue, and your revenue runs on software. If the software is fragile, the revenue is fragile.

Private equity firms have gotten specific about this. They send in a technical reviewer who asks for your vendor list, your contracts, your data export, and your access logs. They're building a model of what it costs to run your business for the next five years. Every renewal you can't control goes into that model as risk.

There's a second reason. Buyers plan to merge your operations into something, eventually. A system they can modify is a system they can merge. A system they rent, with settings they can't move, is a system they'll have to rip out.

These come up in roughly this order, and each one has a cost attached in the buyer's head even if they never say the number out loud.

1. Whether you own the code or just rent the login

The first question is ownership, and it's a legal question before it's a technical one. If a contractor built your quoting tool, who holds the copyright? If the contract is silent, the developer may own it, not you. That's the default in US copyright law for independent contractors, and plenty of owners find out during diligence.

Buyers want a clean chain. A signed work-for-hire or assignment clause, the source code in a repository you control, and no third party who can revoke access. If you can't produce that, the buyer either discounts the asset or carves it out of the deal.

2. How much of the business runs on per-seat subscriptions

Per-seat pricing looks harmless at 12 users. At 90 users it's a payroll line. A reviewer will take your seat count, your per-seat rate, and your historical price increases, and project it forward.

Here's the arithmetic buyers run. Say you pay 65 dollars per user per month for a project platform across 80 people. That's 62,400 a year. Vendors have been raising prices 8 to 15 percent at renewal. Over five years at 10 percent annual increases, that's roughly 381,000 dollars, and you own nothing at the end. A buyer sees that as a half-million dollar obligation attached to the business they're buying.

That doesn't automatically mean the subscription is wrong. It means the subscription has to earn its place. A tool you use 15 percent of, at that price, is a finding.

3. Whether your data can leave the building

Every platform claims it exports. Few export well. A CSV of your current records is not the same as your history, your attachments, your comment threads, and the links between records.

I've seen exports that drop every file attachment, exports that flatten relationships between parent and child records, and exports that cap at a row limit nobody documented. A buyer's reviewer will ask for a full export as a test. If it takes your team three weeks and a scripted pull through the vendor's API to produce it, that's useful information for both of you. Better to find out before the data room than during it.

4. How many critical processes live in a spreadsheet

This is the most common finding and the least discussed. Somewhere in your company there's a spreadsheet that calculates job margin, or allocates crews, or tracks warranty claims. One person maintains it. It's never been tested. It has hardcoded values from 2019.

Buyers aren't offended by spreadsheets. They're concerned about dependency. If the person who maintains it leaves after close, what breaks and how fast? Write down what each one does before someone asks.

5. The undocumented glue between your systems

Most mid-sized companies have three to six integrations holding the stack together. A Zapier automation that pushes new deals into the job board. A nightly script on someone's desktop that reconciles inventory. A webhook somebody set up during a trial two years ago.

These are fine until they aren't. A reviewer will ask what happens when one fails and who gets notified. If the honest answer is "we notice when customers complain," that's a gap. Document each connection, what it moves, how often, and who owns it.

6. License compliance and software nobody approved

Shadow IT is the software your teams bought without telling anyone. Marketing has a design tool. Sales has a dialer. Somebody's running a database on a personal account. None of it is on the vendor list you hand over.

Two problems. First, the buyer finds charges they can't explain, which damages trust in the rest of your numbers. Second, personal accounts mean business data sits under someone's private login. That's a real transfer problem, and it's a security finding.

7. Access control and who can still get in

Reviewers pull your user lists. They look for accounts belonging to people who left. They look for shared logins. They look for admin rights spread across half the company.

This one is fixable in a week and it's embarrassing to fail. Pull every system's user list, cross-reference against your current roster, and remove anything stale. While you're there, turn on two-factor authentication on anything touching customer or financial data.

8. Key person risk inside the software itself

If one developer built your internal system and left no documentation, you have the same dependency problem as the spreadsheet, just more expensive. Buyers call this bus factor. How many people can keep this running?

The fix isn't glamorous. A written architecture overview, a working local setup guide, and credentials stored somewhere other than a developer's laptop. That package turns a scary custom system into a defensible asset.

Accountants treat purchased software as an asset you can put on the balance sheet. Subscriptions are operating expense, which means they're a permanent drag on EBITDA. Since most deals price off a multiple of EBITDA, cutting recurring software cost raises the sale price by that multiple.

Run the numbers on your own business. If you cut 60,000 a year in subscriptions that weren't earning their keep, and your business trades at a 6x multiple, that's 360,000 of enterprise value. The build cost happens once. The multiple applies every year the savings persist.

Buyers also read ownership as control. A system you own can be modified, extended, and merged on your schedule. A rented platform can change its pricing, deprecate a feature you depend on, or get acquired by someone with different plans.

Start at least a year out if you can. Most of this is administrative, not technical.

1. Pull every software charge from the last 24 months and build a single vendor list.
2. Find the contract for each one. Note the renewal date, the notice period, and whether it transfers on a change of control.
3. Get written IP assignment from every contractor who touched your systems.
4. Run a real export from each platform and check it against what's actually in the system.
5. Document every spreadsheet that drives a decision, and name a backup owner.
6. Map your integrations on one page.
7. Clean up user accounts and remove anyone who left.
8. Cancel what you don't use. Unused seats are pure margin recovery.

Change of control clauses deserve a second look. Some vendors require consent to transfer, and some use that moment to renegotiate. Knowing which ones apply protects you from a surprise at signing.

Rebuilding your stack six months before a sale is usually a mistake. A half-finished custom system is worse than a working subscription. Buyers discount things in progress. If you're already in market, document what you have and fix the ownership paperwork instead.

Plenty of subscriptions should stay. Accounting, payroll, email, and document storage are commodity problems with mature vendors. Nobody has ever raised a valuation by writing their own general ledger. Custom makes sense where your process is specific to your business and the off-the-shelf tool forces you to work around it.

There's also the buyer's own plan. If your acquirer already runs a standard operating platform across their portfolio, they may rip out whatever you have regardless of quality. Your clean, owned system still helps, because the migration is easier when the data is yours and documented. It just won't earn the premium you hoped for.

And honest math matters. If a custom build costs more than five years of a subscription you actually use fully, don't build it. The case for ownership is strongest when you're paying for a platform you've outgrown or barely use.

Start with the vendor list and the export test. Those two exercises surface most of what a buyer will find, and you can run them with your own team in a couple of weeks. What you learn will tell you whether you have a documentation problem or an ownership problem, and they get fixed differently.

If the audit turns up systems you're renting and can't leave, that's a solvable situation, not a permanent condition. We build systems businesses own outright, in Clearwater and across Pinellas and Hillsborough counties. If you want a straight read on what's worth replacing and what's fine as-is, book a free strategy session.

Read this next

Understanding what your subscriptions really cost over five years is the foundation for every other decision here. Start with our breakdown of SaaS total cost of ownership versus a custom build.

Related articles

• How to calculate the true cost of per-seat software across a growing team
• Who owns your code? A plain-English guide to software IP for business owners
• Data portability: how to test whether your platform will really let you leave
• Replacing a spreadsheet that runs your business, without breaking operations