How Tracklet works

Physical key tracking,
finally solved.

Attach a Bluetooth tag to each key ring and install the app — your team's phones do the rest, automatically.

Consumer personal trackers are built for one person recovering a lost item. Tracklet is built for teams — shared access across every staff member's phone, verified custody trails, and real accountability from the moment a key leaves the building.

Book a demo See how it works
BLE Tag
Attached to each key ring
Staff Phones
Passively detect nearby tags
Cloud
Serverless, scales automatically
Dashboard
Real-time status, anywhere
The problem

Keys are the last blind spot
in building security

Most modern buildings have digital access control — swipe cards, PIN pads, camera systems. But physical keys still exist, and they move around with no digital trace.

No visibility

When a key leaves the cabinet, where does it go? Traditional systems can tell you who signed it out — but not where it is right now, or whether it's been returned.

Compliance without insight

Paper logbooks satisfy auditors, but they're reactive. There are no alerts when a key is overdue, no automatic audit trail, and no way to spot patterns — until something goes wrong.

Existing solutions need hardware

RFID key cabinets cost thousands to install. NFC tap stations need fixed readers at every door. Both require infrastructure that's tied to a single location and expensive to maintain.

Tracklet closes this gap by turning the smartphones your team already carries into a passive key-detection network. Small, purpose-built Bluetooth Low Energy (BLE) tags are attached to key rings. When a staff member's phone comes within range, it silently logs a sighting and reports it to the cloud. No tapping, no check-in, no behaviour change required. The result: a live map of every key's last known location, a full audit trail, and automatic alerts — all running on infrastructure your team already owns.

The sensor network

Your team's phones are
the infrastructure

Traditional asset tracking requires fixed readers mounted at every door — thousands of dollars in hardware before you've tracked a single key. Tracklet takes a different approach.

No fixed readers. No installation. Coverage grows every time a new team member joins.

Existing phones as sensors

Every enrolled staff member's phone acts as a mobile Bluetooth scanner. Staff join voluntarily — they install the Tracklet app and create an account to opt in. Only phones belonging to opted-in staff participate. No new hardware, no site survey, no installation.

Passive detection

Phones detect nearby BLE tags automatically in the background — no app interaction required from staff. A tag sighting is logged silently every time a key comes within range of a phone.

Coverage grows with your team

Add a new staff member to Tracklet and your detection coverage improves immediately. Every new participant extends the network to wherever they carry their phone — offices, car parks, corridors, lifts.

This model works in multi-floor buildings, underground car parks, and across multiple sites — wherever staff carry their phones. The system always shows the last known location for every key, with a timestamp and an age indicator so you know how recent the sighting is. If a key hasn't been detected for a while, that is surfaced clearly — there is no silent staleness.

Bluetooth tracking

How BLE passive
scanning works

Bluetooth Low Energy (BLE) tags broadcast compact, energy-efficient radio signals detected by nearby smartphones. Purpose-built commercial BLE tags are designed for continuous business operation, shared team access, and multi-site scale — a very different proposition to the consumer personal trackers that inspired widespread awareness of the technology.

Why not GPS, NFC, or RFID?

GPS
Battery drain, fails indoors, too large and expensive for a key tag
NFC
Requires a deliberate tap — removes the passive tracking benefit entirely
RFID
Fixed readers needed at every door — thousands in infrastructure before tracking a single key
BLE ✓
Uses existing smartphones as the sensor network — zero extra hardware required

Why consumer personal trackers fall short for business

Consumer personal trackers make it easy for one person to find a misplaced item. That narrow design brief creates hard limits that make them unsuitable for organisational key management:

  • Single-account access only. Consumer trackers are tied to one account. In any organisation where multiple managers, supervisors, or staff need visibility of the same keys, this is an immediate dead-end. There is no concept of shared access, roles, or team membership.
  • No audit trail or accountability. Knowing roughly where a key is tells you nothing about who had it, when they took it, or where it travelled. Consumer trackers record no custody history, no holder identity, and no compliance log. When an incident occurs, there is nothing to review.
  • Platform lock-in limits coverage. Consumer trackers built around a single mobile ecosystem only work on devices in that ecosystem. A mixed iOS and Android team gets inconsistent and incomplete coverage — leaving gaps at exactly the wrong moment.
  • Reliance on nearby consumer devices. Consumer trackers locate themselves by borrowing location signals from other nearby consumer devices. In commercial environments — car parks, multi-storey buildings, industrial sites — that relay network is unreliable. Coverage disappears wherever consumer foot traffic is low.
  • Not rated for continuous commercial use. Consumer trackers are optimised for occasional personal recovery events. Continuous detection across a working day, across a team of phones, drains their batteries far faster than their rated lifespan — and the battery is not user-replaceable on most models.

Tracklet is purpose-built to address all of these. Multi-user access across every enrolled phone, full iOS and Android coverage, a verifiable chain-of-custody audit trail, and tags rated for continuous commercial deployment over a three-year service life.

The passive scanning model

Staff phones run the Tracklet app in the background. The app is installed voluntarily — staff opt in by downloading it and creating an account. Only enrolled phones participate in detection; staff who have not installed the app are not part of the network. Once enrolled, no active participation is needed day-to-day — the app silently detects nearby BLE tags and records a sighting: the tag's internal ID, the phone's GPS coordinates, and a timestamp. The key holder doesn't tap, scan, or interact with anything.

Each key cabinet has a configurable home zone — a GPS bounding area centred on the cabinet's location. Keys detected within that zone are marked In. Keys detected outside it are marked Out. The calculation is purely distance-based — no precise GPS is required, just good enough to distinguish "at the office" from "somewhere else".

iOS background scanning

Apple supports background Bluetooth scanning through a standard, documented framework. The app scans only for registered Tracklet tag identifiers — not every Bluetooth device in range — so battery impact is minimal.

iOS may throttle background scan frequency but detection resumes reliably when a tag comes into range. The "Always Allow" location permission is required so GPS coordinates can be attached to each sighting.

Standard Apple API — not a workaround or unofficial capability.
Android background scanning

Android aggressively manages background processes to preserve battery — especially on devices from Samsung, Xiaomi, and Oppo which layer their own power managers on top. Standard background services are suspended when the screen is off. Tracklet works around this by registering scans directly with the phone's Bluetooth hardware rather than the app process.

When a tag is detected, the system wakes just long enough to record the sighting and go back to sleep. Scanning continues even when the app is completely closed, and resumes automatically after a device restart.

Scanning is registered with the Bluetooth hardware — it survives even when the phone's screen is off.
Offline resilience

Mobile devices aren't always connected — underground car parks, poor signal areas, in-flight mode. Tracklet queues sightings locally on the device (up to 50) and flushes them to the cloud when connectivity returns.

A background flush task runs on a 15-minute cycle using the OS task scheduler. Sightings include timestamps recorded at detection time, so the custody log is accurate even when upload is delayed.

No sighting data is lost due to brief connectivity gaps.

Range and accuracy — honest numbers

Typical BLE range: 5–30 metres in open space. GPS accuracy: 5–20 metres outdoors. Both vary with walls, interference, and building materials.

Tracklet is designed for zone detection, not room-level precision. The system answers "is this key at the office or somewhere else?" — not "is it in the third drawer on the left". That is the right question for key custody, and BLE with GPS handles it reliably.

Multiple sightings from different phones improve location confidence. The dashboard shows the most recent sighting with the best GPS accuracy, plus a timestamp so you always know how fresh the data is. If a key needs to be physically located, Find Mode shows recent BLE encounters from the tag holder's phone to help narrow it down.

Admin dashboard

Real-time visibility
without an IT department

The Tracklet web dashboard is a browser-based app — nothing to install, no server to manage. Admins get a live view of every key's status from any device, anywhere.

Interactive maps — last sighting location shown on an OpenStreetMap tile layer relative to the home zone. See exactly where a key was last detected, on a real map.
In/Out status at a glance — every key in the cabinet shows a clear In or Out state, updated automatically as sightings arrive from staff phones. No manual updates needed.
Overdue alerts — configurable thresholds per key. If a key hasn't been marked In within X hours, the admin receives an in-app notification and optional webhook payload.
Virtual cabinets — logical groupings that mirror your physical locations. A site can have "Server Room Cabinet", "Front Desk Cabinet", or any grouping that fits your operation.
Two QR code types — Invite QR: share a scannable link to add staff to a cabinet; they scan once and are enrolled automatically, no admin steps per user. Checkout QR: generated per-key by an admin, lets a staff member explicitly claim hard custody of a specific key — or return it — with a single scan.
Custody tracking — colour-coded chips show who currently holds each key. Soft custody (amber) is assigned automatically when a BLE sighting places a key outside its home zone. Hard custody (orange) requires an explicit QR scan and persists even if the key re-enters the home zone — only another QR scan can release it.

Custody state transitions

A key's custody state changes in response to two types of input: a passive BLE sighting from a staff phone, or an explicit QR scan by a user. The rules that govern each transition are designed to minimise false transfers while ensuring intentional check-outs are always respected.

No Custody custodyType: null Soft Custody assigned by BLE Hard Custody assigned by QR scan BLE sighting out-of-zone QR scan (checkout) BLE in-zone (auto-clears) QR scan (self-return / admin return) QR scan (checkout) BLE, new user (>5 min) QR scan (different user)
Solid lines: active transitions  ·  Dashed lines: return / clear transitions  ·  Loops: in-place holder transfers
The two custody modes
Soft custody (amber)
Assigned automatically by the BLE sighting pipeline. No user action required. Cleared automatically when the key re-enters its home zone. Can be transferred to a new holder if no sighting has been recorded for more than 5 minutes (anti-bounce window).
Hard custody (orange)
Granted only by scanning the key's QR code. Persists even if the key re-enters the home zone — a return requires an explicit QR scan (self-return) or admin force-return. BLE sightings cannot clear or transfer hard custody.

All state transitions

From Trigger To Notes
No custody BLE sighting — out of home zone Soft Immediate assignment to the reporting user
Soft (same user) BLE sighting — out of home zone Soft Refreshes custodyStartedAt, no holder change
Soft (different user) BLE sighting — out of home zone, >5 min since last seen Soft (new holder) Anti-bounce window elapsed — custody transfers silently
Soft (different user) BLE sighting — out of home zone, <5 min since last seen Soft (unchanged) Within anti-bounce window — custody held to prevent rapid flipping
Soft BLE sighting — in home zone No custody Auto-cleared; key_returned notification sent to former holder
No custody or Soft QR scan (checkout) Hard Explicit claim; user auto-joined to cabinet if not already a member
Hard (same user) QR scan No custody Self-return; sighting written with zone: in
Hard (different user) QR scan Hard (new holder) Transfer; app prompts for confirmation; custody_lost alarm sent to previous holder
Hard Admin force-return No custody POST /keys/{keyId}/return via admin web app
Any Key archived No custody Custody cleared as part of the archive operation
Any Account deleted No custody All keys held by the departing user are force-returned
Full audit trail — the complete sighting history for any key is searchable and filterable by date, staff member, or location. Every record is timestamped and linked to a verified account.
Webhook support — push key events (check-out, check-in, overdue) into existing facility management or security software. Integrate Tracklet with your operations workflow without manual data entry.
Cloud backend

Built on serverless
cloud infrastructure

Traditional hosted servers charge for capacity around the clock — even at 3am when no keys are moving. Tracklet runs entirely on serverless infrastructure that only executes when needed, and auto-scales from one site to thousands with no configuration changes.

Serverless functions

API handlers execute only when requests arrive — zero infrastructure cost at idle. Auto-scales with no capacity planning, no server patching, and no uptime monitoring required from the team.

Cloud database

A managed NoSQL database handles sighting storage with millisecond read performance — critical for real-time custody updates. Point-in-time recovery is enabled on all data, so nothing is ever permanently lost.

Login via email — no passwords

Staff log in using a one-time password (OTP) sent to their work email — no passwords to create, forget, or breach. Secure, short-lived access tokens are issued after verification and can be individually revoked if a device is lost.

Zero-infrastructure notifications

Overdue key alerts don't require a dedicated alert server. A scheduled cloud task runs every few minutes, compares Out keys against admin-configured thresholds, and fires in-app notifications and webhook payloads for any overdue keys. Email delivery is handled by a managed cloud service. The entire notification pipeline is serverless — no infrastructure to manage, no background worker to monitor.

Cost model — how this differs from enterprise tracking vendors

Capability Tracklet Manual logbook NFC tap station RFID fixed readers
Setup cost Tags only (<$100/key) Near zero $200–$500/reader $10,000–$100,000+
Ongoing cost Tag replacement every 3 yrs Admin time Software subscription Maintenance contracts
Passive detection
Real-time alerts
Audit trail
Zero installation cost
Scales with facility size
Security & privacy

Secure by design

Tracklet's security model is built into the architecture, not bolted on. Every API call, data record, and authentication flow is designed with a specific threat model in mind.

No passwords means no password breaches. OTP-only authentication eliminates the entire credential theft attack surface.
Encrypted in transit
All API traffic is encrypted over HTTPS (TLS 1.2+), enforced at the API layer. No plaintext connections permitted.
Cryptographically signed tokens
Access tokens are cryptographically signed using a key stored in a secure secrets vault — never in code or configuration files. Each token is short-lived and scope-limited.
OTP expires in 10 minutes
One-time passwords are single-use and expire after 10 minutes. Expiry is enforced at the database level — not just application logic.
Session revocation
Every active session is tracked in a session table. Any session — or all sessions — can be individually revoked by an admin, for example if a staff phone is lost.
Organisation-scoped data
Location data is only accessible within the organisation that manages the cabinet. Isolation is enforced at every API handler — not just the UI.
No passwords stored
OTP-only authentication means there are no passwords to hash, store, breach, or reset. The credential theft attack surface simply does not exist.
CORS per environment
Cross-origin resource sharing is configured per deployment environment, not wildcarded. Only the authorised web app origin can call the API.
Input validation throughout
All API handlers validate inputs at the boundary: coordinates range-checked, strings sanitised, all IDs validated before any database access.
Honest disclosure

What Tracklet can't do
(and what we do about it)

Every system has limits. Being upfront about them builds more trust than glossing over them. Here is what to expect.

Known limitations
BLE is proximity, not precision
We detect that a key is near a phone, not its centimetre-level location. The system is designed for zone detection ("at the office" vs "somewhere else") — not room-level tracking.
GPS is degraded indoors
Sighting coordinates in multi-floor buildings may not perfectly reflect floor level. GPS accuracy is typically 5–20m outdoors and less reliable through reinforced concrete.
Coverage depends on staff participation
A site where no staff member runs the app will have no sightings. Coverage improves as adoption grows — the first few enrolled staff provide baseline coverage, and each additional member extends it.
Android battery management varies by device
On some Samsung, Xiaomi, or Oppo devices, users must manually whitelist Tracklet in battery settings for the most reliable background scanning. The app surfaces this as a setup prompt with device-specific instructions.
Not a real-time location system
There may be a delay between a key moving and a sighting being reported, depending on when a staff phone was last nearby. For key custody — where keys are held for minutes or hours — this is a practical non-issue.
Physical tag attachment
Tags must be securely attached to key rings. The system tracks the tag — if a tag is separated from its key, that separation is not detectable by software alone.
iOS suppresses repeated sightings of stationary tags
When the iOS app is backgrounded, CoreBluetooth silently overrides allowDuplicates: true — in theory each tag is reported only once per scan session. A tag sitting still near a phone may only generate a single sighting, not continuous updates. The tag may need to move out of range and back before iOS delivers a second packet. Tracklet's sighting throttle accounts for this; the practical effect is that location freshness may be bounded by movement, not polling rate. Note in practice we rarely encounter this limitation.
Android scan rate limiting can silently degrade detection
Android enforces a limit of 5 scan start/stop cycles within any 30-second window. If this is exceeded, subsequent scans are silently downgraded to opportunistic mode — which only delivers results when another app happens to be actively scanning. There is no error callback; scanning appears to succeed but becomes unreliable. Tracklet avoids this entirely by running a persistent foreground service that starts scanning once and never restarts, but third-party BLE libraries that restart scans frequently will hit this limit.
iOS cannot expose hardware MAC addresses
iOS assigns a random, per-session CBPeripheral UUID to every BLE device — the hardware MAC address is deliberately withheld as a privacy measure. Tracklet resolves this via a one-time GATT connection to read the MAC from the tag's Device Information Service. Until that first connection completes, a newly encountered tag cannot be matched to its registered ID. Once cached, the mapping is permanent.
For technical readers

Under the hood

For engineers, investors, and IT evaluators who want to understand the deeper implementation details and architecture decisions behind Tracklet.

What makes this technically difficult — and why that matters
  1. Android background BLE diversity — Android OEMs (Samsung, Xiaomi, Oppo, Huawei) each ship custom battery managers that aggressively kill background processes. Solving this correctly requires deep knowledge of Android internals and per-device testing. Many developers ship apps that silently stop scanning the moment the screen turns off, with no error or warning to the user.
  2. iOS background execution limits — Apple's background Bluetooth scanning requires correct app entitlements and real-device testing across multiple iOS versions. A common mistake is shipping an app that scans correctly in the foreground but silently stops in the background — without any error or warning to the user.
  3. Multi-device sensor coordination — when multiple phones detect the same tag simultaneously, the system must deduplicate sightings, resolve location conflicts, and produce a coherent custody state. The sighting queue with server-side deduplication handles this without requiring real-time coordination between devices.
  4. Zone model design — delivering meaningful In/Out status from imprecise GPS data is a deliberate design challenge. The zone model produces reliable custody signals without centimetre-level accuracy, using distance calculations that work well even with typical GPS variance.
  5. Full-stack ownership — the native BLE module, mobile app, web dashboard, serverless backend, and cloud infrastructure (IaC) are all built and maintained by the same team. No dependency on third-party tracking SDKs that could change pricing or deprecate APIs. Every layer integrates tightly because the same engineers built all of them.
iOS & Android BLE scanning — platform constraints in detail

Both platforms impose constraints on background BLE scanning that are either underdocumented or documented only in release notes buried in developer forums. Understanding them is what separates a reliable passive scanning system from one that silently stops working the moment the phone screen turns off.

iOS — CoreBluetooth / CBCentralManager

  1. Service UUID filter is mandatory for background delivery — a null (unfiltered) scan stops delivering results the instant the app is backgrounded, with no error or warning. Tracklet filters on UUID 0x656B, which is the UUID Minew MTB09 tags include in their primary advertisement packet (not the scan response, which iOS never retrieves when backgrounded).
  2. Background deduplication is forced regardless of flags — allowDuplicates: true is silently overridden when the app is in the background. Each CBPeripheral UUID is reported at most once per scan session. A tag sitting stationary next to a phone will not generate repeated advertisement packets until it goes out of range and returns. This is an OS-level constraint with no workaround.
  3. No hardware MAC address ever exposed — iOS deliberately withholds BLE device MAC addresses as a privacy measure. Instead, each device receives a random per-session CBPeripheral UUID. Tracklet resolves the real hardware ID via a one-time GATT connect → Device Information Service (0x180A) → Serial Number characteristic (0x2A25) read. The CBPeripheral UUID → MAC mapping is cached permanently in AsyncStorage so the connection only happens once per tag per device.
  4. Active vs passive scanning — scan response packet visibility — iOS performs active scanning (sends scan requests to retrieve scan responses) only when a non-null service UUID filter is active. The Minew MTB09 broadcasts its 0xAAE0 UUID and hardware MAC only in the scan response packet, which is invisible with passive scanning. The 0x656B UUID appears in the primary advertisement and is therefore visible with active scanning. Getting this wrong means tags are completely invisible in background.
  5. State restoration after app termination — if iOS terminates the app under memory pressure while it holds a bluetooth-central background task, the OS relaunches it headlessly and provides a willRestoreState callback with the saved CBCentralManager state. Without implementing this correctly, background scanning permanently stops after the first app termination. The restoreStateIdentifier must be set at manager construction time — it cannot be added later.
  6. Simultaneous tag capacity — iOS imposes no documented per-app hard limit on how many peripheral UUIDs can be detected simultaneously through a single service UUID filter. A single CBCentralManager instance handles all matched peripherals. Practical testing confirms reliable detection across 20–100 concurrently broadcasting tags. There is also no documented limit on the number of service UUIDs in the scan filter list, though very large lists may be coalesced or partially ignored.

Android — BluetoothLeScanner

  1. 5 scan starts per 30-second window — silent downgrade — Android's Bluetooth stack enforces a hard rate limit: calling startScan() more than 5 times within any 30-second window causes subsequent calls to be silently downgraded to SCAN_MODE_OPPORTUNISTIC. In opportunistic mode, the scanner only delivers results when another app on the same device happens to be actively scanning — making detection completely unreliable. There is no error callback; the call appears to succeed. Tracklet avoids this by starting the foreground service scan exactly once and keeping it running.
  2. Hardware filter slots (chipset offload) — the BLE chipset can apply advertisement filters in hardware using very little power. The number of simultaneous hardware-offloaded slots varies by chipset manufacturer: typically 16–128 slots across all apps on the device. Exceeding this causes the OS to fall back to software filtering, which wakes the CPU for every BLE advertisement packet in range — significantly increasing battery drain at scale. Tracklet occupies exactly one hardware slot (a single service UUID filter), leaving the rest available regardless of how many tags are registered.
  3. Scan mode duty cycle in background — Android applies scan modes that trade latency for battery: SCAN_MODE_LOW_POWER (~500ms active window every 5 seconds, ~10% duty cycle) is the default for background foreground services. SCAN_MODE_BALANCED (~25%) and SCAN_MODE_LOW_LATENCY (continuous, ~100%) are available but the highest mode is restricted to foreground use and drains battery proportionally. A tag passing through range during the inactive 4.5-second window of low-power mode will not be detected on that pass.
  4. Foreground service requirement (API 26+) — standard background services on Android 8+ are automatically stopped when the app leaves the foreground. Continuous BLE scanning requires a foreground service with a persistent visible notification. Even foreground services can be killed by OEM battery managers (Samsung One UI, Xiaomi MIUI, Oppo ColorOS, Huawei EMUI) — users on these devices must manually whitelist the app in device-specific battery optimisation settings to guarantee reliability.
  5. Simultaneous tag capacity — Android applies one service UUID filter that matches all advertisements containing that UUID, regardless of how many physical tags are broadcasting. There is no per-registered-tag limit at the scanner level. All matching tags are delivered through the same callback. The practical ceiling is the hardware filter slot count — but since Tracklet uses a single UUID filter, the slot count is always 1 regardless of how many tags the organisation has registered.
  6. Permission requirements by API level — ACCESS_FINE_LOCATION is required on all versions up to API 30. API 31+ (Android 12) adds BLUETOOTH_SCAN and BLUETOOTH_CONNECT runtime permissions — their absence causes a silent scan failure with no indication to the user. API 33+ (Android 13) adds POST_NOTIFICATIONS for the foreground service notification; denial is non-fatal (scanning continues) but the persistent notification disappears.
Build & deployment pipeline
Source code
→
Automated build
→
Cloud + App Stores
→
Live globally

Mobile app — built with React Native and a managed build service that produces production-ready files for Google Play and the App Store. Separate build profiles exist for development, internal testing, and production. Over-the-air updates are possible for non-native changes without a full app store submission cycle.

Admin web app — a React single-page application delivered via a global content delivery network with SSL at the edge. Sub-100ms load times are typical worldwide.

Infrastructure as code — all cloud resources are defined in version-controlled TypeScript. Deploying a new environment is a single command — no manual console configuration, no drift between environments.

Ready to get started?

See Tracklet in action

No hardware to install. No server to manage. Attach tags to your keys, onboard your team, and you're tracking key custody in under an hour.

Book a demo Back to home