Ezhal: three role-specific apps from one codebase

Field service businesses have a structural problem: the three people involved in one job need three completely different interfaces. The customer wants to book and know when someone is arriving. The technician wants today's route and the ability to close a job with one hand. The manager wants to see everything at once.

Building three apps means three codebases, three release cycles and three places for the same bug to live.

The business needed all three, but not three separate products. Every one of them talks to the same bookings, the same technicians and the same payments — so duplicating that logic across three apps would have tripled the cost of every future change.

One Flutter codebase with a shared domain layer and three role-specific shells on top. The booking rules, the wallet and the payment flow are written once; what changes per role is which screens exist and what each role is allowed to do.

State is managed with Riverpod, which keeps that shared logic testable and stops the three shells from drifting into three subtly different implementations of the same rule.

On top of the core there is a loyalty layer the business actually sells on: subscriptions, a wallet, points, stamps and Apple Wallet passes, so a customer can keep a service pass on the lock screen.

Ezhal was delivered to the client as a private product; it is not published on a public store, so there is no link to install. The screenshot on this page is from the platform itself.