Should Lock Manufacturers Build Their Own Smart Lock Technology or Buy a Platform?
- 6 minutes ago
- 10 min read
Every lock maker and software company eventually faces the “Build vs. Buy” decision. After a decade on the "build" side, KoreLock exists so our partners don’t have to repeat that journey. Here’s what we’ve learned.
Build vs. Buy: The short answer
If one specific layer of the smart lock technology stack is the thing your company intends to win on, build that layer. For everything else, the honest math of "Build vs. Buy” favors a platform like KoreLock. And for almost every lock manufacturer and most software companies, "everything else" means the whole technology stack. The reason isn't the prototype. It's the cost, time to market, and everything that comes after the prototype.
Let’s build? The demo that fools everyone
Here's how the "let's build it ourselves" journey usually starts. A good firmware engineer gets a lock unlocking from a phone over Bluetooth in a couple of months. An app agency delivers a nice-looking mobile app a few months later. Leadership watches the demo. Tap the phone, the bolt turns, and everyone applauds. The conclusion writes itself: this is a six-month project with a budget and an end date.
That demo is maybe 10% of the work. It's also the fun 10%, which is exactly why it's so misleading. The other 90% is the long, unglamorous distance between "works on the bench" and "works on the ten-thousandth unit, on a real door, three years from now, after four phone OS updates." KoreLock knows because we've walked every mile of it, and we have the scar tissue to prove it.
Why not to build: A tour of the 90%
Bluetooth in the wild is nothing like Bluetooth on the bench. Your Smart Lock prototype was tested on three phones. Your customers carry hundreds of Android models across a dozen OS versions, each with its own BLE quirks and permission rules. Every fall, a new OS release breaks something that worked in the spring. KoreLock has chased bugs where a lock's perfectly valid response, arriving a beat slower on one hardware variant, got misread as "feature not supported." You don't find that bug until you have thousands of phones and multiple lock models in the field. Which means you will find it after launch. Ask us how we know.
Firmware updates are a product, not a feature. Ship a connected Smart Lock without over-the-air updates, and every bug lives in the field forever, or comes back on a truck. Real OTA means device groups, staged rollouts, safe recovery when a battery dies mid-update, and coordination across multiple processors in the same lock. And every update must be signed and verified by the bootloader before it installs, with automatic rollback if anything fails mid-flight, because an update pipeline without cryptographic verification is just a remote code execution service with a logo. Building that pipeline is a project on the scale of building the lock itself, and it needs to exist before your first security patch, not after.
Your fleet dashboard will lie to you. Once locks are deployed, someone has to know which ones are healthy. Sounds simple, until your dashboard can't tell a lock that lost connectivity from a lock whose owner turned Wi-Fi off on purpose to save battery. KoreLock teaches your monitoring to understand what a device intends, not just what it reports, providing the kind of refinement that only comes from operating a real fleet. Skip it, and your support team drowns in false alarms.
Credentials are a moving target with a bouncer at the door. Five years ago, a keypad and a card reader covered the market. Now buyers expect mobile keys, and increasingly they expect the lock to live in Apple and Google Wallet. Here's the catch: wallet access isn't an engineering task you can schedule. It's an admission process, with certifications, security reviews, and hardware requirements set by companies that don't return calls from 30,000-unit product lines. The industry is also mid-transition with the new Aliro standard, so whatever you build today needs a path to what's coming. Betting a niche product on entering those ecosystems solo is how roadmaps die.
The app store treadmill never stops. Google and Apple mandate new OS targets on their schedule, not yours. Frameworks age; libraries deprecate. This is a permanent engineering headcount that adds zero visible features. It just keeps the product alive. A one-time development budget can't pay for it, because it isn't one-time.
And everything above has to run on batteries for a year. Radio power management determines when Wi-Fi wakes, how BLE advertises, what sleeps, and when. It's the difference between a product and a returns problem. KoreLock holds multiple patents on Wi-Fi radio power control because this problem was hard enough to be worth patenting the solution. It is not something you download.
Why to buy: What "the platform" actually is
Most ”Build vs. Buy” conversations picture two or three pieces: some firmware, an app, a cloud. Here's the actual ten-part Smart Lock platform inventory:
Embedded lock hardware. Lock controller PCBAs designed for battery life, multiple radios, and a decade on a door.
Reader hardware. The front-of-lock boards that credentials touch: NFC and card readers, keypads, QR code scanners, and Bluetooth. Antenna design inside a metal lock body is its own dark art, and this board lives on the unsecured side of the door, which makes its security architecture matter as much as its feature list.
Lock firmware. Credentials, schedules, lock settings, motor logic, sensors, keypads, and power management are maintained across a growing family of lock models.
Cloud infrastructure. This title hides more work than any other on the list. It starts with each lock's digital twin: the always-current cloud copy of device state, settings, and credentials that everything else depends on. The platform must guarantee data point delivery, every event and setting change arriving in order across unreliable connections. Around that core sits a full production operation: the web stack (ours runs Rails and React Native on AWS, with Docker on ECS, Postgres, and Redis), REST APIs partners depend on, background job processing for the work nobody sees, automated database backups with tested failover, and redundant servers and job processors behind load balancing, because instances die and locks are security devices. None of this is a setup task you finish. It's an operations discipline you staff forever, for a system where the worst-case failure is someone standing at a door that won't open.
The credential ecosystem. PINs, cards, and fobs are the easy part. Proprietary Bluetooth mobile keys need a secure lifecycle across issuance, transfer, and revocation, working offline. Wallet credentials are a different animal entirely: Apple Wallet, Google Wallet, and the emerging Aliro standard are gated ecosystems with multi-year admission processes. We'll tell you a secret: we didn't go through those doors alone either. We integrate specialist mobile credential providers into our stack, because entering those ecosystems directly is exactly the kind of expensive, slow, off-mission project we advise our own partners to avoid. (We’re practicing what we preach!)
Device and cloud security. "We encrypt everything" is table stakes to say and years of work to actually do. On the device it means secure boot, where the bootloader cryptographically verifies every firmware image (ECDSA-signed) before it runs, rollback protection so an attacker can't downgrade a lock to old, vulnerable firmware, and hardware-backed key storage: our platform hardware includes a Common Criteria EAL 6+ certified secure element, the same class of tamper-resistant chip used in payment cards, where device keys live in non-exportable slots and cryptographic operations happen without keys ever touching main memory. In transit, it means TLS with mutual authentication, so every lock carries its own unique X.509 certificate and the cloud and the device verify each other, plus encrypted BLE payloads between lock and phone. In the cloud, it means OAuth 2.0 API access control, encrypted database fields, secrets management, and SOC 2-compliant AWS infrastructure. And wrapped around all of it: a security-response process for the life of the fleet, because shipping the protection is the start of the job, not the end.
OTA management. Not a feature you ship, an operation you run. Every update is signed with a release key and verified by the bootloader before it installs. Upgrades with automatic rollback, so a failure mid-update leaves a working lock, not a brick on someone's door. Rollback protection, so old firmware with known vulnerabilities can't be reinstalled. Then the fleet side: device groups, staged rollouts, and the judgment of when to push to ten locks versus ten thousand. All of it is maintained forever, because the day you need this machinery most is the day a security patch can't wait.
Partner APIs. The documented, versioned, supported surface that lets property management and access software build on your locks.
White-label web and mobile apps. Under your brand, kept alive through the perpetual OS treadmill.
Factory and QA systems. Flash stations that get firmware, keys, and identity onto boards at line speed, run by factory technicians, not engineers. Plus, automated firmware test suites and physical test jigs that exercise every outgoing board's keypad, radios, and peripherals before it ships.
Now look at where those layers live. Maybe a third of this is "software" the way a software company means it. The rest is embedded engineering, RF design, cloud operations, ecosystem relationships, and manufacturing infrastructure. That's why this stack challenges both kinds of builders from opposite directions: lock manufacturers underestimate the software, and software companies underestimate everything else. We know both sides personally. Our partners include lock makers, but also access-software companies who are excellent at their own layer and have zero desire to staff embedded firmware, babysit device fleets, or build test jigs. They're not wrong. They're specializing.
The punchline: "build it ourselves" isn't a project. It's a second company, permanently staffed for firmware, cloud ops, app releases, security response, and factory tooling, living inside your actual company. The question is whether you want to run that company.
Build vs. Buy: The math the big guys can't do.
Here's the part of the platform story that gets talked about least, and it's our favorite part.
A major lock brand needs a forecast approaching a million units before a new connected product gets greenlit. That's not because they're timid. It's because their fixed costs demand it. When you have to amortize a full in-house development effort across a single SKU, small markets don't clear the bar, no matter how real the demand is. The spreadsheet kills the product before engineering ever sees it.
But consumer expectations don't check the spreadsheet. People who manage their front door or thermostat from their phone now expect the same from the cabinet lock, the gate latch, the storage container, the gun safe, and the RV door. The expectation of connectivity has extended past HVAC and the front door. The market just hasn't been able to serve it, because at 10,000 or 25,000 units a year, nobody could afford the technology stack.
That's exactly the business we built KoreLock for. Because the platform already exists and is paid for across many products (all ten layers, from reader boards to test jigs), a 10-50k unit niche product isn't a spreadsheet casualty. It's a good business. We can take a new form factor from concept to production-ready without rebuilding anything but what's genuinely new about it. And that niche product inherits capabilities it could never earn on its own volume; wallet-grade mobile credentials included. The long tail of the lock market is enormous; it's underserved, and it's finally addressable.
When you should build anyway.
Fair is fair: sometimes "Build vs. Buy" is right. But the test isn't "are we a software company?" Plenty of software companies wisely build on a platform for everything below their layer. The real test goes layer by layer: is this specific layer the thing you intend to win on? A company whose actual product is device-fleet infrastructure might rightly build the cloud layers, because that's their product. The whole stack, from reader boards to test jigs to white-label apps, is only worth owning if operating all of it is your business plan. That describes platform companies and almost nobody else. And as we admitted above, even we partner for the credential ecosystem layer. Nobody should own all of it out of pride.
When you should buy and what to look for in a Smart Lock platform partner.
If the platform path is right for you, evaluate partners on the things this article is actually about, because they'll determine your next five years. Locks in production at scale, not demos. A real OTA operation with staged rollouts. Fully white-label apps and OEM products where the end user is your customer. A complete credential stack (mobile keys, PIN, and card) with a real path to wallet credentials and Aliro. Reader hardware capability, not just the lock side. Factory and test infrastructure, because your contract manufacturer will need it. Certification experience for the marks your channel requires.
And the one question everyone forgets to ask about: the willingness and speed to build features specific to your product, because your roadmap shouldn't wait in line behind a hundred other manufacturers.
+ + + +
Frequently asked questions
How long does it take to build a Smart Lock platform from scratch?
Plan on 2 to 4 years to reach production-stable, not the 6 to 9 months the prototype demo suggests. A working Bluetooth prototype takes a few months. The rest of the stack (OTA infrastructure, cloud digital twin with guaranteed datapoint delivery, white-label apps, factory flash tools, and QA test systems) is where the years go. And some layers, like Apple and Google Wallet credentials, aren't buildable on any schedule without ecosystem admission. Building on an existing turnkey platform typically cuts time to market from years to months, and you inherit production stability instead of earning it one field bug at a time.
How long does it take to build a Smart Lock with the KoreLock technology platform?
Typically, about 6 months from project start to production-ready. If that number sounds like the same six-month fantasy this article just warned you about, here's the difference: the 90% is already done. The OTA pipeline, cloud digital twin, credential stack, white-label apps, and factory test systems already exist and are already proven in the field. Your 6 months go into what's genuinely new about your product, such as your hardware integration, your branding, and your specific feature needs, instead of rebuilding infrastructure. Timelines vary with custom hardware scope, but production-ready in months instead of years is the entire point of the platform.
When should a lock manufacturer build instead of buying a platform?
Build a layer only if that specific layer is what your company intends to win on. The practical test: would you still build it if a production-proven version were available tomorrow? If yes, that layer is your business, so own it. If not, partner for it. For nearly every lock manufacturer, the differentiators are mechanical design, manufacturing quality, brand, and channel, and none of those get stronger by running a firmware and cloud operation on the side.
How is the KoreLock Smart Lock technology platform secured?
Defense in depth across the device, the connection, and the cloud. Locks use secure boot with cryptographically signed firmware, signed and verified OTA updates with rollback protection, and hardware-backed key storage in a Common Criteria EAL 6+ certified secure element, so device keys are non-exportable even with physical access. Communications use TLS with mutual authentication and per-device X.509 certificates to the cloud, and encrypted BLE between lock and phone. Cloud infrastructure runs on SOC 2-compliant AWS with OAuth 2.0 API access control, encrypted data at rest, and managed secrets.
KoreLock, Inc. is a B2B IoT smart lock technology platform for lock manufacturers and access control providers, offering embedded firmware, PCBAs, white-label mobile and web apps, and cloud SaaS. Learn more at korelock.com.