Customers, dealers, and the operations team each needed a different view of the ordering process. Splitting those views across unrelated tools would have created more manual work and conflicting records.
Three audiences were working on the same order
The platform had to serve customers placing orders, dealers managing their part of the relationship, and an internal team responsible for products, stock, fulfilment, and reporting. Each audience needed different controls, but all of them were changing the same underlying business record.
Building three isolated applications would have moved the reconciliation problem into the office. The essential design decision was to keep one order lifecycle and give each role a view that matched its responsibilities.
- Customers needed product discovery, ordering, and status without administrative detail.
- Dealers needed account-aware access and a focused route through their assigned work.
- Operations needed product, inventory, role, order, and reporting control in one workspace.
One workflow, expressed through three focused interfaces
The customer website, dealer application, and administration system were designed as separate surfaces over shared rules. Order state, product availability, account permissions, and reporting definitions were kept consistent instead of being reimplemented for each interface.
The interfaces reveal only the decisions available to the current user. That keeps the customer path short, gives dealers useful account context, and lets the operations team investigate the complete history when something needs attention.
- Shared product and inventory records prevent competing versions of availability.
- Role-based navigation removes controls that are irrelevant to the current user.
- Order events provide a traceable route from placement through operational follow-up.
Shared business rules sit behind every channel
An Angular administration interface and Flutter dealer application connect to a .NET backend backed by PostgreSQL. API boundaries keep client-specific presentation separate from order, inventory, permission, and reporting logic.
The practical architecture concern was not the number of frameworks. It was making state changes predictable, validating permissions on the server, and keeping enough context in logs and records to explain an order across channels.
- Angular supports dense administrative records and operational review.
- Flutter gives dealers a mobile surface suited to work away from a desk.
- .NET and PostgreSQL hold shared rules, transactional state, and reporting data.
The handoffs became part of the system
Customers can place and follow an order, dealers can work within their assigned scope, and operations can oversee the same lifecycle without rebuilding the story from separate tools.
The most useful result is a shared operational record. It gives future product work a stable base because new channels or reports can use the same order and inventory definitions rather than creating another parallel process.
- Review a complete order across customer, dealer, and internal events.
- Confirm that inventory visibility follows the intended account and role rules.
- Use operational exceptions to decide which workflow deserves the next improvement.
What the work established
Customers can place and track orders, dealers can manage their part of the process, and the operations team has one place to oversee activity.
- 01
One shared order lifecycle across customer, dealer, and administration workflows.
- 02
Inventory information available to the people who need it.
- 03
Role-based access keeps each interface focused on the work for that user.