Inventory software is any system that records what stock you hold, where it is and how it moves, and for most businesses the real choice is between three options: keep the spreadsheet, buy an inventory product, or build a custom system. Keep the spreadsheet while one person owns it and stock moves slowly. Buy a product when your operation looks like most others in your trade. Build only when the way you handle stock is unusual in a way no product supports, and the workarounds are costing you every week.
The three honest options for inventory software
| Option | Suits | Stops working when |
|---|---|---|
| Spreadsheet | One or two people, one location, a modest range, stock counted periodically | Several people edit it, stock moves daily, and nobody can say who changed a figure |
| Off-the-shelf inventory product | Standard buy, store and sell flows, common sales channels and accounting packages | Your units, location rules or integrations fall outside what the product models |
| Custom system | Stock handling that is unusual and central to how you operate | It rarely stops fitting, but you own the maintenance, and it is overkill where a product fits |
I build custom systems for a living, so I have a stake in the third row. I would still tell most small businesses to exhaust the first two before spending money with anyone like me. The reasoning is the same as in any custom software versus off-the-shelf decision: buy what is common, and build only what is specific to you.
Signs the spreadsheet has stopped working
A spreadsheet is a perfectly good inventory tool at small scale. The trouble starts when it quietly becomes the system of record for an operation it was never designed to hold. These are the signs I would look for:
- The number on screen and the number on the shelf disagree, and nobody can say when they parted company.
- A quantity was overwritten and the old value is gone. Version history can tell you the file changed, but not why twelve became nine.
- You sold something you did not have, because the sheet is updated at the end of the day.
- A transfer between two sites means subtracting in one tab and adding in another, and sometimes only half of that gets done.
- Reordering depends on someone remembering to look.
One of these is tolerable. Three or four together mean the spreadsheet is carrying more than it can.
The underlying cause is structural. A spreadsheet stores quantities: the current number in a cell. Every update overwrites the last one, so the history of how you got there is lost the moment you type.
What off-the-shelf inventory products do well
For a business whose stock flow looks like most others, an inventory product is the right answer, and a custom build would be a waste of money. On day one you get:
- The core loop: purchase orders, receiving, sales orders, picking, adjustments and stock counts.
- Reorder points and low-stock alerts.
- Barcode support, often with a mobile app.
- Ready-made connections to the popular e-commerce platforms, marketplaces, accounting packages and shipping carriers.
- Somebody else who patches, secures and improves it.
Check what you already own, too. Most accounting packages and e-commerce platforms include basic stock tracking. If you sell through one channel from one location, that may be all the inventory software you need.
When you trial a product, test it with your three most awkward items, not your simplest. That is where fit fails, and it is far cheaper to find out in a trial than after migration.
Where off-the-shelf stops fitting
Products are built for the common case, and they tend to stop fitting in three places.
Unusual units
Buying by the pallet, storing by the case and selling singly is ordinary, and most products convert between those. The harder cases are different in kind: goods sold by actual weight where every piece differs, cable or fabric cut to length where the remnant is still stock, batches with expiry dates, serial-numbered units, kits assembled from components, and items that go out on loan and come back. Some products handle some of these. Fewer handle your particular combination.
Multi-location rules
A "location" field is easy. Rules about locations are harder: stock in vans, stock on consignment at a customer's premises that you still own, stock in transit, stock in quarantine until it passes inspection, and rules about which site fulfils which order. If you depend on rules like these, check whether a product models them or merely lets you label things.
Integration with a specific ERP or marketplace
Vendors build connectors for the systems most of their customers use. If your ERP is older, heavily customised or from a regional vendor, or you sell on a niche marketplace, you may find no connector exists. Then stock levels travel between systems by export and import, on a delay, and the delay is where overselling comes from.
When integration is the whole problem, the right custom work is sometimes only the connector, with a bought product on one side of it. That is a much smaller job than a full inventory system.
Is online database software a middle option?
Often, yes. Online database software, meaning tools such as Airtable and its peers, gives you linked tables, forms, views, permissions and simple automations without writing code. It sits between a spreadsheet and a built application.
Using it as inventory database software
It works well when the main need is structure: a proper item list, a table of stock movements linked to it, and several people working at once. It becomes strained when you need strict rules, such as refusing a movement that would take stock below zero, or fast scanning, or use without a signal. Before committing, test what happens when two people move the same stock at the same moment, and check the record and automation limits against your real volumes. I compare the two routes in low-code vs custom development.
Working through this on a real project?
Tell us what you are building or fixing. A senior engineer will give you a straight view of it, including when the honest answer is that you do not need us.
The data model: items, locations and movements
This is the one technical idea worth understanding before you buy or build anything, because it separates real inventory systems from spreadsheets with a login screen. A sound system is built on three things.
- Items. What you stock: a code, a description, a unit of measure, and batch or serial tracking where you need it.
- Locations. Anywhere stock can be: a warehouse, a shelf, a bin, a van, a customer's site, or "in transit".
- Movements. Every event that changes stock: a receipt, a sale, a transfer, an adjustment, a count correction. Each movement records the item, where it came from, where it went, how many, when, who did it and why.
The quantity on hand is not a number somebody edits. It is the sum of the movements, in the same way a bank balance is the sum of the transactions on the account. Here is an illustrative example for a single item:
| Movement | From | To | Quantity |
|---|---|---|---|
| Receipt against a purchase order | Supplier | Main warehouse | 100 |
| Transfer | Main warehouse | Van 2 | 20 |
| Sale | Van 2 | Customer | 5 |
| Count correction | Main warehouse | Written off | 1 |
The main warehouse now holds 79 and the van holds 15. Nobody typed either figure. Because of that, you can see exactly why each number is what it is, you can ask what stock was on any past date, and a transfer cannot be half done, since it is one movement with a from and a to.
One refinement matters in practice: the difference between stock on hand, stock reserved for orders already taken, and stock available to sell. A system should show all three.
A quick test for any product or proposal is to ask to see the full movement history of one item. If the system can only show you today's quantities, it has the same structural weakness as the spreadsheet.
Barcode scanning and offline use
Scanning
Scanning makes recording a movement faster and more accurate than typing. Most dedicated handheld scanners behave like a keyboard: scan a code and it is typed into whichever field has focus, so they work with a web application without special drivers. A phone camera can also read barcodes from inside a web page, which in my experience is fine for occasional scans and slower for sustained volume.
Use the manufacturer's barcode where one exists, and print your own labels for locations and unlabelled items. A good receiving screen is scan the location, scan the item, confirm the quantity, done.
Offline
Warehouses, cold rooms, yards and vans often have poor signal, and there are three levels of answer:
- Online only. Simple, and it fails the moment the signal drops.
- Tolerant of a weak signal. The screen keeps what was entered and retries until it gets through. This is affordable and enough for many sites.
- Fully offline. The device holds a local copy, records movements with no connection and synchronises later. This can be done in a native app or in a progressive web app, and it is a real step up in cost and testing.
The hard part of full offline working is conflict: two devices can both issue the last unit while out of contact. With a movement model, each device queues its movements and the server applies them all, then flags any negative stock for a person to resolve. Even so, be honest about whether you need level three or would be well served by level two.
Custom inventory management software: what a build involves
A custom build starts on the floor. Someone walks the route stock takes through your business with the people who handle it, and writes down what actually happens, exceptions included. From that come the data model, the screens for receiving, moving, issuing and counting, permissions, scanning, integrations, reports, data import and training.
You also take on ownership. No vendor ships improvements to your system, so changes have to be built and somebody has to look after hosting, backups and security updates. Plan for that running cost. I go through the full picture in the real cost of custom software.
A build is justified when most of these are true:
- You have trialled products with your awkward cases, and the misfit is in something central to how you operate.
- People keep side spreadsheets next to a product you already pay for.
- An integration you depend on does not exist and cannot be bridged sensibly.
- Per-user pricing fits badly because many of your users only scan occasionally.
It is not justified when your flow is standard, when the complaints about a product are cosmetic, or when you expect the result to need no upkeep.
If you do build, start with one flow, such as goods in or van stock, and extend from there. Yarqat sells a fixed-scope offer for that kind of first slice, Ops App in 30 Days: one workflow, scoped in a paid discovery session, then built as a web application in about thirty days at a fixed price against a written scope, with your live data imported and the code in your own repository. It covers one workflow, not a whole warehouse system. A build that needs genuine offline synchronisation or several integrations is a bigger project, and it would be scoped and quoted as one.
Migration: moving off the spreadsheet
Migration is where inventory projects go wrong, whichever option you chose, so the order matters.
- Clean the item list first. Merge duplicates, settle on one name and one code per item, and fix units of measure.
- Decide what history to bring. Usually the answer is opening balances only. Keep the old spreadsheet as a read-only archive.
- Set up and label locations. Every place stock can sit needs a name in the system and, ideally, a label on the shelf.
- Count everything at cutover. A full physical count becomes the opening movements. Starting from the spreadsheet's figures imports its errors.
- Pick one cutover moment. Choose a quiet period, freeze the spreadsheet, and from then on record every movement only in the new system. A long parallel run sounds safe, but two records of the same stock drift apart quickly and then nobody trusts either.
- Count again a few weeks later. Spot counts show whether movements are being recorded as they happen. If they are not, that is a habit to fix.
If no product fits and you want a straight view on whether a build is worth it, that is the question our custom software development work begins with.
Inventory software: common questions
What is the best inventory software for a small business?
The one that fits how your stock actually moves. Start with the stock features in the accounting or e-commerce platform you already pay for. If those fall short, trial dedicated products using your most awkward items. Only consider a build if they fail on something central.
Can online database software replace an inventory system?
For a small operation, often yes. It gives you linked tables, forms and multiple users, which is a real step up from a spreadsheet. Test strict stock rules, scanning and offline use before you rely on it.
What is inventory database software?
It is software that keeps stock as related records, typically items, locations and movements, instead of numbers in cells. Stock levels are calculated from recorded movements, which gives you a history and an audit trail.
When is custom inventory management software worth the cost?
When your units, location rules or integrations are unusual, they are central to how you operate, and a trial has confirmed that products cannot model them. If the misfit is minor, adapting your process to a product is cheaper.
