Why Fixing Your Software Stack Should Come Before AI

AI was on the list. It ended up seventh.

A community nonprofit came to me because its software barely worked together. Information had to be moved manually, important systems couldn't share data and the accounting platform sat in the middle of several problems.

The organization was interested in AI, but adding another tool wasn't going to fix any of that. Before we could decide where AI belonged, we needed to understand the software they already had.

What did the software audit reveal?

The software audit found more than 20 different products in use across the organization.

That number sounds alarming, but the number of products wasn't the real problem. Some were useful and did exactly what the team needed. Others overlapped, weren't being used fully or created extra work because they couldn't communicate with anything else.

We reviewed each product using a few practical questions:

• What does it actually do?
• Who uses it and how often?
• What information goes into it?
• Where does that information need to go next?
• What happens when it doesn't work?
• Is it solving a meaningful problem or simply still there?

That last question matters. Software has a way of becoming permanent because cancelling it feels riskier than continuing to pay for it. Meanwhile, staff build spreadsheets, email reminders and manual workarounds around the gaps.

By the end of the audit, we had more than a list of subscriptions. We could see which products affected the most people, where information was getting stuck and which change would make several other improvements possible.

Why did accounting become the first priority?

The accounting platform became the first priority because too many other systems depended on it.

The nonprofit was using Sage 50. In their setup, it lived on the desktop, access was limited to a few users and several products couldn't send information to it directly. That meant staff had to move information between systems or wait for someone with access to do it.

Sage 50 wasn't automatically the wrong product because it was older or desktop-based. It was the wrong fit because it had become a bottleneck for the way this organization now operated.

After reviewing the options, the nonprofit chose Xero. It could connect with the organization's ecommerce platform and several other products already in use. One accounting migration could remove multiple manual handoffs and create a better foundation for future reporting.

This is why technology priorities can't be chosen one product at a time. Replacing the loudest or most annoying tool might feel productive, but the best first project is often the one that makes 3 or 4 other projects easier.

That dependency thinking is central to how I approach technology decisions: understand the process and the information flow first, then choose the software that supports them.

Why was the AI project number 7?

AI became project number 7 because the first 6 projects addressed problems the organization was already experiencing every day.

The roadmap included connecting existing systems, removing products that weren't providing enough value and improving several operational processes. AI still had a place, but it wasn't more urgent than unreliable data, repeated entry and systems that couldn't share basic information.

Imagine adding AI to the original setup. Which of the 20 products would it use as its source? Which version of the information would it trust? Would it have access to current accounting, appointment and inventory data, or would staff need to copy that information into one more place?

AI can summarize, classify and generate. It can't decide which of 4 conflicting records is the truth unless someone has already designed that process.

The nonprofit didn't reject AI. It sequenced it.

By putting the foundational projects first, the organization is improving the information and processes that a future AI project will rely on. When project 7 begins, it can solve a defined problem instead of becoming tool number 21.

What else belonged on the roadmap?

Not every roadmap project involved replacing software. Some of the best improvements came from changing the process around an existing tool.

One project focused on making it easier for the nonprofit's clients to book service appointments. The organization already had much of the technology it needed. The work was to simplify the experience and connect the process properly.

Another involved delivery. An outside vendor had become unreliable, so the nonprofit decided to bring the work back inside the organization using its existing team and tools. That wasn't a software purchase at all. It was an operational decision made clearer by understanding the full process.

Inventory management and reporting are also on the roadmap, but that work hasn't happened yet. Their place in the sequence matters. Better reporting depends on the underlying information being captured consistently. Improving the dashboard before fixing the data would produce a nicer view of the same uncertainty.

A useful technology roadmap can include:

• Products to replace
• Integrations to build
• Software to retire
• Processes to simplify
• Work to bring in-house or send out
• Information that needs a clear owner
• AI opportunities worth revisiting later

The roadmap isn't a shopping list. It's an order of operations.

How can you audit your own software stack?

Start with a spreadsheet or a sheet of paper. You don't need specialized software to understand the software you already have.

For every product, record:

1. Its purpose. Write one sentence describing the job it performs. If nobody can explain that clearly, flag it.
2. Its users. List who uses it, who administers it and who is affected when it fails.
3. Its information. Note what enters the product, what leaves it and where that information needs to go next.
4. Its workarounds. Record every spreadsheet, repeated entry, emailed file or reminder needed to keep the process moving.
5. Its impact. Describe the operational cost when the product is slow, inaccessible or wrong.
6. Its connections. Identify which other improvements depend on changing or integrating it.
7. Its decision. Keep it, connect it, replace it, retire it or investigate further.

Then look for the first domino. Which project would remove the most repeated work, improve the most important information or make several other projects possible?

That project may involve AI. More often, it involves fixing something less exciting that everyone has quietly worked around for years.

Fix that first. AI will still be there when the foundation is ready for it.

Frequently asked questions