The interesting thing about QR code inventory tracking is not the QR codes. That part has been a solved problem for twenty years.
What is interesting is that the economics underneath the decision have moved, and most of the comparison articles on this subject are still working from the old ones. They assume buying is cheap and obvious and building is a six-month capital project. The first half is still true. The second half is a lot less true than it was three years ago.
So rather than tell you what to do, here is what the market actually charges, what you get for it, and what the considerations look like once the build side is cheaper than it used to be.
What the products cost
Every figure below was read from the vendor's own pricing page on October 30, 2026. I have deliberately not used the comparison blogs that rank for these terms — a lot of them are written by competitors, and when I checked their numbers against the vendors they disagreed with the vendors and with each other. These will drift, so treat them as a snapshot and check before you sign anything.
| Product | Entry price | What the entry tier holds | API |
|---|---|---|---|
| Snipe-IT self-hosted |
$0 | Unlimited assets, unlimited users | Included, 120 req/min |
| Snipe-IT hosted |
$39.99/mo | Unlimited assets, unlimited users | Included |
| Sortly | $0 free $24/mo Advanced |
100 items / 1 user 500 items / 2 users |
Enterprise only price not published |
| MaintainX | $0 Basic $20/user/mo |
Per-user pricing, no item cap published | $65/user/mo Premium tier |
| EZOfficeInventory | $81.41/mo | Up to 5,000 units, unlimited users | Not stated on the pricing page |
| Asset Panda | No pricing published. A work email and a 30-minute call produce a custom quote. | Not stated | |
A few things are worth reading off that table rather than past it.
Sortly's headline prices are first-year prices. Advanced shows $24 against a struck-through $49, Ultra $74 against $149, Premium $149 against $299. The page says the discount applies to new subscriptions and that a 20% discount applies to yearly plans after the first year. So the year-two number is not the number on the button.
The caps are tighter than they look. Sortly's Advanced tier holds 500 items and two user licenses. Ultra is 2,000 items and five. For a lot of businesses the item count is fine and the seat count is the thing that forces an upgrade, which is a different budget conversation than the one you thought you were having.
And then there is the API.
The API is the most expensive feature in the category
Look down that last column. The ability to connect the system to anything else — your accounting, your order system, a nightly export, anything — is consistently the thing that costs the most.
MaintainX publishes it plainly: the Open REST API arrives on Premium at $65 per user per month, against $20 for the tier below. That is more than triple, for one capability. Sortly's help center and developer documentation both state that the API is available exclusively on the Enterprise plan, whose price is not published; access is OAuth 2.0, rate-limited to 1,000 requests per key per fifteen minutes, and the account owner has to request it through support. EZOfficeInventory's pricing page does not say either way. Asset Panda will tell you after the call.
The outlier is Snipe-IT, which is open source: the self-hosted edition is free, holds unlimited assets and unlimited users, and includes the REST API at 120 requests a minute. Their page is blunt about it — the software "is and always will be free." What you give up is spelled out just as plainly: no automated upgrades, no automatic backups, no TLS certificate, no email support. You are running a server, with everything that implies.
None of which makes any of these products a bad choice. It makes the API a pricing lever, which is an entirely rational thing for a vendor to do and a useful thing for a buyer to notice. When you buy software you are buying a set of constraints on what it can connect to. That used to be a reasonable trade, because writing the integration yourself was expensive too.
What has actually changed about building
Here is the part the older comparisons miss.
The expensive hours in a build like this were never the clever parts. They were the predictable parts: the create-read-update-delete screens, the permission plumbing, the import that has to cope with a messy spreadsheet, the label generation, the glue code against somebody else's API. Hundreds of hours of work that was tedious rather than hard.
That is precisely the work AI coding tools have taken a bite out of. Not the thinking — the typing. And because the integration glue was always among the most mechanical code in the project, the thing the vendors are charging a premium to let you do is the thing that got cheapest to do yourself.
Be careful how far you take that, though, because plenty did not change:
- Knowing what to build. A tool that writes code quickly will happily build you the wrong data model very fast. The decision about what a record is remains the whole job, and it is the decision that is expensive to reverse.
- Whether anyone uses it. See below. No amount of generated code fixes an adoption problem.
- Operations. Backups you have actually restored from, a certificate that renews itself, monitoring, somebody to call. This is the real content of the Snipe-IT trade-off, and it is why "free" and "free" are different words in that table.
- Ownership. A subscription you stop paying for stops being your problem. Something you built is yours in both directions.
So the honest version is not "building is cheaper now." It is that the crossover point moved. Buying still wins comfortably at the simple end. It just stops winning sooner than it used to — and it stops winning fastest when the product caps what you can hold, charges for the connection, or cannot model the thing you actually track.
The distinction that decides which category you are even shopping in
Two different problems get searched with the same words, and buying the wrong category is the most common expensive mistake here.
| Inventory | Assets | |
|---|---|---|
| What it is | Stock that moves through and gets consumed or sold | Things you keep and maintain |
| The question it answers | How many, and where | Which one, and what has been done to it |
| How it gets tagged | By type, then counted | Individually, one code per item |
| What a scan does | Adjusts a quantity | Opens a history |
| What you regret | Counts that drifted from reality | Not knowing when it was last serviced |
The practical consequence: inventory software usually cannot record that a specific physical object was repaired, because it does not believe individual objects exist — it tracks forty of a thing, not that one. If what you have is equipment with a service history, an inventory product will feel almost right for about a month and then hit a wall you cannot work around.
Plenty of businesses have both, which is fine. They are just two kinds of record, and knowing that up front is cheaper than discovering it later.
The considerations, in the order they actually bite
1. Can the product model the thing you track? Products assume items, quantities and locations. If what you track is a partial roll, a batch with a cure date, a serialized component inside an assembly, or something measured in a unit that changes as it moves through the shop, you will spend the engagement fighting the data model. Any product can store a number. The question is whether it understands what your number means.
2. Does the scan start a process, or adjust a count? If scanning should assign work to someone, trigger a reorder against rules you wrote, print a document, notify a customer, or move a job to its next stage, you are describing a workflow with a barcode on the front. The product will give you the barcode and none of the workflow.
3. What does it have to talk to, and what does that cost? This is the one to price before you commit, not after. Work out which tier carries the API, multiply it by your seat count, and compare that number rather than the headline. A $20 plan that becomes a $65 plan the moment you need an integration is a $65 plan.
4. Does the record have to leave in someone else's format? A lot of business-to-business relationships come with a data obligation attached — not just product, but a file, in a layout that is theirs, on a cadence that is theirs. Generic exports are built to be generically useful, which is a different thing from being accepted by a specific trading partner. I have written about what that looks like at a label manufacturer, where the daily outbound file was the whole point.
5. Who runs it at two in the morning? Self-hosting anything, including the free option in that table, means backups, certificates, upgrades and monitoring are now yours. That is a real cost and it is the one most often left out of a build-versus-buy spreadsheet.
6. Does it already work in a spreadsheet? If the tracking exists and the pain is that one workbook holds it, one person understands it, and nobody dares touch it, you do not have a software selection problem. You have a spreadsheet that outgrew itself, and the business rules are already written down — just written down in a workbook.
The scan is not the hard part
Whichever way you go, this is what determines the outcome.
These projects do not fail on software. They fail on whether anyone keeps scanning. Somebody holding a box with one hand, or with dirty hands and a job to finish, will not log in to anything. They will not download an app, they will not wait for a splash screen, and they will not fill in nine fields to say a thing moved.
I would rather scope a smaller system people use than a complete one they abandon. That is true whether the system came in a subscription or came from me.
What the code should contain
One concrete decision worth getting right on day one, because it is expensive to reverse once labels are on things.
Encode a web address ending in a short opaque identifier. Nothing else.
It is tempting to put the useful information in the code — the description, the location, the part number, the price. Do not. The moment any of it changes, every label carrying it is wrong, and labels are the one part of this system you cannot update remotely. Point at a record instead.
Opaque matters too. A code containing /item/4817 tells anyone who scans it roughly how many items you have and lets them go looking at 4818. A short random identifier does not.
Shorter is also physically better, not just tidier. Fewer encoded characters means fewer modules in the symbol, which means each module is larger at a given label size, which means it scans from further away and survives more scuffing. Shortening the string buys more real-world readability than raising the error-correction level does.
And verify the symbols before they reach a printer. A QR code with one field misplaced looks exactly like a working QR code — the eye cannot catch it, and checking it with the same library that generated it proves nothing, because the bug is symmetric. The mechanism is written up separately in why a QR code can look perfect and scan as nothing. A run of labels that was never readable is an expensive thing to discover six months after it went onto the equipment.
Where to go from here
If what you have is equipment to tag and maintenance to keep on top of — machines, vehicles, tools, anything with a service history — that is asset tracking and preventive maintenance.
If what you have is tracking that already works in a spreadsheet and the spreadsheet has become the risk, that is a spreadsheet-to-web-app problem, and it is usually the easier project because the rules already exist.
And if you want the comparison run properly, the numbers that decide it are: how many things, how many people touching it, what has to happen on a scan, and what it has to talk to. Those four answers price both sides. I publish what a custom internal tool costs for the same reason — it is a comparison you should be able to make before you call anybody.