Engineering KeeLess: From Prototype to Industrial Access Control Platform

The question that started it

Every hardware product starts as an experiment, and KeeLess started with a simple one: can a smartphone replace a physical access card while giving people a better experience and stronger security at the same time? Answering that took years of prototyping, testing, redesigning, and re-engineering. What began as a pile of development boards and sensors on a desk became a fully integrated access control ecosystem with custom hardware, a proprietary communication protocol, industrial-grade electronics, and intelligent mobile credentials.

This is the hardware side of that story.

The problem with the existing options

Most access control hardware on the market still relies on RFID cards and tags, legacy communication standards, proprietary boards with little room to extend, expensive infrastructure upgrades, and poor integration with the smartphones everyone already carries. Smartphones had become central to everyday life, but access control hadn't caught up. The goal was straightforward to state and hard to execute: build an access control platform designed for a mobile-first world, not one bolted onto an old one.

Phase 1: early experimentation

The first KeeLess prototypes were intentionally rough. Rather than investing in custom hardware before we'd proven anything, the early builds ran on ESP-based microcontrollers, Bluetooth Low Energy communication, relay modules, basic power supplies, and rough mobile app prototypes. None of it was meant to look good or ship. It was there to answer questions: how reliably can you detect a phone, how consistent is BLE in practice, which authentication approaches actually hold up, how fast is the access response, how much does interference from the environment matter, and how do people actually behave around doors and gates when a system like this is in the loop.

Phase 2: solving the proximity problem

One of the harder problems was figuring out when a user was genuinely approaching an access point, rather than just somewhere nearby with Bluetooth on. Signal strength alone wasn't consistent enough in real-world conditions; walls, bodies, and other phones in the area all distort it. We evaluated Time-of-Flight sensors, more careful RSSI analysis, device motion patterns, and a few other environmental detection techniques to narrow this down. Time-of-Flight sensors turned out to be the most useful addition, since they let the system reason about physical distance from the entry point rather than just "a device is somewhere around here." That shifted the system from detecting a device to understanding intent and proximity, which is most of what makes a tap-to-unlock experience feel instant instead of laggy.

Phase 3: building a complete ecosystem

Once the core detection problem was solved, it became clear that access control isn't really about opening a door, it's about reader hardware, controller hardware, mobile apps, management software, credential management, and secure communication all working together. Development expanded from hardware prototypes into a full architecture: centralised management platforms, remote provisioning, event logging, real-time monitoring, and multi-site support. At this point the project had stopped being a prototype and started being a platform.

Phase 4: designing custom hardware

As deployments grew and requirements got more specific, development boards and off-the-shelf electronics became the limiting factor rather than the accelerant they'd been early on. We made the call to design custom hardware from the ground up, which was the biggest single decision in the project's history. Custom hardware meant we could optimise performance for our actual use case, reduce installation complexity for the people fitting these units, improve reliability, lower long-term costs, increase security, and add features specific to access control rather than working around a generic board's limitations.

The KeeLess Controller

The KeeLess Controller became the heart of the platform: the intelligence layer between readers, locks, management software, and mobile devices. We designed it for industrial reliability, long-term maintainability, secure communication, scalability, and room to expand, rather than just getting a working board out the door.

Integrating power conversion onto the board

One lesson from early deployments was that installers wanted simpler installs with fewer external boxes to mount and wire. So we started integrating power conversion directly onto the hardware itself: onboard voltage regulation, power conversion circuitry, protection circuitry, and peripheral power outputs, all on the custom PCB. That eliminated the need for separate external converters and meant fewer points of failure. Practically, it meant faster deployments, fewer support calls about wiring, cleaner installs, and lower maintenance overhead. What used to be several separate modules wired together became one engineered board.

KeeLink: a proprietary communication protocol

As the ecosystem grew, standard communication methods started to show their limits, so we built KeeLink: a proprietary communication architecture optimised specifically for KeeLess devices. The goals were faster authentication, lower latency, stronger security, reliable device synchronisation, and enough headroom to keep scaling without a redesign. KeeLink became the connective layer between readers, controllers, mobile apps, cloud services, and KeeChain, our digital identity infrastructure, which is what makes the whole ecosystem behave like one product instead of a set of components that happen to ship together.

From prototype boards to industrial product

The clearest way to see the progression is to look at the three stages side by side.

• Early stage: development boards, breadboard circuits, experimental firmware, temporary enclosures.
• Intermediate stage: prototype PCBs, custom firmware, field testing, pilot installations.
• Production stage: industrial PCB assemblies, integrated power systems, custom enclosures, deployment-ready hardware, and management tooling that could handle real scale.

Every iteration at every stage fed directly back into the next one. Nothing here was designed in a vacuum and then handed off; the field issues from pilot installs are what drove the production-stage redesigns.

The engineering philosophy behind all of it

One principle stayed constant through every phase: build only what solves a real problem. Every hardware revision, firmware update, and architectural call was driven by an actual deployment requirement, not by what would look impressive in a deck. That's also why the early prototypes were allowed to look as rough as they did. None of the engineering time went into polish until the underlying decisions had been proven out in the field.

Where this leaves KeeLess today

KeeLess is now a complete technology ecosystem: custom reader hardware, custom controller hardware, the KeeLink protocol, mobile applications, management software, digital credential systems, and the KeeChain digital identity layer. More than any single piece, it represents a few years of engineering iteration that didn't stop once the first version shipped. If you want the software and protocol side of the story in more detail, see our first KeeLess case study.