A tag above the doorbell that a visitor taps with their phone. Their call reaches the household wherever they are, over video, audio or chat. No camera on the wall, no wiring, and nothing for the visitor to install. I lead the architecture, the backend and the infrastructure, and run the team that builds it.
A parcel, an engineer, a neighbour. The doorbell answers exactly one way: it makes a sound in a room you may not be standing in. The products built to fix this all took the same route — a camera on the wall, pointed at the street. That tells you what happened, records everyone who walks past, and is still often too slow to catch a courier before they have written the card and gone.
The brief was to make the door reachable without turning it into a surveillance point, and to do it without an electrician: no mains wiring, no chime replacement, and nothing the visitor has to download, install or sign up for. Whatever answered the door had to work for a courier who has ninety seconds and no interest in your product.
The visitor never authenticates. Tapping the tag opens a web page carrying a token that identifies the door, not the person. No account, no app, no install — a courier is in a call seconds after tapping. Everything the visitor touches is a browser page, which is why the product works for someone who will use it exactly once.
Moved the real-time layer onto LiveKit, replacing an earlier SIP-based approach. Carrying our own signalling and media path meant owning NAT traversal, codec negotiation and mobile call lifecycle forever — none of it product. The API keeps all business logic and the clients stay interchangeable; the media platform is a component we can reason about instead of a subsystem we maintain.
No camera means no record of who called — a deliberate product boundary, and the preview the resident sees comes from the visitor's own phone once they start contact. Session state lives in memory rather than a shared store, which is right for the current device count and is the first thing that changes at scale. The tags use secure NFC whose keys cannot be rotated casually, because rotating them invalidates every tag already programmed and mounted on a wall.
PRODUCT · doorlink.io
ZIPP LABS · platformDoorLink is in production: tags are programmed and mounted, the apps are in both stores, and the platform runs across six services with continuous delivery from GitLab. I own the architecture, the API and the infrastructure, and lead the developers building the web and mobile clients.
The part I care about most is not in the product. It is a documentation system of sixty-plus files with a decision log, a compatibility matrix across API, web, mobile and shared packages, and an additive-only contract rule — so a mobile release cannot silently break against an older API. Status is tracked against that, so what is done and what is not stay separable.
API, web, mobile and the shared package move on a compatibility matrix. Breaking changes follow a protocol rather than a hope that everyone deploys at once.
Contract tests, web end-to-end, mobile end-to-end and a risk gate on sensitive paths. A commit touching them without acknowledgement fails in seconds, not in review.
Versioning and API compatibility are decided before a build, and over-the-air updates are separated from changes that genuinely need a native build.
A standing review program with numbered findings, invariants and remediation playbooks — including secret rotation and a documented rule that NFC master keys are never rotated casually.
No sales pitch, no agency layers. I'll read your situation and reply within 24 hours with whether I'm the right fit.
