Galaxy DigiLabsSoftware Engineering, AI Automation & Digital Platforms

Case Study

Product2026

Every Door With Its Own QR Identity

A QR-driven platform where every physical door owns its QR code. Visitors scan a printed or on-screen QR and land on a public page for that specific door — to ring a bell, join a queue, log a visitor, mark attendance, check in or trigger an emergency. No app install needed.

A Galaxy DigiLabs product

Outcome

Live site (doors.digigalaxy.cloud) with HTTPS, the Door Core functional — core records synced, auto QR slug and image on insert, public landing and status routes working, and owner/operator roles in place.

Problem

Visitor management, bell-ringing, queues, attendance and check-ins are each served by a different tool — or by paper. A door at a gate, desk, counter or checkpoint has no identity of its own.

Business Context

The product is a multi-tenant platform where each physical door owns a QR code. Visitors need no app. Owners and operators manage doors through an operations workspace. It must work offline-first in poor connectivity.

Constraints

  • Zero install for visitors — a browser page is the whole experience.
  • Offline-first behaviour for poor connectivity.
  • Multi-tenant per Door: every door is its own isolated context.
  • Public routes must be safe for guest submission.

Analysis

The unit of the platform is the Door, not the visitor list. Once every door has an identity, a QR slug, a settings record and an event log, every use case — bell, queue, visitor log, attendance, checkpoint, emergency — becomes a DoorInteraction on that Door.

Architecture

Eight core record types model the platform: Door, settings, members, interactions, replies, event logs, mode templates and form fields. Controllers auto-generate the QR slug and image, log events and publish them over realtime.

Solution

Public routes provide a landing page per door and a status page per interaction. Guests submit through a public API. Owners and operators work through a dedicated operations workspace with defined roles.

Technology

  • Business application backend on the development server
  • Auto QR slug + QR image generation
  • realtime event publishing
  • HTTPS routing with SSL redirect
  • secure database and task queues

Implementation

Phase 1 delivered the Door Core: records, controllers, public routes, roles and the live site — built and verified against the actual server before moving to later phases.

Challenges

Realtime publishing of interactions, guest submission safety on public routes, and keeping the QR generation automatic so every door is immediately usable the moment it is created.

Outcome

The platform is live over HTTPS with a working Door Core: create a door, get a QR, and visitors can interact from a browser with no installation.

Lessons

When every physical object gets an identity, the use cases stop being separate products. The door is the unit of truth — everything else hangs off it.

Future Improvements

Additional interaction modes, offline-first sync refinement, and per-door configuration through the settings and mode templates.

Technology

business application backendQR codesrealtime eventsHTTPS routingsecure databasetask queues

Start With the Problem

Tell Us What's Not Working.

You don't need to know which framework, platform or technology you need. Start by explaining the problem - we'll design the system around it.

hello@galaxydigilabs.com