The customer
Books a service, sees a price, and knows when someone is coming. Tracking the technician in real time turns the most common support call into something the customer answers for themselves.
Services
Field service management apps: customer, technician, manager
Field service has a structural problem — the three people involved in one job need three completely different screens. We build all three from a single codebase, which is how Ezhal, a car-service platform, got a customer app, a technician app and a manager view without paying for three separate builds.
Who this is for
- A service business sending people out to jobs — maintenance, cleaning, repairs, installation, car services, deliveries.
- An operation dispatching work by phone call and WhatsApp, where nobody can say what is happening right now without asking someone.
- A company whose customers keep ringing to ask when the technician is arriving.
- A business that has outgrown a spreadsheet of jobs but cannot find software shaped like the way it actually works.
Three people, three different apps
The technician
Today's queue, in order, on a phone, usable with one hand and often with a dirty screen. Closing a job takes a tap, not a phone call back to the office.
The manager
Everything at once: who is where, what is late, what is done, and what it earned. The view that turns an operation from remembered into measured.
One codebase underneath
Three role-specific apps built from a single Flutter codebase. A fix is written once. A new feature does not have to be built three times, and the three apps cannot drift apart.
The parts that make it usable in the field
- Live technician tracking, so the customer stops calling to ask.
- Subscriptions and repeat service plans, for the customers who are not one-off jobs.
- A wallet, points and stamps, where retention actually matters to the business model.
- Apple Wallet passes, so a membership or a booking lives where customers already look for it.
- Payments through Stripe or MyFatoorah, chosen for the market you are actually in.
- Offline behaviour scoped deliberately: which actions must work in a basement car park with no signal, and what happens when the phone reconnects.
One we have already delivered
Ezhal is a multi-role car-service platform: three role-specific apps — customer, field technician and manager — built from a single Flutter codebase, with live tracking, subscriptions, a wallet, points and Apple Wallet passes, using Riverpod with MyFatoorah, Stripe and Firebase.
It was delivered to the client and runs as their platform, so there is no public store link to show you. The case study on this site describes what was built and how it fits together, and we can walk through it properly on a call.
Timeline and price
Three roles is genuinely more work than one app, and it usually lands at three to four months. The honest alternative is to start with one role — most often the technician, because that is where the time is being lost — and add the others once the first is earning its keep.
Either way the price is fixed in USD before anything starts, split across milestones, with a working build to open at each one.
Related work
Ezhal
Multi-role car-service platform
Read the case study →
Common questions
Can we start with just one of the three apps?
Yes, and it is often the right call. Starting with the technician app usually pays for itself first, because that is where jobs get lost. The architecture is built so the other roles can be added later without starting again — that is a design decision made at the beginning, not a promise made afterwards.
Do the technicians need a connection all the time?
No, but which parts work offline is a scoping decision rather than a default. We agree up front exactly which actions must work with no signal — usually viewing the day's jobs and closing one — and what happens to that data when the phone comes back online.
Can it connect to the system we already use for invoicing or stock?
Sometimes. It depends entirely on whether your existing system has an API or an export worth using, and that is the first thing we check rather than the last. If it does not, you will hear that on the scope call and not after you have paid for an integration.
How do customers pay?
Through a payment gateway in the app — Stripe, MyFatoorah or PayTabs, chosen for the country you operate in — or on completion in cash if that is how your business runs. Both are normal and the app should match reality, not the other way round.
Who owns the apps and the data?
You do. Code, intellectual property, hosting, database and the Apple and Google developer accounts are all in your name from the first day. That is the standing arrangement on every project here.
Get a fixed quote for your field operation
Describe how a job moves through your business today — who takes it, who does it, and who never finds out. You get a scope summary and a fixed price in USD.