A co-working operator put door access, bookings, and billing questions in one member app

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Across five cities this operator runs co-working floors where membership means door access, meeting-room bookings, and a billing relationship, all historically handled by different tools. Members carried fobs from a lock vendor, booked rooms through a web dashboard, and emailed the front desk about everything else. The front desk — two people per city — spent its day answering booking questions, and the members' committee, which has real teeth in this operator's governance, had demanded feature parity between iPhone and Android members from day one.

What it was costing

Members juggled a web dashboard, a separate door-fob vendor app, and email threads for everything else; the front desk answered booking questions all day, and access revocation for lapsed memberships took days.

What they could see

• Revoking access for a lapsed membership meant emailing the fob vendor and waiting days, during which the ex-member could still walk in.
• The front desk's day was booking questions — availability, changes, conflicts — while actual hospitality went unstaffed.
• Members kept three logins and two apps for one membership, and every onboarding tour began with an apology.
• Lost fobs cost a replacement fee, a vendor ticket, and a week of temporary clipboard sign-ins at the door.

The constraints we worked inside

• Door hardware is Bluetooth lock units from a vendor with a documented SDK but no cloud API for revocation — the app must manage keys directly.
• Membership billing lives in the operator's existing subscription tool; the app reads entitlements, never payment data.
• Both platforms needed parity from day one — a members' committee had demanded it.

What had been tried before

The operator asked the lock vendor about cloud-based revocation and received a proposal for their unreleased management portal.

The portal was months from shipping, priced per door per month across five cities, and still would not have fixed bookings or the three-logins problem.

Front-desk staff ran a manual revocation checklist — email vendor, disable booking account, flag billing — documented in a shared doc.

The checklist depended on someone noticing a lapse first; steps got skipped in busy weeks, and the physical fob kept working until the vendor answered.

What we proposed

We proposed one member app on a single React Native codebase, with the operator's subscription tool as the sole source of entitlements: access, booking rights, and guest privileges all derive from billing state. Door keys become short-lived Bluetooth credentials issued on app sync, so revocation is a billing change that propagates in minutes, and a lost phone is a re-sync rather than a vendor ticket. Native modules stay confined to the lock SDK, which is the only part that genuinely cannot be shared across platforms.

Just as important is what we ruled out, and why:

• Two fully native apps — One mobile engineer was the entire mobile capacity; parallel codebases would have halved the feature surface and made the committee's parity demand structurally impossible to keep.
• Replacing the Bluetooth locks with cloud-managed hardware — New locks across five cities meant capex and construction downtime, and the members' floors earn their revenue on occupancy, not infrastructure projects.
• A progressive web app for bookings layered beside the fob system — It would have left door access — the actual daily pain — untouched, and browser Bluetooth support could not drive the locks reliably on either platform.

How the work ran

Delivered by the experience pod — mobile engineer + designer over 10 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

React Native

One engineer, two platforms, and a committee-enforced parity requirement: a shared codebase with native modules only where the lock SDK forces it was the honest shape.

TypeScript

The entitlement model is the product's spine; one type definition shared between app and backend meant billing-state changes could not drift out of sync with what doors accept.

Lock-vendor native SDK

The vendor's SDK is the only supported path to their locks; wrapping it as a disciplined native module kept its quirks contained instead of smeared through the codebase.

Expo EAS

Key-rotation fixes had to reach members' phones without an app-store review cycle; over-the-air updates turned a security patch from a week into an afternoon.

Node.js backend

The entitlement service is glue between billing, the lock SDK's key service, and bookings; Node kept it in the same language the operator's future hires will read.

What went wrong

How we worked together

Cadence

Fortnightly demos with the operations director, plus a monthly walkthrough on one member floor in each pilot city during a working afternoon.

Client side

The operations director owned the program; each city manager owned their floor's rollout; a members' committee representative attended demos and reported back to the committee.

Decisions

The committee rep carried parity questions to the committee and returned with rulings; day-to-day product calls were made at the demo and logged in a shared decision register.

They provided

Lock SDK credentials and documentation, read access to the subscription tool's entitlement data, one pilot floor per early city, and front-desk staff time for trials.

What changed

The headline: members manage access, bookings, and billing queries in one app across all five cities — 3 tools → 1 app, read from Front-desk contact log. A second check: access revocation time for lapsed memberships at Days → minutes.

The front desk got its day back: booking questions moved into the app, so the desk greets members instead of arbitrating calendars. Revocation became a billing state change that takes effect in minutes, which changed how the operator thinks about departures — offboarding is now an administrative act, not a negotiation with a vendor. Members notice the consolidation mostly as the disappearance of a chore: one app, one login, and a door that recognizes the membership it always should have.

The result was read from Front-desk contact log against the pre-engagement baseline over the stated window, with a guardrail check on access revocation time for lapsed memberships. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The Expo EAS project, credentials, and release channels under the operator's account
• The entitlement model schema and billing-sync service with operational runbook
• Lock-vendor SDK documentation and our per-OEM tuning notes for the device lab
• A city-manager playbook for onboarding new floors and training front desks
• A staging tenant with synthetic members for testing future releases safely