Traul
Mobile Apps · On-demand Mobility
Three connected apps, built for less than their old vendor subscription would cost over two years.
Project
Traul
Service category
Mobile App Development / Custom Platforms
Tech stack
Flutter (customer and driver apps) · React and Vite (admin panel) · Shared backend
Here’s the gist
Traul connects customers who need goods moved with the drivers who move them, and an operations team that keeps it all running. The business was on an off-the-shelf app service that charged heavily for even small changes.
We built a customer app, a driver app and an admin panel as one connected system. The client owns the code and can change it directly.
The Challenge
Goods transportation depends on three groups working in step: customers who book, drivers who accept and complete jobs, and operations staff who manage users, pricing and exceptions. Each needs a different screen, and all three need the same live data.
The packaged product only fitted the business as far as the vendor allowed.
Three things had to work at once:
- Changes shouldn’t depend on a vendor: even small updates were charged at a high rate and queued behind other customers.
- Each group needed an app that fits: drivers and ops staff were working around the product, not with it.
- The business needed control: the subscription cost kept building up without giving them ownership of their own product.
So we built Traul
We built three apps on one backbone, shaped around how each group works.
Book and track
Customers request deliveries and follow their progress in the app.
Jobs on the road
Drivers see and accept available jobs, and update status as they complete them.
Ops in one place
Staff manage users, jobs and exceptions, with an overview of activity across the system.
One live record
All three apps read from one backend, so information is the same wherever it’s viewed.
Did it work?
A big yes.
3 apps
Customer, driver and admin, built as one system.
Cheaper
Built for less than the vendor subscription over two years.
Faster changes
No vendor lock-in.
The client owns its platform, ships changes on its own schedule, and has room to grow.
How we got there
From a vendor’s product to their own.
| Step | What we did | What it gave them |
|---|---|---|
| 01Map the three worlds | What we did Mapped the three user groups and the flows between them: booking, job acceptance, completion and operational oversight. | What it gave them A clear picture of what each group needs. |
| 02Build one backbone | What we did Designed one shared backend so a booking, a driver status change and an admin action all update the same live data. | What it gave them Consistent information across every screen. |
| 03Build the two apps | What we did Built the customer app with a simpler booking flow, and the driver app for accepting and completing jobs on the road. | What it gave them Apps designed for the people actually using them. |
| 04Build the admin panel | What we did Built a panel for operations staff to manage users, jobs and oversight from one place. | What it gave them One central place to run the business. |
| 05Hand over the keys | What we did Transferred the code so the client’s team can change the products directly. | What it gave them Freedom to change anything without waiting on a vendor. |
What’s Next
The client now runs its platform on its own terms. From here it can add new service types and reporting for operations, and extend the driver app with further features.
FAQs
Let's Clear Things Up
Start with
one message.
Tell us about your project and what you want from it. We’ll reply with a clear plan, an honest timeline and the team to make it happen.
100+ projects delivered in 15+ countries