Choosing inventory software for a small operation: the questions that decide it

01 / FIELD NOTE

Keep the decision tied to the operating context.

A small operation buying inventory software is usually comparing capability lists, and the lists are the least useful part of the comparison. Every product on a shortlist can record stock, produce a report and export a file. What separates them is what happens in the second year, when the person who set it up has moved on and the business has changed shape.

The first question is what the software is the system of record for. Some products are the inventory system and everything else feeds them; others are a layer that reads and writes to something else that remains authoritative. Confusing the two produces a business with two records and a manual reconciliation between them, which is worse than either alone and tends to be discovered only after both are in daily use.

The second is the integration that already exists in the business. Accounting, order management, the sales channel, a spreadsheet that somebody depends on. Whether the new system can read from and write to those, and by what mechanism, decides the real cost of ownership far more than the licence does. An interface that has to be maintained by hand is a recurring cost that rarely appears in the purchasing comparison and always appears in the accounts.

The third is the unit of tracking the software can represent. If the business needs to distinguish individual serialised units and the product only models quantities per product code, the requirement will not be met by configuration. If the business sells in cases and the product insists on unit-level records, the operation will be doing data entry it does not need. Establishing the smallest unit the business must distinguish, and checking that the software models exactly that, prevents both mistakes.

The fourth is where the data lives and what happens if the relationship ends. A system that holds the inventory record in a form the business cannot take with it is a commitment beyond the contract term. Export in a usable structure, and the ability to reconstruct the record elsewhere, are worth more than a marginal feature difference and are rarely asked about at the point of sale.

The fifth is what the software expects a person to do every day. The decisive question is not what it can do but what it requires: how many fields are mandatory, how many steps a receipt takes, what happens when a barcode will not scan. A product that models the operation accurately and demands more attention than the operation can spare will be worked around, and a workaround is a data-quality problem with no owner.

Cost belongs in the comparison as a per-unit figure rather than as a total. Labels, application labour, hardware amortisation, subscription and support all scale with the operation, and a total that looks affordable at pilot scale can be unaffordable at full scale. Knowing the per-unit cost lets the business compare it directly against the cost of the errors it is trying to prevent, which is the only comparison that means anything.

The features worth prioritising are the unglamorous ones: a usable exception queue, an audit history that records who changed what, a permission model that separates counting from adjusting, and a count function fast enough to be used often. These are what determine whether the record stays trustworthy. Reporting and analytics are downstream of a record that is right, and no amount of analysis rescues one that is not.

Integration effort should be estimated before it is promised. Whatever the vendor provides, someone in the business has to understand the data flow, notice when it stops, and know who to call. A small operation often has exactly one such person, and if that person is also running the warehouse, the integration is one absence away from failing silently. Naming who owns it is part of the decision, not an implementation detail.

The starting scope should be one area and one process. Not because the ambition is small, but because a real result in one place produces the evidence needed to justify the next one, and because the process will need correcting after the first attempt. A phased start also limits how much of the business is exposed if the choice turns out to be wrong.

A trial that means something is worth more than a demonstration. Running the candidate software against a genuine week of the operation — real receipts, real counts, real exceptions — surfaces the friction that a guided demonstration is designed to hide. Where a full trial is not possible, asking to see the exception workflow and the count screen, rather than the dashboard, gets closer to the same information.

The decision criteria worth writing down before the comparison begins are the ones that will still matter later: what the smallest tracked unit is, which existing systems must stay authoritative, who owns the record, what the per-unit cost is, and what would make the business stop. A shortlist assessed against those is a different and better-informed comparison than one assessed against a feature matrix — and it is much harder to be talked out of.