KEYS Community

A community platform reads like a social product from the outside. The engineering problem is that five different kinds of people act on the same records, and each of them is entitled to a different view of it. A resident sees their building. A property operator sees the buildings they manage. A council sees the area it is responsible for. A service provider sees the work offered to it. An administrator sees the configuration behind all of them.

Every feature therefore has to answer two questions before it can answer the first one: who is asking, and what are they entitled to see. Get that wrong once and a resident sees another building’s documents.

The audiences do not share an interface, because they do not share a job. Residents live in a phone app. Operators and councils work in the browser. Service providers have their own portal. Administrators have a console. All four are clients of the same API, which is what keeps one set of rules behind four front doors.

One Flutter codebase covers both mobile platforms, so a resident feature ships to iOS and Android together rather than twice, on two schedules, with two sets of bugs.

The backend is a TypeScript monorepo holding two deployable services. The API server owns requests, domain logic and persistence. A second service owns everything that leaves the system as a message to a human. They share entity definitions and message types through workspace libraries, and communicate over RabbitMQ.

Residents arrive by whichever route is easiest for them, and a community platform cannot dictate that. The system accepts email and password, phone with an SMS one-time code, and three social providers. Each is a separate strategy behind one factory, so adding a route is a new strategy rather than another branch in a login function that already has four.

Roles alone are too coarse for five audiences, so the model separates the role a person holds from the individual permissions that role grants. Route handlers declare the permission they require; a guard resolves the caller and refuses anything that does not carry it. The declaration sits next to the handler, which is the only place a reader will look for it.

The domain is wide rather than deep, and that is the point: a community is not one workflow but many small ones that all have to agree about membership, permission and notification. Modules are organised by domain rather than by technical layer, so a feature lives in one place instead of being spread across four.

Behind them sits a persistence layer of sixty-odd entity models under versioned migrations. The migration history matters more than the entity count: a live community platform cannot take a schema change that drops data, so every structural change ships as a reviewed, ordered migration.

When something happens that people should hear about — a post, a proposal, an event, a reply — the domain does not send anything. It emits an event. A listener turns that into a queued message, and the notification service decides what that means for each channel and each recipient’s preferences.

Each delivery channel is a strategy behind a common interface, chosen by a factory from the event type. The domain knows that something notable happened. It does not know that push exists, and it does not need changing when a channel is added or a provider is swapped.

A community platform is anchored to physical places, and UK address data is not a solved problem you can look up in one call. A postcode covers many properties. Property identity, coordinates, what sits nearby and how a location should be classified come from different sources that disagree with each other.

That work runs as its own Python service rather than inside the API, because it is I/O-bound against several third parties, its answers are cacheable, and it should never be on the path of a resident opening the app.

The platform connects residents to local services, which only works if those services are categorised consistently. Free-text descriptions from providers are not consistent. Classification runs as a separate Python service that assigns a category and sub-category to a service or business, so the directory stays navigable as it grows.

PostgreSQL holds the platform’s transactional state under a versioned migration history. Redis carries what is expensive to recompute and safe to lose. Files live in object storage rather than in the database. The distinction matters operationally: losing the cache is an inconvenience, and everything else has to be recoverable.

The whole system is containerised, which is what makes a four-client, three-service, two-language platform something a developer can run end to end on one machine before changing any part of it. That is a delivery property as much as a technical one: the cost of a change is dominated by how hard it is to see the effect of it.

The hard part of this system is not any one service. It is that a change to membership or permission touches a Flutter app, three web clients, an API, a notification service and two Python services, each of which can be right on its own and wrong together.