MobiPA: building an inclusive ride-sharing app for a French village, in Flutter

MobiPA is a mobile ride-sharing app I built in Flutter, between March and May 2021, as the final engineering project of my degree at Grenoble INP Polytech. The client was the city council of La Mure, a town of about five thousand people in the Isère department. The brief was specific: a way for elderly residents and residents with reduced mobility to request rides from municipal staff and volunteer drivers, for practical trips — pharmacy, town hall, market, medical appointments. Repo: github.com/aelmufti/MobiPA.

I want to write about this one because it is the project where I learned the most, and almost none of what I learned was framework-shaped.

Designing for users who do not use apps

The primary user of MobiPA is not a digital native. We did our first round of user testing with people in their seventies and eighties, most of whom had used a smartphone for less than a year, and several of whom were also dealing with macular degeneration, tremor, or arthritis. The first prototype was a conventional ride-sharing UI — small icons, gesture-based map interactions, a bottom sheet you swipe up — and it failed almost everyone.

The redesign that worked obeyed three rules:

• Tap targets at least 56 dp. Android's Material guideline minimum is 48, which is sized for unimpaired adults. Older users with reduced fine motor control consistently missed at 48 and consistently hit at 56. The extra padding is free.
• No gestures, only buttons. Swipe-to-dismiss is an invisible affordance. So is long-press-to-edit. We replaced every gesture with a labelled button, even when that made the layout uglier.
• High-contrast, large type. The default theme used 18pt body text, well above the platform default. We also avoided light-grey-on-white "secondary" text entirely, because none of our users could read it.

Most of these came out of the WCAG 2.1 AA guidelines, which I had only loosely encountered before. The audit at the end of the project surfaced the remaining 30% — text contrast on the splash screen, focus order on form inputs, missing semantic labels for screen readers, error messages that conveyed information by colour alone. Doing an accessibility audit at the end is too late; the next time I would have it running in CI from day one.

Why Flutter

The honest reason is curriculum. Grenoble INP's mobile course had moved to Dart and Flutter the year I took it, and the capstone was framed around that. The defensible reason, in hindsight, is that Flutter was a good fit:

• Single codebase, two platforms. The town hall needed both iOS and Android because their staff fleet had both. A team of three students could not have shipped two native apps in ten weeks.
• Material components on Android, Cupertino on iOS, one widget tree. The visual conventions on each platform mattered to older users, who would not have recognised a uniformly-themed app as "an iPhone app".
• Reasonable accessibility primitives. Flutter's Semantics widget exposes the semantic tree to screen readers fairly cleanly. It is not as mature as the native APIs but it was enough for an MVP.

Where Flutter cost us was on the form fields. Flutter's text input handling was, at the time, a notably awkward part of the framework — keyboard avoidance, autofill, accessibility focus order, all needed manual nudging. I spent a disproportionate amount of the project on the booking form.

Firebase as the only realistic backend

A capstone has a hard deadline and no operations budget. A Firebase setup (Auth, Firestore, Cloud Messaging for notifications) is the smallest backend that can handle registration, ride requests, status updates, and push notifications, without a server we would have to keep alive after the project ended.

The handover plan was the awkward part. When you build a Firebase app for a public-sector client and then graduate, what happens to the project owner of the Firebase console? We documented the migration path, set up a council-owned account before the final demo, and transferred ownership. Trivial in theory, fiddly in practice. Anyone doing capstones for real clients should plan that step from week one.

What "client work for a town hall" actually means

I had not done public-sector work before. Three things surprised me:

• The procurement cycle is slow even at small scale. Decisions that would take a startup five minutes — colour, app name, store listing copy — went through committees and feedback rounds that ate weeks.
• GDPR is not optional. Personal data collected by a town hall on its residents is regulated tightly. We worked through what we were storing, what we had a legal basis for, and what could be deleted on request. None of that was novel work, but all of it was real work.
• The success metric is not engagement. An inclusive-mobility app is successful if a handful of journeys per week happen because of it. That number does not look impressive on a slide. It is the right number.

What I would build differently today

If I were re-scoping MobiPA in 2026, I would seriously consider not building an app at all. A well-designed responsive web page plus SMS dispatch for the actual booking would reach a population that includes feature-phone users and would not need an install step. The app shape was right for what the brief asked; the brief did not necessarily ask the right question.

On the framework side, Flutter has come a long way since 2021 — text input is no longer the rough edge it used to be, Material 3 is in better shape, and the accessibility tooling has matured. I would still pick it for cross-platform with a small team. For solo work I would probably look at a progressive web app first now.

The thing that stuck

Designing software for someone who is not the audience for most modern software is a humbling exercise. The defaults you reach for when nobody has reminded you otherwise — small targets, low-contrast hierarchy, hidden gestures, dense information density — are bad defaults for the actual range of people who use computers. MobiPA was the project that taught me to treat accessibility as a design constraint rather than a checklist to satisfy at the end. That has shaped everything I have built since.