Most advice about wireless protocols answers one question: which one should I pick for this application? That’s a useful question, and we’ve answered it elsewhere; RFID, BLE and NFC read the asset in very different ways, and which fits depends on your deployment. (If that’s where you are, start with the comparison post and the per-technology pages for UHF RFID, Bluetooth and NFC.)
But if you own a product rather than a single deployment, a bigger and earlier question lands on your desk: should the product commit to one protocol, or plan for several across the markets you might serve — and what does it actually cost to add one later? That’s a roadmap decision, and getting it wrong is expensive in a way the picking question isn’t. Commit too narrowly and a new market means an unplanned rebuild; hedge too broadly and you triple your cost for optionality you never use. This post is a framework for making that call.
The question that comes before “which protocol”
“Which protocol?” quietly assumes a single deployment. But products often have to serve markets that read the same asset in incompatible ways: a warehouse with fixed readers wants UHF RFID; a field crew with phones wants an NFC tap; a facility already running BLE gateways wants BLE. The real question isn’t which of those to choose, it’s whether to bet everything on one, or design so that serving a second doesn’t mean starting over.
Two opposite fears pull product teams off course here. One is the fear of being trapped: if I commit to RFID and a big customer needs NFC, have I painted myself into a corner? The other is the fear of scope: if I try to support all three up front, I’ll triple the budget and ship nothing. Both fears are reasonable. The way out is to understand what “adding a protocol later” actually costs.
What adding a protocol later actually costs
Here’s the fact that makes the whole decision tractable: the expensive part of a battery-free sensor (the sensing core, the energy harvesting, the measurement physics) is protocol-agnostic. It doesn’t change when the radio changes. That’s the shared-core story, covered in our RFID vs BLE vs NFC comparison; the short version is that the sensing is the same and only the radio differs.
So adding a protocol later is not a from-scratch rebuild. But it isn’t free, and anyone who tells you it’s a config flag is overselling. You re-engineer the radio and RF front-end, and you redo the integration, because the protocols live in different worlds: different energy budgets, different data models (EPC Gen2 vs BLE GATT vs NFC NDEF), different reader ecosystems. The cost of “add later” sits squarely between trivial and new product.
The practical consequence is the whole game: the hard, expensive core you pay for once, if you keep it protocol-agnostic from the start. That single early design choice is what turns “add a protocol later” from a catastrophe into a manageable increment.
Three roadmap strategies, and when each is right
Commit to one protocol. When one deployment model covers your market (or you can standardise how the asset is read) pick the protocol that fits and build for it. It’s the cheapest, simplest path, and it’s the right default. Don’t buy optionality you have no concrete plan to use.
Ship one, keep the core reusable. When a second market is plausible but not here yet, ship the protocol your first market needs, but keep the sensing core protocol-agnostic underneath, so a second radio is an addition rather than a redesign. This costs a small premium now and buys you a cheap exit from lock-in later. Under genuine uncertainty, this is usually the right call.
Plan a multi-protocol line from day one. When you already have two or more funded markets with genuinely different read models, design the line for all of them: reuse the core, and budget the radio and integration for each protocol up front. It’s the most expensive path now, and it’s only worth it when the markets are real, not hypothetical roadmap slides.
The trap: three products wearing a trench coat
The failure mode to avoid is treating “we might need three protocols someday” as a licence to build three products in parallel. That triples cost and timeline for optionality you may never exercise. Optionality is cheap when it lives in a shared core and expensive when it lives in three separate builds. So if you find yourself scoping three parallel developments to hedge a maybe, stop and put the flexibility in the core instead.
The one design choice that keeps your options open
If you take one thing from this: keep the sensing core protocol-agnostic from the first design, even if you ship a single protocol. It costs little up front, and it’s the difference between “we’re locked into RFID” and “we add BLE the quarter the market appears”. That clean separation between core and radio isn’t automatic: it depends on controlling the RF and firmware yourself rather than inheriting a bundled module, which is exactly the capability that makes it possible.
Weighing this for a product you’re planning? A scoping study can map which parts of your sensing core stay protocol-agnostic, and what each future radio would actually cost to add, so the roadmap decision is made on real numbers instead of on the fear of being trapped. Scope your product roadmap → And if you just want to see the sensor work first, the eval kits and SDK are the fastest way in: explore the kits.
Next week: designing the sensor in at the manufacturing stage — RF guidelines for OEMs embedding battery-free sensing.