An asset tracking app is only as good as the register behind it.
Most asset tracking app projects start with the scanner and stall on the register. Scanning is the easy half: a camera reads a label and hands your code a string. The hard half is what that string points at, which is a row that has to survive years of transfers, repairs, write-offs and one auditor asking where item 1042 was last June. Assets are individuals, not stock, so the counting logic behind inventory tracking apps does not carry over.
This page covers what one asset row has to hold, which items belong in the register at all, why custody has to be a log rather than a column, and what a phone camera can actually read off a tag.
See what belongs in the registerThe short version
Inventory answers how many, an asset register answers which one.
An asset tracking app tracks individuals. Every laptop, drill, trailer and pump gets its own row, its own identifier and its own history, because nobody ever needs to know how many laptops the company owns. They need to know which laptop, where it is, who signed for it, what it cost and whether it still exists.
That makes the register the product and the scanner a convenience. A tool that reads a label but cannot say who held the item on 30 June is not tracking assets. It is reading barcodes.
One asset, one row, one ID that outlives the label
A workable row is short and dull: your own asset ID, a category, make and model, the serial number, purchase date, purchase cost, the cost centre or department that owns it, current site, current custodian, status, and a disposal date once there is one. An equipment tracking app adds a service or calibration due date, because a machine has obligations a laptop does not.
Do not use the serial number as the identifier. Serials get misread off a worn plate, some items ship without one, two vendors will hand you the same string, and a replacement board can change it. Mint your own sequential ID, print that on the label, and keep the serial as an attribute you can search. Then a relabelled item is still the same asset.
Status belongs to a short closed list, not a free text box: in service, in for repair, in store, retired, lost. Free text gives you seven spellings of broken by the end of the year. Retired and lost rows stay in the register with a date and a reason, because deleting the row is what makes a company asset register app unusable at audit. The label is the consumable here, not the record. When it gets painted over or pressure washed off, print another label with the same ID rather than issuing a new one.
What actually belongs in the register
Two different questions get answered with one list, which is where most registers go wrong. Accounting asks what has to be capitalised. The IRS de minimis safe harbor election lets a taxpayer with an applicable financial statement deduct amounts paid for tangible property up to $5,000 per invoice or item as substantiated by the invoice, and up to $2,500 per invoice or item without one. The election does not cover inventory or land. So a fixed asset tracking app built strictly on the capitalisation line will be missing a lot of what actually walks out of the building.
The control line sits much lower than the accounting line. Items disappear because they are portable and easy to resell, not because they are expensive. A $180 impact driver leaves site far more often than a $9,000 compressor. That is why a useful register carries two flags rather than one: capital, for the accountant, and tracked, for whoever runs the store. It is also why a tool tracking app usually ends up as its own habit even when it shares the same table.
The app does not decide the tax treatment and should not pretend to. What it owes your accountant is the cost, the acquisition date and the invoice reference sitting on the row, so the question can be answered without anyone opening a filing cabinet. Ask them where the line sits for your business, then store the answer as a field instead of as folklore.
IRS, tangible property final regulations, de minimis safe harbor election
Try it
Does this item belong in the register
Two lines decide it and they are not the same line. Accounting draws one by cost. Control draws one by how easily the thing walks off site.
Give it its own row
Within the de minimis safe harbor amount, so it can be deducted under the election and may never reach the fixed asset register at all.
Portable and easy to resell, so it needs a custodian and a check out trail whatever the accounting says.
Custody is a log, not a column
The tempting design is a current holder column that gets overwritten at each hand-over. It answers today's question and destroys every other one. Write the hand-overs as events instead: asset ID, from whom, to whom, timestamp, site, condition note, and a signature or photo. Current holder is then the newest event for that asset, calculated rather than stored.
With the log in place the awkward questions become queries. Where was asset 1042 on 30 June. Who signed for it. What condition was noted when it came back, and by whom. How many times this pump has been to the repair shop this year. None of that is recoverable from a column that only holds the latest value, and no amount of scanning will bring it back later.
Model the empty state too. An asset sitting in the store belongs to nobody, and that is a real state rather than a blank. Transfers between sites need a leaving event and an arriving event, because the gap between them is exactly where things go missing.
When assets go out to people outside the company, with a return date and a price attached, the event grows a rate, a deposit and an overdue rule, and you are building an equipment rental app rather than a register. Decide which one you want before you design the event, because a hire has a due date and an internal issue does not.
What a phone can actually read off a tag
For printed tags the answer is encouraging. The camera module in a React Native and Expo project does barcode scanning itself: you name the symbol types you expect in a barcodeTypes list, and a callback fires with the decoded value when one is recognised. The documented list covers qr, code128, code39, code93, ean13, ean8, upc_a, upc_e, itf14, codabar, datamatrix, pdf417 and aztec. Narrow it to the one or two types you actually print, otherwise the camera will happily decode a courier label on the shelf behind.
Two documented details are worth planning around. Reading a code out of a still image rather than the live camera is limited to QR on iOS, so a workflow built on photographing tags for later decoding is a poor bet. And on Android the code should take up most of the frame, which argues for a label big enough to fill a viewfinder at arm's length. QR and Data Matrix carry error correction and stay readable when a corner is scuffed, while Code 128 is the linear symbol a warehouse scanner gun also reads. Whichever you pick, put the asset ID on the label and nothing else. A label holding a full URL is a label you have to reprint when the app changes.
On whether a generated build can scan a tag and open that asset record, here is what we saw and what we did not. Newly documents a control on its cloud simulator that feeds your computer webcam into the device camera, plus one that drops a JPEG, PNG or MP4 into the device photo gallery. That control exists because a simulator has no camera of its own, and it does mean you can hold a printed tag in front of a running build. The step after the scan is ordinary application code: the callback hands you a string, you look it up in the asset table, you push the record screen. We did not watch a shipped build decode a tag and land on the matching row end to end, so treat that specific claim as unverified until you install on a real phone and try it with your own labels.
Radio tags are a different conversation. A phone can tap an NFC sticker at a few centimetres, but no stock phone reads warehouse UHF RFID tags across a room, so a plan that assumes walk-past counting needs a reader, not an app.
Expo, Camera API reference, barcode scanning and barcodeTypes
What each approach gives you
| Approach | Own ID per item | Custody history | Scan opens the record | Fits your own fields |
|---|---|---|---|---|
| Shared spreadsheet | No | last editor only | No | Yes |
| Printed labels plus a spreadsheet | Yes | if someone writes it down | No | Yes |
| Fixed asset module in accounting | Yes | value changes only | No | No |
| Off-the-shelf asset platform | Yes | Yes | Yes | within its fields |
| An asset app you build | Yes | Yes | Yes | Yes |
Building one around the register you already keep
Asset platforms are priced per asset or per user per month and arrive with their own idea of a check-out. That holds up until the register needs a field they do not model: the cost centre that owns the item, the calibration certificate number, the second signature required before anything leaves the yard, the van that counts as a location. At that point you are either paying for an enterprise tier to unlock one field, or keeping the real register in a spreadsheet beside the platform, which is where most of these projects quietly end.
Newly is an AI app builder. You describe the register you actually keep, including the fields your auditor asks about, and it writes a real React Native and Expo project you own, running it on a cloud iPhone or Android simulator while it builds. It is $25 a month and there is no free plan. iOS ships through TestFlight and App Store Connect using your own Apple Developer account, and Android publishes to Google Play internal testing from the Deploy tab or builds a standalone APK with the JavaScript bundled. The code comes out one way with npm i -g @newly/cli and then newly pull, there is no GitHub sync, and there are no built-in payments, so any hire fee or deposit needs an outside provider.
Settle one thing before the scanning work: two people will scan the same item on the same morning, and what happens then depends entirely on where the asset register lives. A register that exists only on one phone is not a register, it is a note.
Questions people ask about asset tracking apps
It keeps a record of individual items the business owns and uses: each one has its own identifier, location, custodian, cost, status and history. Scanning a label is just the fastest way to reach that record. The register is the actual product.
Describe the asset list you already keep
Write down one real row, the fields your auditor asks for, and the hand-over that goes wrong most often. Build the register around those three things.
Start building