A passenger ferry operator gave commuters a timetable and ticket app that works when the harbor connection doesn't

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

Between the mainland terminal and a chain of island stops runs a commuter ferry service with a seasonal tourist surge and a timetable that changes four times a year. The operator sells tickets from staffed windows and a small online store, and vessel positions come from a licensed tracking feed it pays per call. Its riders are commuters with annual passes, day-trippers with phones and no patience, and terminal staff on whatever handsets the company issued years ago.

What it was costing

Timetables lived on a website that assumed good connectivity at the terminal — exactly where it failed — and seasonal ticket windows produced morning queues that pushed commuters toward driving.

What they could see

• The timetable page spun at the terminal precisely when commuters needed it, because coverage dies in the waiting hall's concrete corner.
• Ticket windows produced queues before the two morning sailings, and the queue pushed regular commuters back into their cars.
• Terminal staff called the office to confirm whether a sailing was on time, because the tracking page was no faster than the passengers' own guesses.
• Summer day-trippers missed sailings trying to buy tickets on the pontoon, then complained publicly about the operator.

The constraints we worked inside

• The vessel tracking feed is licensed and rate-limited; the app must not poll it naively.
• Ticketing runs through the operator's existing payment provider; no new payment relationship was in scope.
• The fleet includes older Android handsets used by crew-facing staff at the terminal.

What had been tried before

A contractor built a responsive timetable site with live tracking widgets that the operator promoted at the terminal.

It assumed the one thing the terminal lacks — connectivity — and every timetable change had to be re-published by the office, so the live page was routinely wrong.

The operator printed seasonal pocket timetables and sold books of paper tickets at convenience stores near the terminal.

Print went stale at every timetable change, paper tickets created their own validation queue, and neither did anything about the morning window queue.

What we proposed

We proposed an Android app that caches the full day's timetable at first launch and treats live tracking as a stream of compact deltas rather than repeated pulls, keeping the licensed feed inside its rate budget. Buying a ticket is two screens — route, then pay — reusing the operator's existing payment provider and saved passes, and the purchased ticket lives in a local pass store that validates offline. The performance bar came from the terminal's actual handsets, not our test phones.

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

• A cross-platform framework to cover iOS commuters too — The visible failures were Android-terminal problems and the build had to land before the season; native Kotlin met the old-handset performance bar without a framework's startup cost.
• An operator-run payment and ticketing backend — No new payment relationship was in scope, and standing up PCI-scoped ticketing before the season would have consumed the entire engagement on infrastructure instead of the queue problem.
• Polling the tracking feed on an interval with client-side throttling — Per-call billing means every idle commuter with the app open costs money; a delta subscription was the only shape that scaled with riders rather than against them.

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

Kotlin

Terminal staff handsets and commuter devices span old OEM builds; Kotlin native gave predictable background behavior where a framework's assumptions would have shown.

Jetpack Compose

The two-screen purchase flow and timetable views needed consistent state handling across many device sizes; Compose kept the UI declarative and testable with a small team.

WorkManager

Timetable refreshes, delta syncs, and pass cleanup are deferrable background work that must respect the feed's rate budget — WorkManager schedules it without a foreground service.

Room

The offline promise rests on a structured local store — cached timetable, pass state, sync queues — and Room's migrations keep that schema honest across releases.

Pass handoff to existing payment provider

The provider's saved-pass flow turned repeat commuting into two taps; building our own wallet would have added a payment relationship nobody asked for.

What went wrong

How we worked together

Cadence

A Tuesday demo call with the operations manager, plus Thursday mornings at the terminal during the two busiest sailings to watch real commuters use the build.

Client side

The ticket-office supervisor ran window-side trials; one deckhand with the oldest issued handset became our performance reference; the operations manager owned scope and vendor conversations.

Decisions

The tracking feed's terms and any provider-facing change went to the operations manager in writing; everything else was decided at the demo or explicitly deferred.

They provided

Credentials for the tracking feed, an introduction to the payment provider's integration team, the terminal device list, and staffing the ticket office during trial sailings.

What changed

The headline: share of digital tickets validated offline-capable at first launch of the trial season, read from the operator's validation logs — 62% → 89%, read from Operator validation logs. A second check: ticket-window queue length at the two busiest sailings at −41%.

The terminal's morning changed character. Regulars board scanning a phone that works in the concrete corner where the website never did, and the ticket window's queue is now mostly tourists rather than a daily ritual the operator had budgeted around. Terminal staff stopped calling the office for sailing status — the app is the source they trust. The operations team also gained something structural: timetable changes propagate to phones the day they are decided, so seasonal reshuffles stopped being a communications exercise.

The result was read from Operator validation logs against the pre-engagement baseline over the stated window, with a guardrail check on ticket-window queue length at the two busiest sailings. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• Google Play Console account, signing key custody, and the release checklist
• A runbook for timetable publication and cache-refresh behavior across versions
• The feed-rate budget document and monitoring dashboard for the delta subscription
• The terminal device matrix test kit, including the oldest crew handset
• A rehearsal script for payment-provider updates so future changes are tested the same way