GasyMove / TucTuc

What problem does GasyMove solve?

A TucTuc service in Madagascar brings together three groups whose needs pull in opposite directions: the rider who books, the driver who accepts, the operator who supervises. On the delivery side a fourth appears — the restaurant receiving orders.

None of these four views can wait. A ride, an order, a payment: it is real time or it is worthless.

What local constraints did I have to handle?

Payments. Neither cards nor bank accounts for most users. The real instrument is mobile money — MVola, Orange Money, Airtel Money — aggregated through Efaina. Three operators, three behaviours, asynchronous confirmations and intermediate states that must be made explicit rather than treated as errors.

The network. A driver loses connectivity while moving. The app has to stay usable and resynchronise, not throw an error and lose the ride.

KYC. A transport operator is accountable for its drivers. Document verification is a work queue, not a checkbox.

How is GasyMove architected?

Flutter with Firebase, one binary for two very different roles. Firestore security rules carry the rider/driver separation: a role enforced only on the client would be bypassed within minutes.

Firestore live listeners for ride and order state, rather than polling that would drain both battery and data allowance.

Two separate web dashboards in Next.js 16 and TypeScript: administration (driver, ride and revenue KPIs, KYC queue, transactions) and the restaurant board, which has its own rhythm and its own audience.

What did GasyMove teach me?

Designing for a market you do not know from the inside forces one simple discipline: never assume the infrastructure. Not the network, not the payment method, not the device. Every implicit assumption eventually gets paid for in the field.