Before signing for any business software, check five things: that it handles your three most frequent daily tasks in a real trial with your own data, that you can export everything in a usable format, what the full yearly cost is once users and add-ons are counted, who supports you and how fast, and how you would leave. Most bad purchases come from a polished demo, not from bad software.
Why the sales demo is the most misleading part of buying software
A vendor demo is a rehearsed path through the product. The salesperson knows which screens are fast, which reports look impressive and which features are still rough, and the demo quietly avoids the rough parts. That is not dishonesty so much as the nature of selling. The problem is that a small business owner often decides during that hour, because the demo is the only time anyone looks at the product closely.
What the demo never shows is your own mess. Your customer list has duplicates, your product codes changed twice, one branch writes dates differently, and your best salesperson keeps notes in a phone app. Software that looks clean with sample data can become painful once it meets real records. The first week of importing often reveals more than the whole sales process.
The demo also hides the daily rhythm. A feature you use once a month can be clumsy without hurting anyone. A screen your cashier opens two hundred times a day must be quick, readable on the device they actually use and forgiving of mistakes. Ten extra seconds on a frequent task adds up to hours of lost time and, worse, to staff quietly returning to the old notebook.
So treat the demo as a brochure, not as evidence. The evidence comes from a trial where your people do their real work, with real data, on the computers and phones they really have, including the slow ones in the back office.
A selection process a small team can actually run
This process fits a company of five to fifty people and usually takes three to six weeks. It is deliberately boring, because boring is what protects your money.
- Write down the three to five tasks that happen most often. Not features, tasks: "create an invoice for a returning customer", "check stock before promising delivery". Frequency matters more than importance here.
- Name one owner for the decision. Someone who will use the system daily and has time to test it. A committee without an owner tends to buy whatever the boss saw last.
- Shortlist two or three options, never ten. Ask peers in the same trade what they use and what they regret. Regret is more useful than praise.
- Run a trial with real data. Import a slice of your actual customers, products or orders. If the vendor will not allow a real trial, take that as information.
- Let the actual users do the tasks. Watch where they hesitate, where they reach for paper, and which steps they skip. Do not help them; you will not be there later either.
- Test the way out before the way in. Export everything you entered during the trial and open it in a spreadsheet. Check that names, dates and amounts are intact.
- Price the full year in writing. Ask for a written quote that covers users, branches, storage, add-ons and support for twelve months, then compare the totals, not the monthly headline.
If two options tie, choose the one your least technical employee found easier. That person decides whether the system survives.
Hidden costs that rarely appear on the pricing page
Per-user pricing that grows with you. A low price for three users looks very different when seasonal staff, accountants and branch managers all need logins.
Add-on modules. Inventory, payroll, e-invoicing connections or multi-branch reports are often sold separately. Ask which of your five core tasks need an add-on.
Data migration. Moving years of records from old files is real work. Someone has to clean, map and check it, whether that is your staff or a paid consultant.
Training time. Every hour staff spend learning is an hour not serving customers. Budget it honestly, especially during peak season.
Integration fees. Connecting to your bank, your sales channels or your accounting tool may need paid connectors or custom work.
Hardware upgrades. Older office computers or cheap phones may run a modern web app slowly. Test on the worst device you own.
Price changes at renewal. Introductory prices end. Ask how renewal pricing is decided and whether you get notice before it changes.
The cost of switching later. If leaving would take months of work, that future cost belongs in today's comparison.
Questions to ask the vendor, and what a good answer sounds like
Ask these in writing and keep the replies. Vague answers are not always bad faith, but they are always a risk.
| Question | Good sign | Warning sign |
|---|---|---|
| Can we export all our data, any time? | Yes, in common formats, without a fee; they show you how | "Our team can do that for you on request" |
| Where is our data stored and who can access it? | Clear answer on location, access roles and backups | Marketing language with no specifics |
| What happens if we stop paying? | Read-only access or an export window for a set period | Data deleted immediately or unclear |
| How is support provided? | Named channels, response time stated, local language available | "Contact us any time" with no details |
| Which of our core tasks need add-ons? | A direct list mapped to your tasks | Avoids the question, offers a bigger package |
| Can we talk to a current customer like us? | Gives a reference in a similar trade and size | Only large brand names, no peers |
| How do price increases work? | Written notice period and a clear policy | "Prices rarely change" |
Keep these answers with the contract. When something goes wrong a year later, they are the only record of what you were promised.
Plan your exit before you plan your rollout
Vendor lock-in rarely comes from one dramatic clause. It builds up slowly: custom fields only the vendor can edit, reports that exist nowhere else, workflows wired to their own payment tool. After two years the business runs on habits that live inside one product, and leaving feels impossible even when the service gets worse.
The simplest protection is to own your data in practice, not just on paper. Schedule a monthly export of customers, products and transactions to a folder you control. It takes minutes, and it turns a disaster into an inconvenience if the vendor raises prices, gets acquired or shuts down.
Also keep the master accounts in the company's name. Admin logins tied to a former employee's personal email are a common and painful problem. Use a shared company address for the owner account, turn on two-factor authentication and record who holds which role.
Finally, read the termination and data sections of the contract before signing, even if the rest feels like legal noise. If the wording is unclear, ask for clarification in writing or have a lawyer review it. A small fee now costs far less than negotiating for your own records later.
Frequently asked questions
Is free software a good choice for a small business?
It can be, for simple needs, but check who maintains it, whether you can export data and what happens when you outgrow the free tier. Free tools often limit users or storage in ways that bite once the business grows.
How long should a software trial last?
Long enough to cover at least one full business cycle that matters, such as a month-end close or a busy weekend. Two weeks of real use usually reveals more than two months of casual clicking.
Should we buy one all-in-one system or several specialised tools?
All-in-one systems reduce connection problems but make you depend on one vendor for everything. Several tools give flexibility but need someone to keep the data flowing between them. Small teams without IT staff often do better with fewer, simpler pieces.
What if the vendor will not let us trial with real data?
Ask why, and offer to use a small anonymised sample instead. If they still refuse, weigh that heavily, because you will discover the real fit only after paying.
Do we need a consultant to choose software?
Not usually for small, standard needs if one person owns the process. A consultant helps when processes are complex, several branches must share data, or the contract is large; make sure they are not paid commission by the vendor they recommend.
