Visitor management system

The problem

A security-conscious institution registers, approves and monitors every visitor. The visitor management system it relied on was a PHP and jQuery application with no clear architecture, database design, version control or testing environment, and nothing separated development from production. It worked, but it could not be safely changed or extended.

Constraints

• Inherited a working PHP and jQuery application with no clear architecture, version control, testing environment or separation between development and production
• The system was in daily use: it had to keep working while it was rebuilt
• Visitor and staff records in a security-conscious environment, where every person sees only what their role needs
• Proprietary and confidential: client, site and operational details stay private

Decisions and why

1. Fix how the team works before rewriting the code

   The problems were in the process as much as the language. Before the rebuild I introduced Git and GitHub, Scrum, separate development and production environments, and a UI/UX designer on the team, so the new system would not end up with the same problems as the old one.

2. One workflow, four roles, each seeing only its part

   Staff invite visitors, a security manager approves, denies, asks for more information or flags a visit, gate security validates a QR code, and reception checks visitors in and out. Each role has its own interface and sees only what it needs. The gate validates an invitation but cannot check anyone in.

3. A flagged visit cannot proceed until the alert is resolved

   Security decisions are enforced by the system, not left to whoever is at the desk. Gate results are deliberately simple: confirmed for today, already checked in, wrong day or not yet approved, or invalid.

4. Ship Version 1 to real users, then broaden the scope

   Version 1 went into daily use first, and feedback from the reception team shaped the changes. With that working, I proposed a centralised, configurable Version 2 intended to serve more than one site, and presented it to the client's stakeholders, who approved it.

5. A typed monorepo with checks in the pipeline

   Next.js and NestJS in one TypeScript monorepo (Yarn and Turborepo) share types between front end and back end. Storybook keeps UI components consistent with the designs, Terraform keeps the AWS infrastructure reproducible, and SonarQube runs in CI.

Result

Version 1 rebuilt and deployed into daily operational use. Version 2, a centralised and configurable system, completed in October 2026 and presented at a formal completion review with the client's stakeholders.

As of Oct 2026

Stack

• TypeScript
• Next.js
• NestJS
• Turborepo
• Storybook
• AWS
• Terraform
• Okta SSO
• SonarQube