Fix the Process Before You Buy the Software

A buyer does not care whether your software is current. They care whether your company can answer a question it was not expecting, accurately, within a few days, from a system someone other than you can run. Buying a new system before a sale helps only if it makes that true. Often it does the opposite.

Automating a bad process gets you lost faster

Software does not fix a process. It runs the process faster and in more places at once. A broken process becomes broken at scale, and its output looks more trustworthy than the spreadsheet it replaced, which makes the errors harder to question.

Before any system decision, ask three blunt questions.

Necessity. Is it actually necessary? Not useful, not impressive. Necessary, meaning something the company must do cannot be done without it.

Competency. Is this your core competency? If not, you are proposing to become good at something new while also running the business, and while also preparing it for sale.

Replacement. Is it replacing work being done by hand today? If it is not, the work is new, and it has to justify itself on its own terms.

One more. If the company cannot meet a standard with its current practices, new software will not make it comply. The standard was not failing for lack of a system.

Never let the vendor define the scope

The most common mistake on a system project is letting the vendor decide what the project is. It does not feel like a decision. You have a problem you cannot fully describe, the vendor has a demo and a discovery call, and by the end of it your problem has been described back to you in the shape of what they sell. Everyone is sincere. The scope is still theirs.

The fix is cheap. Before anyone sees a demo, someone who works for you and not the vendor writes down what the company needs the system to do, in your own language and in terms of outcomes rather than features. Vendors respond to that document, and you measure them against it afterward.

Then budget honestly. The license is the part that arrives with a price on it. Support, oversight, data migration, and the time of the people who will run it are real costs. Leaving them out is how a project gets approved and then quietly abandoned halfway through, which in the year before a sale is the worst outcome available, because a buyer now sees two half-working systems instead of one.

Find where your numbers actually come from

The question that decides how your diligence goes is simple: when someone in your company needs a number, where do they get it?

If the honest answer is that the system produces something close and then a person adjusts it in a spreadsheet, the spreadsheet is your real system of record. That happens for reasons that are nobody’s fault. The official system is slow, or cannot produce the one view that matters, so a capable person builds what they need. Within a couple of years the company’s actual numbers live in a file one person understands.

A buyer will find that file, usually by asking for something it alone can produce and watching how long the answer takes.

Writing the requirements first

Illustrative. Mei owns a property management company running about four thousand residential units. Two years before she planned to sell, a software vendor pitched her an all-in-one platform covering leasing, maintenance, accounting, and owner reporting.

Instead of starting with the demo, she had her controller write a two-page list of what the company actually needed to produce: owner statements by property that tied to the general ledger, maintenance cost per unit by building, and occupancy and delinquency by month for three years. Measured against that list, the new platform did most of it well and one critical piece badly. It could not carry three years of history over from the old system.

Mei bought it anyway, but with the history migration written into the contract and a three-month period running both systems in parallel. When a buyer later asked for three years of owner statements and delinquency by property, the answer came out of one system in two days.

What a buyer will ask for

The requests are not exotic. Some version of these comes early in nearly every sale:

• Revenue by customer, by product, and by month for three years, tying to the financial statements.
• Gross margin by product or service line, with any allocation method stated.
• A customer list with start dates, so retention can be calculated rather than asserted.
• Headcount by function over time, with compensation.
• Receivables and payables aging at several past dates, not just today.

If each takes a week and ends in a spreadsheet nobody else can check, you will still get through diligence. It will just take longer, cost more, and leave the buyer believing a little less of what you told them at the start. How fast you answer the first requests matters more than most owners realize; see what a buyer asks for first, and what being slow costs you.

Time is the real cost

Weak systems rarely cost you the price of software. They cost time, and time in a sale is not neutral. Every week diligence runs long is a week in which a customer can give notice, a quarter can come in soft, or a buyer’s investment committee can lose its enthusiasm. That drift is often how deals die, as deals do not die over money explains.

The question is not whether your technology is up to date. It is whether your company can answer questions about itself quickly enough that nobody has time to get nervous.

---

This is what we do. Prism Edge works out where your real numbers come from, decides with you whether a new system is necessary at all, and writes the requirements before any vendor gets to. If you do buy, we make sure it can produce what a buyer will ask for before a buyer asks.

The full chapter on systems that hold up in diligence, including a seven-figure software project that would have ended in the same phone call, is in Enhancing Your Business Value, free to download here.