Building an NFC asset tracking system for construction sites — and learning that the version nobody asked for was the one everyone used.
Designed and deployed an NFC-based equipment tracking system across 30+ construction sites. 65–70% reuse rate on tracked assets, up from effectively zero. $240K+ recovered in the first eight months. 50x ROI. The first version of the system barely got used. The second version worked because I removed most of what I built in the first one.
At the end of a construction project, equipment moves. Some goes back to a warehouse. Some goes to the next job. A lot of it disappears — thrown in a dumpster, left on-site, or "borrowed" in ways that never get documented. New projects then purchase the same equipment that adjacent sites already own. Same company, different project, same purchase order.
It happened constantly, and it wasn't because anyone was careless — there was simply no cheap, fast way to know what you had or where it was. Projects were spending $20K–$50K each on fire protection equipment alone, then discarding it at job completion. Across 30+ active sites, the company had zero visibility into thousands of pieces of safety equipment worth hundreds of thousands of dollars.
The obvious safety manager solution was a spreadsheet. Log every piece of equipment, track locations, coordinate transfers manually. We had one brainstorming session about it before everyone recognized it would never work — thousands of items across 30+ sites, manual entry going stale within days, nobody willing to maintain it consistently.
So I found a better tool. SafetyCulture, a platform we already used for inspections, had a newly released asset tracking module with NFC tag support. I designed a comprehensive system: custom serialized NFC tags with regional identifiers, detailed condition tracking, utilization reporting, checkout workflows — the works.
I personally tagged over 200 items on my own project before showing it to anyone else. In theory, it was thorough. In practice, adoption was minimal. When I watched people try to use it, the reason was obvious: too many fields, too many steps, too much overhead for someone closing out a job under deadline pressure. The system was built around the data I wanted to capture, not around how people actually worked.
I stripped the system down to one question: do we know where this thing is, and can we get it to the next place it needs to be?
The condition tracking, the utilization reports, the checkout workflow — gone from the required flow. What remained was a single NFC scan at equipment check-in and a single scan at project closeout to log its destination. Two taps per item per project. Ten seconds total.
The reporting still happened. Utilization data still accumulated. But it accumulated passively, as a byproduct of a workflow supervisors would actually do — not as the reason for the workflow. I paired this with bulk CSV upload capability I'd helped SafetyCulture beta-test over six months, bulletproof process documentation, and pre-built templates so any safety manager could tag 100 items in about 20 minutes.
For the rollout, I picked strategic pilots: tech-savvy safety managers on projects whose teams complained loudest about equipment costs. Early wins generated momentum. I never had to mandate usage — project teams started requesting access because they saw the value from their peers.
About three months in, field supervisors started requesting features. Not through formal channels — through texts and side conversations. "Can you add a photo so we can flag damage?" "Can I see what's available at the warehouse before I submit a purchase order?" "Can we get RFID so transfers are automatic?"
That kind of feedback — unsolicited, specific, useful — is different from compliance feedback. Compliance feedback says "this is hard to use." Product feedback says "this works, and now I want more from it." When I got the second kind, I knew the adoption problem was solved.
I built the photo feature and the inventory lookup via Power BI dashboards. I deferred RFID because the platform and cost didn't support it yet — and explaining that trade-off to a field supervisor who was already engaged enough to ask was a genuinely different conversation than explaining why the system existed in the first place.
The feature that kills adoption is usually the one you're most proud of. The detailed condition tracking and utilization reporting felt like the valuable part of the system. They were the part that got cut, and the system got better when they were gone — not because the data wasn't useful, but because requiring it upfront made the whole thing too costly to use.
There's a general principle here that I've seen hold in every technology system I've built for construction: the field will not change its workflow to accommodate your software. Your software has to accommodate the workflow. That's not a compromise — that's the design requirement.
The sequence that actually works: understand the workflow first, find the two or three moments where a lightweight interaction fits naturally, and build only that. Everything else can be additive once you have trust.
If users comply when someone's watching but revert to their own methods otherwise — I'd be interested to hear what you're seeing. It's a solvable problem, but the solution is almost never more features. I do consulting work in this space on a selective basis.