From one congregation to a multi-tenant church platform

Asori started in 2025 as the app for a single congregation in Kumasi. It reached Google Play and the App Store in October 2025, and Asori Admin followed in November.

Adoption inside that church grew into the kind of use that exposes architecture: ushers marking attendance every Sunday, dozens of leaders with different responsibilities, and administrators importing the church’s existing member records.

The data was shaped like a multi-church system, but authority was not. Permissions hung off the user, a single default church was assumed in places, and a leader’s access could only be described in broad strokes.

That made two things impossible: onboarding a second church safely, and giving each leader only the slice of the church they are responsible for.

The rebuild had to happen underneath a live product.

• A congregation depends on Asori every week — no big-bang migration.
• Mobile apps update slowly, so older versions had to keep working while the backend tightened.
• Church structures are layered: departments, up to six grouping levels, age-band ministries and ministry teams.
• Some roles need whole-church reach (ushers at the gate) but must still be kept out of personal profiles.

We made the church membership — not the user — the source of authority. A person has one identity and a separate membership in each church, carrying their role, status and scope in that church.

Effective access is computed on the server: an active membership, in an active church, with the role’s baseline or an explicit allow — and no explicit deny. Deny always wins, even over a pastor’s wildcard.

At a public level, the platform has four layers:

• Identity — one account per person, independent of any church.
• Membership — per church: role, status, department/group/age-band scope, allow and deny overrides.
• Authorisation — every privileged call is checked server-side against the active church and membership; cross-church requests are refused.
• Data — church-scoped collections, security rules that mirror the server checks, and caches keyed by church and scope that clear on sign-out, church switch or scope change.

• Scope before role: a department head sees their departments; an empty scope means no access, never “everything”.
• Separate the ability to act from the ability to look: ushers can mark anyone present without opening their profile.
• Lifecycle without data loss: churches can be active, suspended, offboarding or inactive, and no state change deletes data automatically.
• Explicit field allow-lists for administrative directory responses, so payment data, tokens and internal fields never leak into lists.

The work ran in stages through August and September 2026: a discovery of the single-church assumptions, a strict security-rule deployment, then the multi-tenant congregation integration, completed in mid-September.

Multi-church behaviour is exercised with synthetic A/B/A church fixtures, and the backend test suite grew past 1,400 tests. Older app versions were served by narrowly scoped temporary compatibility rules while users updated.

Asori runs on the multi-tenant model in production, with its first church partner operating on it. New churches can now be onboarded — each one verified by SomaMe first — without changing the architecture.

Every leader works inside a precise scope, and every sensitive action leaves an audit trail.

Authority is a product decision before it is an engineering one. Writing down who should see what — role by role, in the church’s own words — was the most valuable artefact of the whole project.

Deny-wins rules sound strict, but they are what make churches comfortable granting access in the first place.