A climbing gym chain moved check-in, courses, and memberships onto members' phones

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

Three climbing gyms in three cities, each floor busy from the after-school rush to close, all run through a single front-desk terminal that handles check-in, sales, waivers, and everything else. Class bookings happen by phone during staffed hours only, so the 6pm queue at the desk is partly the desk's own making. The membership system is a desktop product the chain has outgrown but not outlived, and its waiver provider's signed documents are the chain's legal record — neither was negotiable.

What it was costing

Check-in ran on a desktop at the front desk, classes were booked by phone during staffed hours, and members queued at 6pm while the desk's single terminal also handled sales, waivers, and everything else.

What they could see

• Members queued at 6pm while the desk's single terminal processed check-ins one at a time between sales and waiver checks.
• Classes filled by phone during staffed hours, so the evening rush booked nobody and the morning shift answered booking calls all day.
• Front-desk staff verified memberships from a desktop screen while a line watched, and entry for a full class outlasted its warm-up.
• Members with lapsed waivers were turned away at peak, which the desk remembered as every bad interaction of the week.

The constraints we worked inside

• The membership system is a desktop product with an import/export XML bridge — no live API.
• Waivers are legal documents; the existing waiver provider's flow had to remain the record of truth.
• Members arrive to climb, not to learn an app; the check-in path must be shorter than the desk queue it replaces.

What had been tried before

The chain added a second desktop terminal at the busiest gym to split check-in from sales during peak.

The queue shortened by minutes and the staffing cost was permanent; phone bookings and waiver friction at entry were untouched, so the 6pm problem survived.

A website booking widget was added so members could reserve class spots online, separate from membership entirely.

Members booked online but still queued to be verified at the desk, so the widget added a step without removing one, and adoption quietly fell away.

What we proposed

We proposed a Flutter app where membership syncs through scheduled imports over the desktop product's XML bridge, and check-in writes back through the same bridge — the desktop system keeps its place as the record while phones take over the queue. The waiver provider's flow is embedded before any membership action, so the legal record never has a gap. Class capacity, waitlists, and drop-ins moved into the app, aimed squarely at the 6pm peak: the queue becomes a choice, not a bottleneck.

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

• Replacing the desktop membership system — It holds years of member records and billing history, staff know it, and replacing it was a six-figure project far outside an engagement meant to fix the front door.
• Self-service kiosk tablets at the desk — Kiosks move the queue a metre and add hardware to maintain in three cities; members arrive with phones in hand already, which is the cheaper terminal to program.
• An iOS-only member app — The chain's membership skews Android in two of three cities, and a parity gap at the front door would have surfaced at exactly the 6pm peak the project exists to fix.

How the work ran

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

The stack, and the reasoning

Flutter

A small team needed the check-in path, class booking, and waiver handoff shipped together across both platforms before the busy season; one codebase made the timeline real.

Riverpod

Membership state, waiver status, and class capacity all gate the same check-in action; Riverpod's testable providers kept those gates explicit instead of scattered through widget code.

XML bridge service

The desktop membership product's import/export XML bridge is its only integration point; honoring it kept the system of record intact and the chain's data continuous.

Firebase Auth

Members sign in with what they already gave the gym — email or phone — without the membership desktop database ever growing a second identity system.

Waiver-provider web embed

The provider's signed documents are the legal record; embedding their flow — not rebuilding it — kept the chain's liability posture exactly where it belongs.

What went wrong

How we worked together

Cadence

A Tuesday evening demo timed to sit just before the 6pm peak, then front-desk observation at all three gyms during at least one rush per fortnight.

Client side

The general manager owned the program across cities; each gym's front-desk lead ran local trials; the office administrator validated every XML bridge import against the desktop system.

Decisions

Anything touching the legal waiver record went to the general manager in writing; queue and booking behavior was settled by the desk leads who lived the 6pm peak.

They provided

The desktop product's XML bridge specification, a waiver-provider sandbox and their support contact, front-desk staff time during trials, and member test accounts per city.

What changed

The headline: majority of member check-ins via app during the trial months, with the desk terminal freed for sales — Desk queue → self-service check-in, read from Front-desk check-in logs. A second check: class bookings made outside staffed hours at +31%.

The 6pm queue became a scatter of members walking straight to the wall, phones in hand, while the desk terminal finally does what it was bought for: sales. Bookings now happen at 11pm from a couch instead of by phone at noon, which changed the classes themselves — fewer empty evening slots, fuller beginner courses. The desk's job changed rather than shrank: instead of being the bottleneck members queue against, the desk's time goes to the members who need a person — a lapsed card, a first-time climber with a question.

The result was read from Front-desk check-in logs against the pre-engagement baseline over the stated window, with a guardrail check on class bookings made outside staffed hours. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• Release pipeline and store accounts for both platforms under the chain's ownership
• The XML bridge service ops runbook, including import schedules and reconciliation steps
• Waiver-provider embed configuration with the completion-callback verification guide
• A front-desk playbook for the exception cases the app escalates to a human
• Load-test scripts reproducing a full-gym evening peak against the bridge