Case study

The estate office

Visitor management and property administration, run as one platform across a property operator's customer sites.

Guardhouse to billingone resident record

Sector
Property management operator
Year
2022
Role
Team of four
Stack
Flutter, C#, .NET, SQL Server
Runs on
Self-hosted

The problem

Managed properties run visitors and residents on paper or on whatever the guardhouse happens to have, so registering a resident is manual re-entry and billing them is a separate manual exercise every cycle. For an operator running that service across properties, that manual work is a cost attached to every site they take on, which caps how many they can serve.

What we built

A visitor and resident management platform covering registration, visitor handling and resident billing in one place, with a mobile app on the resident side and a back office on the operator's. The operator runs it themselves and serves their customers on it, so a new property is an onboarding rather than a deployment.

The long version

Most visitor management systems stop at the gate: they record who came in and when. The reason this one runs to billing is that the two halves are the same record. A resident is a person the guardhouse needs to recognise and a person the operator needs to invoice, and keeping those in two places is what made both jobs manual.

The constraint that shaped the build was that the client is not the end user. They run the platform and serve property owners on it, so every decision that would have been fine for a single site was wrong here: a hard-coded rule, a workflow that assumes one way of running a property. It had to be configurable enough that taking on a new property is an onboarding rather than a change request, because otherwise the client’s own margin disappears into us every time they win one.