From a 30-Day Deadline to 2,500 Vehicle Operations a Day

A new site exposed a much bigger problem

Reotech began working with FCS Group in 2025 as the company prepared its first regional deployment in Nice. The expansion should have been an exciting step. Instead, it exposed a serious weakness.

The software FCS was using had worked well enough for smaller operations, but Nice was different. There were more vehicles, more agents, more activity, more operational complexity, and much higher expectations from the client.

Very quickly, it became clear that the existing application was no longer simply inconvenient.

It was getting in the way of the operation.

Processes that needed to move quickly were difficult to manage. Managers lacked the visibility they needed. Field teams needed a better way to execute their work. And the client’s expectations for automation could not be met with the existing system.

Then the situation became urgent.

FCS had roughly one month to demonstrate that it could operate differently. Otherwise, an important client relationship was at risk.

One month to build the foundation of a new operation

When FCS came to Reotech, the obvious solution would have been to patch the old application and buy some time.

We chose not to.

The real problem wasn’t one broken feature. The system itself no longer matched the way FCS needed to operate.

So we started from the operation. We worked with FCS to understand how work moved through the company:

• How does a vehicle enter the workflow?
• Who needs to see it?
• What does an agent need while standing next to the car?
• What does a manager need to know from the office?
• What does the client expect to happen automatically?
• Where are people losing time?
• Where can mistakes happen?
• What information needs to move immediately between the field and management?

From those answers, we designed a new platform around the business itself.

We didn’t need everything. We needed the right things.

A month is not enough time to build every feature anyone could imagine. Trying would have guaranteed failure.

So we focused on the workflows FCS absolutely needed to operate Nice.

The first version had three core parts.

A control center for managers

We built a central platform where FCS could manage the operation and see what was happening across it.

Managers could follow missions, vehicles, users, sites, performance and operational activity from one place. Instead of information being scattered across different processes, the platform became the center of the operation.

A mobile application for field agents

Agents needed software that worked where the real work happened: next to the vehicles.

We built a dedicated mobile application allowing agents to receive their work, execute operational steps and send information directly back into the platform.

Management and the field were finally working from the same system.

The infrastructure around the software

But handing someone an application is not the same thing as making it operational.

FCS had purchased a large number of phones for its agents but didn’t yet have a proper system for managing those devices.

So we helped put that foundation in place too.

We introduced device management with Microsoft Intune, helped configure the phones and applications, and supported several of the surrounding technical and security requirements needed to make the system work reliably in the real world.

Because our job wasn’t to say “The software is finished.” Our job was to get the operation running.

30 days later, Nice went live

Within approximately one month, the first version was ready. The platforms were deployed. The mobile application was installed. The devices were configured. Agents began using the system. Managers could follow the operation. And Nice could run on the new platform.

Most importantly, FCS was able to satisfy the immediate requirements of its client.

The relationship continued. The crisis that triggered the project was over.

But something more interesting had happened.

The emergency system we had built in a month had become the foundation of a much larger platform.

Then we kept building

After the Nice launch, Reotech did not disappear. We continued working with FCS as the platform became increasingly important to the business.

Instead of receiving a specification every few months and returning with a finished feature, we began working directly with the people running the operation.

Managers would tell us:

“This part is slowing us down.”

or:

“We need to see this differently.”

or:

“This process creates too many mistakes.”

And we would investigate the problem with them.

Sometimes the answer was another feature. Sometimes it was a simpler workflow. Sometimes it was automation. And sometimes we could see an opportunity before anyone asked for it.

Because once you understand both the software and the operation, you start noticing things differently.

You can look at a repetitive manual process and ask: Why is a person still doing this?

You can look at data the company already has and ask: Why aren’t managers seeing this?

You can look at a workflow with ten steps and ask: Why does this need ten?

That is how the product continued to evolve.

From one site to a growing operational platform

The original problem was Nice.

Today, the platform is used across five and growing operational sites. And on a normal day, it supports approximately:

2,000–2,500 vehicle operations.

Every day.

The system has grown with FCS. New workflows have been added. Existing workflows have been refined. Management visibility has improved. The mobile experience has evolved. Automation has increased. And the platform continues to change as the operation changes.

What started as a 30-day rescue project became a long-term operational system.

A little of what’s underneath

The technology matters, but only because it allows the operation to work.

We designed the platform using a modern architecture built around technologies including React, Expo and Supabase.

The system was designed so that the web platforms, mobile application and backend could evolve together while sharing a consistent operational model.

We also integrated device-management and deployment processes around the application so that FCS could manage its growing fleet of operational devices.

But none of those technologies were the goal.

The goal was simple:

Give FCS a system that could keep up with the business they were becoming.

More than an application

FCS originally contacted Reotech because they urgently needed software. What developed afterward became something broader.

Today, we don’t only maintain the platform. We help think about how the operation itself can improve.

We work with the people using the system. We study the data. We identify opportunities for automation. We suggest new ideas when technology can remove friction. And we continue adapting the platform as FCS grows.

That’s how we think custom software should work.

Not as a project that gets delivered and forgotten.

But as a system that becomes more valuable as the business around it evolves.