Visitor Management for Enterprises, Built Multi-Tenant

Enterprises need to know who is in their buildings at any moment, who each visitor came to see, and to keep a clean record of it afterwards. Handled the traditional way, at a reception desk with a paper book, that breaks down quickly.

Visitors queue while a receptionist writes things down. Arrivals are unpredictable, so the desk is either overstaffed or overwhelmed. Couriers and food deliveries from services like Wolt and Glovo interrupt the same desk that is trying to process visitors. Staff who should be doing their actual jobs end up tied to the lobby. And the record of who was in the building - the thing security and compliance actually care about - is only as good as a handwritten book.

The brief was to replace all of that with a system many different enterprises could use, each keeping their own data private, without building a separate product for each one.

We built Gjestebook as a multi-tenant SaaS in Laravel and Vue. Many enterprises run on one platform, and each tenant's data is isolated from every other, so one codebase serves everyone while no company sees another's visitors.

Visitors register themselves at kiosks instead of waiting for a receptionist. They can book a visitor parking spot in advance, so arrivals are planned rather than improvised. Deliveries from services like Wolt and Glovo go through a dedicated fast-processing flow, so a courier dropping off lunch does not block someone arriving for a meeting. And every visit is logged: who entered, when, and who they came to see, which gives each enterprise the clean, queryable record that a paper book could never provide.

Visitor handling became predictable and largely self-service. Kiosk check-in cut waiting time for visitors and reduced the number of staff needed to process arrivals, because people sign themselves in rather than queueing for a receptionist.

The platform scaled to serve over 100 companies and handles around 70,000 visits a year. That is the real proof point: a single, well-architected multi-tenant codebase can carry genuine enterprise volume across many separate organisations, each with isolated data, without becoming a maintenance burden or a separate build per client.

The single most important decision in a product like this is made on day one: build it multi-tenant from the start, or pay for it later.

Retrofitting tenant isolation onto a single-tenant app is painful and risky, because data separation has to be correct everywhere, not almost everywhere. Designing for many tenants up front meant every new enterprise was an onboarding, not an engineering project, which is what let the platform grow to 100+ companies on one codebase. The discipline this demands - never assuming "the current tenant" implicitly - is worth enforcing from the first migration. It is much cheaper than discovering a cross-tenant data leak after launch.