A Fleet System for Mining: An MVP in Two Months

“We know infrastructure. But can we turn that knowledge into a software product?”

That was the question facing a technology infrastructure services company supplying networking equipment, cabling, and satellite links. It wanted to move beyond infrastructure and create its own software product.

The first idea was ambitious: a fleet-management system for mining operations.

The MVP was built by two developers in two months. That speed did not come from treating the product as simple. It came from giving a focused team a clear first scope and direct access to the client’s product managers.

Call it the Evidence-First MVP: build enough of the real operation to learn from actual use before expanding the roadmap.

Start with the operating problem

Mining fleets involve more than vehicles moving between locations. Fleet managers need a clear view of drivers, dispatches, active trips, and signs that something may require attention.

The MVP brought those responsibilities into one system. Fleet managers could manage vehicles and drivers, track dispatches, and monitor events such as a vehicle leaving its permitted area or braking suddenly.

The software also needed information from the field. It integrated with GPS tracking devices and dash-cam telemetry already installed in the vehicles, bringing location and driving-behaviour data into the operational view.

This was not a demo built around imaginary data. It was designed around the systems and hardware the operation already used.

Keep the first scope narrow

A first product does not need to contain every possible feature. It needs to test the central promise.

For this project, that meant connecting fleet data, dispatch management, and operational monitoring in one working product. Features outside that core could wait until the team had evidence from use.

A narrow scope also made decisions easier. The developers worked directly with the client’s product managers. Questions did not need to travel through layers of account management or sit in long email threads.

The team could review the working system, make a decision, and continue.

Use a small team deliberately

Two developers were not a compromise made after the plan was approved. The small team was part of the delivery model.

Fewer handoffs meant the people building the product stayed close to the people defining it. The scope remained visible. Feedback could be discussed against working software instead of static documents.

This does not mean every product should be built by the same team size or within the same timeline. It means team structure should follow the first version’s actual purpose.

Read [internal link: the method behind six months to two] for the delivery process behind the compressed timeline.

Let real operations shape the roadmap

The MVP is now in live testing with real fleet operations. The next feature roadmap is being planned from a system used with actual dispatches and drivers, rather than from assumptions made before launch.

That distinction matters for a company entering software as a new line of business. The first version creates evidence for the next investment.

Dihardja’s role was to turn a defined operational problem into something the client could test quickly. The result was not a finished product with every future feature. It was a working foundation for the next decision.

See [internal link: cost of a slow vendor] for the cost of delaying that evidence, [internal link: build vs. buy vs. in-house] for choosing the right delivery path, or our [internal link: services page] for the broader approach.

An MVP should not prove that every idea is correct. It should make the next decision less dependent on guesswork.