Moventoro is a transport operations platform I built for the Dutch market. Its scope connects orders, warehouse work, route planning, drivers, track and trace, a customer portal and invoicing. The application uses Next.js, Prisma and NextAuth, with a mobile API serving an Android driver application.
The architectural center is the shared order lifecycle. Different teams need different screens, but they are still making decisions about the same operational work. The platform has to keep those views connected without pretending every role performs the same task.
An order changes meaning as work progresses
To a planner, an order is work that needs allocation. To a warehouse operator, it is something to receive, locate or prepare. To a driver, it is a stop with instructions. To administration, it is a service whose completion and commercial details matter.
Those perspectives overlap, but they should not become independent copies of reality. If one screen says a job is ready while another treats it as canceled, the business has to resolve a software disagreement before it can do its work.
My design principle is to model the shared identity and lifecycle first, then expose the appropriate view to each role. A screen can simplify information for its user while still referring to the same underlying order and the same business events.
Transitions carry more meaning than labels
A status label is useful only when the organization understands what makes it true. “Completed” can be ambiguous if it refers to a route, a delivery attempt, a warehouse step or an invoice. I prefer review questions that make the transition explicit: what happened, who was allowed to record it and what work becomes possible afterward?
The following are illustrative domain questions for a transport platform, rather than a literal list of Moventoro database states:
- Can an unassigned order appear in a driver’s active work?
- What happens to a planned stop when the order is changed?
- How should an unsuccessful delivery attempt affect the next action?
- Which evidence does administration need before billing?
Answering these questions together exposes disagreements that a collection of independently designed pages can hide.
The driver application is another operational view
Moventoro includes a driver-facing mobile API. That is an important boundary because mobile work happens under different conditions from a planning desk. A request may be delayed, a screen may be reopened and the information displayed when a task began may no longer be current.
For this kind of integration, I review the server’s authority over the action. The app should identify the intended operation; the backend should decide whether the authenticated driver can perform it on the current order. A previously displayed button is not proof that the operation remains valid.
I also distinguish a request being sent from a change being accepted. That distinction gives the interface a way to communicate uncertainty without telling an operator that work was recorded when the server has not confirmed it.
Exceptions are part of the normal workflow
Transport software has to represent interruptions, corrections and incomplete work. A useful operational screen should help someone decide what to do next when the happy path stops. It should not require a developer to reinterpret a generic error message.
My review approach follows an order through several roles, including a correction or failed step. I check whether each role can understand the current situation and whether an earlier decision is still visible enough to explain it. This is more informative than reviewing every page in isolation.
The value of Moventoro’s shared lifecycle is that planning, delivery and administration can be designed as parts of one system. The project brings together backend modeling, integrations, web interfaces and mobile operations around that shared understanding. Keeping the order coherent is what makes those separate capabilities work together.
Updated 26 September 2026.