Who shows up, and how

Six role surfaces, one membership graph

AnKampung is not app-per-role. The same person can be a resident in one community, a committee member in another, and a guard somewhere else — every surface resolves from a single membership graph, so a role is a hat you wear, not an account you juggle. Where the ecosystem page lists the platform's eight capability surfaces, this page is about the six surfaces people actually open.

Role-based, not account-based

Each surface is a different shape — native apps for the phone in your pocket and the gatehouse, web consoles for the work a committee does at a desk, one public web page a guest never has to install. What they share is identity: all six read the same person and the same roles.

Native app

Resident App

Residents, owners, tenants, familythe app itself

The everyday surface. One login opens every home you belong to — the bungalow, the city condo, the house upcountry — with a switcher for community, unit and hat. Visitors, bills, bookings, notices and maintenance all live here, and it is the surface that keeps a local copy so it stays useful when the network drops.

Native app

Guard App

Security, the gatehouse/guard context

The people at the gate verify visitor QR and OTP passes here. It is built offline-first: when the link drops the guard still checks passes against the local ledger, and the access record reconciles on reconnect with nothing lost and nothing duplicated. This is the same device surface the pilot runs live.

Web console

Admin Console

JMB / MC, property managers/admin

Where a community is actually run. The community switcher, unit and resident management, Act 757 billing, arrears and numbered receipts, announcements with acknowledgment, approvals and reports. A web surface because committees and managers work on a bigger screen with real records in front of them.

Web console

Vendor Portal

Contractors, suppliers/vendor

The lift repair company, the landscaper, the cleaner. Vendors receive the work orders assigned to them, update progress against the same state machine, and close out — without ever seeing the rest of the community's data. Scoped access is a property of the membership graph, not a separate login system.

Public web

Visitor Portal

Guests, no install required/visitor

A guest never installs an app to deliver a parcel. They get a public link to register a visit, hold a pass and see the gate instruction — the smallest, most temporary surface, and the one that proves a role can exist in AnKampung without ever becoming a resident account.

Web console

Enterprise Console

Multi-development operators/enterprise

For the managers who run several enclaves at once. Cross-community rollups, per-tenant entitlements and editions, and the operating view of a portfolio — the surface where tenant #1 quietly becomes tenant #2 with a config change rather than a fork. Honest status: this is the formed edge of the platform, not yet shipped.

How a surface is chosen

The graph decides what you see

You do not pick a surface or remember which login goes where. AnKampung reads your memberships and roles, and the right surface — with the right scope — opens on the right device. The switcher moves you between community, unit and hat; nothing about it merges two communities' data.

One person

a single global identity

Many memberships

community · unit · role

The right surface

resolved, not chosen

Scoped to that role

sees exactly its own slice

These are the doors people walk through. What each door is actually running on — the resident app, the offline gatehouse, the money office, the maintenance spine and the rest — is the platform underneath, surface by surface.

Bring your community onto its own spine.

One gated enclave at a time — identity, money, gatehouse and governance that a committee can actually trust.