Projects

Veris

Veris was a visitor management system for physical workplaces. The product connected a device at the point of entry with employee, visitor, and workplace workflows.The important constraint was physical: the device could have internet connectivity only intermittently, sometimes for a few hours at a time. But the employee experience at the device still needed to feel immediate and dependable.

2016 → 2018 · Full Stack Engineer · Architecture · Past engagement

Visit site

How I contributed

Challenges

How does an unknown device know an employee?
The device could not assume it could query the backend whenever an employee arrived. Employee identity and relevant context lived in the central system, while the device might be offline. The employee experience therefore could not depend on a live internet request for every interaction.
A disposable QR code is not enough on its own
Employees used disposable QR codes to identify themselves to the device. The QR code solved the immediate identification hand-off, but the device still needed enough local context to resolve that interaction and complete the workflow when the network was unavailable.
QR security without making screenshots reusable
The QR flow used TOTP-based security so that a captured screenshot of a QR code would not remain valid. The code could be used as a short-lived identity signal rather than functioning like a permanent credential.
Offline operation without permanent divergence
The device needed to continue working while disconnected, while also keeping its local employee and workflow state aligned with the central system whenever connectivity returned.

Role & ownership

  • Contributed toOffline-first web application architecture
  • Contributed toEmployee and visitor workflows at the device
  • Contributed toQR-based employee identification flow
  • Contributed toTOTP-based security for the QR flow
  • Contributed toSynchronization between local device state and the backend
  • Contributed toReact and Web Components application development
  • Contributed toDjango and PostgreSQL backend development

How it worked

People
Employeedisposable QR
Visitor
Device
Veris deviceoffline-capable
Local application stateemployee + workflow context
Sync queuechanges while offline
Security
TOTPshort-lived QR validity
Platform
Django API
PostgreSQLcentral state
  • EmployeeVeris device— QR scan
  • Veris deviceTOTP— validate short-lived code
  • TOTPLocal application state— authorize interaction
  • Veris deviceLocal application state— resolve + operate
  • Local application stateSync queue— record changes
  • Sync queueDjango API— when connected
  • Django APIPostgreSQL— persist central state

The device was treated as more than a thin terminal. It needed enough local state to complete the employee experience without waiting for a round trip to the backend.

The disposable QR code was the hand-off mechanism for employee identity. TOTP-based security made the QR signal short-lived, so a screenshot could not simply be reused later as a persistent credential.

The harder engineering problem was making the rest of the workflow work when the device could not reach the source of truth. Connectivity therefore became a synchronization problem rather than a prerequisite for every interaction: local work could continue, and the device could reconcile with the central system when a connection became available.

Key decisions

  1. 01

    Build the device experience offline-first instead of making every interaction API-dependent

    Why
    Connectivity could be unavailable for hours, while the device was still expected to provide a smooth employee experience.
    Trade-off
    Local state introduced synchronization and consistency problems that a permanently connected client would not have.
    Result
    The physical entry workflow was no longer blocked by intermittent internet connectivity.
  2. 02

    Use disposable QR codes as the employee identification hand-off

    Why
    The QR code gave the device a concrete identity signal without making the employee's persistent identity depend on the device itself.
    Trade-off
    The QR code only solved identification; local employee context and synchronization still had to be designed around unreliable connectivity.
  3. 03

    Use TOTP-based security for QR validity

    Why
    A screenshot of a QR code should not become a reusable credential. Short-lived validity reduced the value of capturing the code outside the intended interaction window.
    Trade-off
    The QR flow had an additional time-sensitive security dependency to coordinate.

What changed

  • The device could continue to support employee and visitor workflows during connectivity gaps.
  • The architecture separated immediate local interaction from eventual synchronization with the central system.
  • Disposable QR codes provided the employee identity hand-off while TOTP-based security prevented captured screenshots from remaining useful indefinitely.
  • Offline-first became a product requirement translated into application architecture, rather than simply a frontend implementation detail.

Artifacts

Looking back

The interesting part of Veris was not the QR code itself. It was the boundary between a physical device and a distributed system: the device had to make decisions locally while the backend remained the central source of truth.

The QR security added another constraint: the identity hand-off had to be convenient enough to scan but not become a reusable credential if someone captured it.

This is one of those cases where an apparently simple product requirement — make employee check-in feel seamless — turns into a synchronization and security problem once connectivity cannot be assumed.

Related work