Illustration for construction delivery platform

Project illustration; identifying client material is withheld.

Connecting builders, merchants, drivers, and operations in one delivery system

Construction delivery platform

Logistics
Project type
Web & mobile app
Project date
2025
Role
Sole developer

Getting construction materials to an active job site can be surprisingly slow. A missing item can send somebody across the city searching for stock, while existing delivery options do not always preserve the trade-account pricing that builders already have with their merchants.

I built an end-to-end platform that connected builders, construction-material merchants, drivers, and an internal operations team. The client and product name are withheld, but the product problem and my role can still be explained.

One product, four points of view

The platform served four distinct groups. A customer could request materials while retaining their existing trade discount. A merchant could receive and prepare the order. A driver could accept suitable delivery work and update its progress. An operations team could oversee the entire journey through a separate dashboard.

This was not four unrelated products. Each experience represented a different view of the same order, so every action needed to update one dependable shared state.

As the sole developer, I built the role-aware application experiences, the operations dashboard, and the underlying workflows that connected them.

Customer, merchant, driver, and operations views connected to one shared delivery order

Customer, merchant, driver, and operations experiences all acted on the same underlying delivery order.

Keeping the system in sync

The most important engineering challenge was preventing the different views of a delivery from drifting apart. A status change made by a merchant or driver needed to be reflected clearly for the customer and the operations team, without creating contradictory information or relying on somebody to relay an update manually.

I modelled the delivery as a sequence of explicit states and transitions. Each role saw the information and actions relevant to its part of the journey, while the underlying order remained shared. That made the system easier to reason about and gave operations a reliable view when something changed.

Matching a viable driver

Dispatch could not be reduced to finding whichever driver happened to be closest. The platform also had to consider whether a driver was available and whether their vehicle was suitable for the materials in the order.

I implemented the matching workflow around those practical constraints, turning an operational judgement into consistent product behaviour. The aim was to narrow the available drivers to sensible candidates while keeping the assignment process understandable to the people running the service.

What was delivered

The result was a working multi-sided platform covering the delivery journey from request through fulfilment. It preserved the relationship between builders and their existing merchants while giving every participant a clearer, role-specific way to act on the same delivery.

The value of the work lies in the system behind the screens: several different experiences, one shared operational truth, and business rules translated into software that could coordinate them.

The client name, original product visuals, commercial information, and identifying implementation details have been withheld.

Have a project in mind?

Send me the brief, rough notes, or problem you are trying to solve.

Start a conversation