Before You Buy Software: Questions Worth Asking, and How to Check Them

Before you sit through a demo, ask around. Is there a well-respected tool built for businesses like yours, in your industry and at roughly your size?

When you talk to people using it, skip "do you like it?" Ask what they work around, whether they'd choose it again, and what happened when they needed something it didn't do.

If there's no clear favourite in your field, the questions below matter more.

Does it fit how you actually work?

Pick the two or three workflows that matter most, and ask them to show you each one, not just say yes. For anything they show you, ask whether it's a built-in setting, an add-on, or custom code someone has to write and maintain.

Then look past the basics. Most tools connect to email and calendars. Where things break is when one event needs to set off several things across your other tools, like a new booking that should update the schedule, notify the right person, and send the invoice. Ask them to show you one of those.

And check what people actually see. Can each person get the information they need without wading through clutter? Can someone who needs to keep a pulse on things get a clear summary without digging?

What will it really cost?

The licence is the easy part to see. Ask what the setup takes, and who does it: their team, yours, or someone you'd bring in. The setup can cost more than the software.

Then ask what happens next. Your processes will change, and the first version will show its cracks once real work runs through it. When that happens, who makes the changes? If every adjustment means bringing the same specialist back in, that's not a one-off cost. It's an ongoing one, and it should be in the budget from the start.

Someone also has to look after it. A tool needs regular care: checking it still works, catching what's quietly broken, keeping it in step with how you work. There are two good ways to handle that.

One is ongoing support from whoever built it. If you go that way, ask whether you'll keep working with the people who set it up, or get handed off to someone starting from scratch. A small fix is quick for the person who built it, and slow and expensive for someone who has to learn your setup first.

The other is someone on your team who learns it properly while it's being built. Ask whether the setup includes training that person, so they can make changes themselves without calling anyone in.

Finally, check the pricing page for the size you expect to grow into. Some of the features you'll need later may sit behind a higher tier.

How much can you change yourselves?

Adding what you need is only half of it. A tool built for every kind of business ships with everything, so ask whether you can hide what you don't use, for the whole team or by role. Then ask what happens when you reach its limits. Every tool has them, which is why most offer some way to go further. The question is how good that way out is, and who on your side could use it. Your peers will know.

Is it still improving?

Every tool follows its maker's priorities, set for all its customers, not just you. So don't take the sales pitch's word for it. Look at the release notes: how often do updates come out, and are they real features or just fixes? Look at the feedback board or forum: do requests get answered, and how old are the most-wanted ones? And search for the problem you're most worried about. A thread where people have been reporting the same bug for years tells you more than any demo.

Can you leave?

Exporting your data is usually the easy part. What makes leaving hard is everything you build around it: the automations, the integrations, the reports. That's what lock-in really is. Before you're in, ask how much of that you could take with you.

Test it in two passes

First, someone who understands your business end to end takes a wide look: does it cover what you do, and does it fit with your other tools? If that looks promising, go deep on one or two critical workflows. Run real work through it with your own data, and bring in the people who'd actually use it day to day. Give it more than a week. Weeks disappear, and you want to see how it holds up in real work. Expect some friction when it rolls out. That's normal, not a sign it's the wrong tool.

If nothing fits, building something of your own might. That's more within reach than it used to be, but it's a different decision, and we've written about it in Custom Software vs Off the Shelf. Either way, if you'd like a second opinion before you commit, tell us what you're weighing up.