From a blocked launch to live operations

The product existed. The launch did not.

Reotech began working with Paris-based ALB Mobility in 2024. Another provider had already built a significant part of the product. On paper, many of the expected components were present. In practice, the system was not ready for real operations.

Attempts to deploy it repeatedly exposed failures across connected modules. Payments and external services were not reliably integrated. The mobile application could not support the workflows expected from drivers, and important operational capabilities were still missing.

For ALB, this was no longer only a technical problem. The business was approaching an important season, and the product had to become usable by real people.

We started with the business, not the code.

Before deciding what to repair or rebuild, we spent long working sessions with the ALB team.

We learned how the operation worked, how the different actors interacted, what the first users needed to accomplish each day, and where the founder wanted to take the company. This gave us a much clearer picture than a backlog of isolated technical issues could provide.

The obvious response would have been to rewrite everything. It might have produced a cleaner codebase eventually, but it would also have consumed time ALB did not have.

Instead, we mapped the shortest responsible path to production. We identified the workflows blocking the launch, repaired the critical integrations, added the missing operational capabilities, and postponed work that would not help the first users succeed.

The launch happened with users, not behind closed doors.

As the first users entered the platform, our involvement did not stop at deployment.

We stayed close to their daily work, followed the problems they encountered, investigated failures as they appeared, and turned real operational feedback into product decisions. Development, deployment, user support, and product improvement moved together.

This allowed us to see the difference between what appeared important inside the codebase and what actually prevented someone from completing their work.

The result was a faster feedback loop and a product shaped around real operations — not assumptions made in a meeting room.

The rescue became a long-term product partnership.

Once ALB was operating in production, the work moved from recovery to continuous development.

What had previously been disconnected tools became one live platform connecting dispatch, partners, drivers, and clients. Today, the system includes an administrative dashboard, partner and client portals, a driver mobile application, payments, external services, and the shared backend coordinating the operation.

The delivery uses AWS extensively for hosting and operational services. The wider system also uses Supabase and Brevo, including transactional email workflows, alongside React, React Native, Node.js, PostgreSQL and Mapbox.

Driver assignment now takes half the time it previously required.

Reotech continues to work alongside ALB, strengthening reliability and security, improving existing workflows, introducing new capabilities, and observing how the platform behaves as the operation grows.

Working from the same picture

Our role with ALB is not limited to receiving tickets and implementing them.

Because we understand the business, its users, and its direction, we can make product and technical decisions from the same picture as the client. We understand what requires attention now, what can safely wait, and how a decision in one part of the platform may affect the wider operation.

The founder remains responsible for the vision. Our responsibility is to understand that vision deeply enough to turn it into software that works in the real world — and to keep the product moving in the same direction as the company.