The best inventory tools for small teams (and when to build instead)
Inventory software splits into three categories that solve different problems. Buying from the wrong category is the most common and most expensive mistake.
Inventory software looks like one market and is actually three. Most bad purchases come from buying in the wrong one, so start by working out which problem you have.
On pricing: plans, tiers and per-location charges in this market change frequently, and per-order pricing models make headline figures misleading. This article does not quote prices. Get a quote based on your order volume and location count.
The three categories
1. Commerce inventory. You sell physical products through shops or online channels, and inventory must stay in sync with sales channels. The hard problem is channel synchronisation — not overselling the last unit across three storefronts.
2. Operational inventory. You hold stock to use rather than to sell: parts, consumables, materials, equipment. The hard problem is knowing what you have and when to reorder.
3. Warehouse operations. Volume is high enough that picking efficiency, bin locations and labour throughput are the problem. This is WMS territory.
Buying a commerce tool for an operational problem is the classic error. You get sales-channel features you will never use and lose the flexibility you actually needed.
Category 1: commerce inventory
If you sell through Shopify, Amazon, eBay or a physical till, buy something built for it. Channel sync is genuinely hard and not worth rebuilding.
What to look for:
- Native connectors to your specific channels, not "integrations available".
- How fast stock syncs after a sale, and what happens during an outage.
- Multi-location allocation, if you ship from more than one place.
- Bundles and kits, if you sell them — a common gap.
- Purchase orders and supplier lead times.
Options worth looking at: Cin7, Katana (strong for light manufacturing), Zoho Inventory, inFlow, Ordoro, and Shopify's own tooling if you are single-channel. Sortly is popular at the simpler end and for asset-style tracking.
The decision that matters: which system owns the stock number. If your e-commerce platform and your inventory tool both think they are authoritative, you will oversell. Decide, configure accordingly, and test it deliberately before you trust it.
Category 2: operational inventory
This is where most small teams actually sit, and where the market serves them worst — because the packaged tools assume you are selling.
If you hold parts, consumables or materials, your requirements are usually:
- Stock on hand by location, accurately.
- Reorder alerts based on real usage.
- Traceability: who took what, when, for which job.
- Links to the rest of your operation — jobs, assets, suppliers, projects.
That last requirement is the one packaged tools handle badly, because they own the stock record and do not want to share it. If your stock needs to link to your job records, and your jobs live elsewhere, you end up reconciling two systems by hand — which is what you were trying to escape.
This is the strongest case for building it yourself in a relational workspace. Three tables gets you a working system:
- Products — SKU, category, reorder point, supplier.
- Locations — warehouses, vans, shelves, "in repair".
- Stock movements — signed quantities with a type and a cause.
Stock on hand is then a rollup of movements, not a number anyone edits. It cannot be wrong, and every unit is traceable to the receipt, sale or adjustment that produced it. Full build in build an inventory system that reconciles itself.
The reason this works well is that stock links naturally to everything else you already model — jobs, assets, purchase orders, suppliers — instead of living in a separate silo.
Category 3: warehouse operations
If you have staff whose whole job is picking, and the constraint is labour throughput rather than knowing what you have, you need a WMS with barcode scanning, pick paths and bin management.
Do not build this. The interaction design of a scanning workflow is genuinely hard, and getting it wrong costs picker-hours every single day.
The build-versus-buy test
Buy when:
- You sell through channels that need syncing. Non-negotiable.
- You need barcode scanning workflows at volume.
- Compliance requires specific traceability — food, pharma, aerospace — and you need certification rather than a good design.
- Nobody on the team wants to own a build.
Build when:
- Stock supports operations rather than being sold directly.
- Inventory must link to jobs, assets or projects that already live in your systems.
- Your process does not match the packaged shapes — hire stock, consignment, serialised assets that move between customers.
- You have tried two packaged tools and both needed a spreadsheet alongside them.
That last signal is decisive. If every packaged tool leaves you maintaining a spreadsheet to bridge a gap, the gap is your actual requirement, and no amount of shopping will close it.
What to insist on, whatever you choose
1. Stock on hand must be derived, not edited. If any user can type into an on-hand figure, the number means nothing and you will never find out why it drifted. Movements-based systems can explain themselves; state-based ones cannot.
2. Adjustments need reasons. Shrinkage you cannot categorise is shrinkage you cannot fix.
3. Locations from day one. Without them, damaged goods, goods in transit and sellable goods all count as available, and you will promise stock you cannot ship.
4. Units of measure must be explicit. You buy in cases and sell in units. Systems that leave this implicit produce one memorable, expensive ordering error.
5. Available, not on hand. The number that should drive decisions is on-hand minus allocated. Check the tool distinguishes them.
The honest recommendation
Selling online or in shops — buy a commerce inventory tool. Choose on channel-connector quality for your specific channels.
Holding stock to use, linked to your operations — build it in a relational workspace. Three tables, an afternoon, and it connects to the rest of your data instead of fighting it.
High-volume picking — buy a WMS.
Under 200 SKUs and one location — a movements table in whatever you already use is genuinely fine. Do not buy software for this yet.
The most expensive mistake is not choosing a slightly worse tool. It is buying a commerce platform for an operational problem, spending two months implementing it, and still keeping the spreadsheet — because the spreadsheet is where stock connects to the jobs it is actually for.