A pharmacy delivery operation had no live view of where its riders were, or reliable confirmation that medicines had actually reached the patient. Marsos built the rider app, the dispatch portal and the platform behind them — so every shipment is followed from dispatch to proof of delivery, and managers watch the whole fleet on one map.
Delivery signals
Connected rider and dispatch platform
Live fleet map
rider positions updated continuously through the shift
Proof of delivery
every shipment confirmed, or its refusal reason recorded
Arabic + English
riders work entirely in their own language
One platform
rider app and control room share a single source of truth
01 / Context
The operating environment
A pharmacy delivery operation needed to replace manual dispatch sheets and phone check-ins with one platform connecting dispatchers, riders, warehouses, delivery zones, shifts, proof of delivery, and live fleet visibility. The public case study withholds the client and product name.
02 / Business outcome
What changed for the client
The result this engagement delivered — before any of the engineering behind it.
Connected dispatchers, riders, and managers in one workflow from shipment creation through proof of delivery and operational history.
Made delivery state, rider position, refusal reasons, feedback, and fleet statistics visible from one administrative portal.
Kept core business rules independent of infrastructure so identity providers, shipment types, carriers, and scheduled processes can be extended without rewriting the domain layer.
03 / Challenge
Complexity before transformation
Dispatchers lacked one system for shipment creation, rider assignment, warehouses, zones, shifts, status, and fleet statistics.
Riders needed barcode pickup confirmation, navigation, live location sharing, delivery or refusal capture, and history in Arabic and English.
Managers needed live operational visibility without coupling business rules to one identity, storage, or infrastructure provider.
Delivery photos, rider telemetry, account email, persistence, and releases required secure cloud services and controlled automation.
04 / Delivery
What Marsos engineered
Built a Flutter and Riverpod rider application for pickup scans, delivery execution, live GPS, photo proof, refusal capture, history, and bilingual use.
Built a React and Vite administration portal for shipments, riders, vehicles, shifts, zones, warehouses, users, feedback, and live statistics.
Built a .NET 8 domain-driven API with clean separation across domain, application, and infrastructure layers.
Deployed containerized services to Azure Kubernetes Service with Azure SQL, private Blob Storage, Okta OIDC, Quartz jobs, and Bitbucket Pipelines.
05 / How it works
The delivery cycle
The system, one step at a time — the sequence that carries an order, a shipment or a decision from start to done.
- 01
Shipment created
A dispatcher logs a shipment against a warehouse and customer.
- 02
Zone and shift match
The shipment is assigned to the on-shift rider who covers that delivery zone.
- 03
Pickup scan
The rider scans the shipment barcode to confirm pickup.
- 04
Out for delivery
Live GPS streams the rider's location to the dispatch map.
- 05
Delivery or refusal
Photo proof of delivery is captured — or a refusal reason is logged.
- 06
History and feedback
Status changes are logged, feeding fleet statistics and rider feedback.
06 / System Architecture
Architecture revealed as a system story.
Scroll through the technical decisions to see how each platform layer connects to the next.
Open full-size diagram ↗Rider app and control-room portal authenticating against one identity provider and sharing a single domain API. The numbered flows trace each real operation end to end: sign-in, barcode pickup, proof-of-delivery photo capture, live location batching, and the release path that ships it all.
Active decision
Matched shipments to on-shift riders by delivery zone and tracked the full lifecycle from creation through pickup, delivery, refusal, history, and feedback.
Architecture decision
Matched shipments to on-shift riders by delivery zone and tracked the full lifecycle from creation through pickup, delivery, refusal, history, and feedback.
Architecture decision
Validated Okta-issued JWTs on API requests while keeping identity replaceable through OIDC boundaries.
Architecture decision
Stored operational data in Azure SQL and uploaded proof-of-delivery media to private Azure Blob Storage.
Architecture decision
Batched rider location pings on a scheduled cadence and used gated build and deployment stages for the API and portal.
07 / Engineering highlights
Where the hard problems were won
The proof points a technical buyer should inspect first.
Impact
Modular by architecture
Domain, Application and Infrastructure layers stay decoupled — new shipment types or carriers plug in without touching core logic.
Impact
Swappable identity
Okta can be replaced with any OIDC provider without rewriting authentication flows.
Impact
Scheduler-ready operations
The same job pattern that batches rider telemetry extends to route optimization or SLA alerting.
Impact
Scales horizontally
Containerized on Azure Kubernetes Service with zero-downtime rollouts already wired into CI/CD.
08 / Platform surface
The capability map
Admin portal modules
Rider app modules
09 / Technology
The delivery stack
Flutter
Riverpod
.NET 8
Clean Architecture
React + Vite
Azure Kubernetes Service
Azure SQL
Azure Blob Storage
Okta OIDC
Quartz Scheduler
Confidentiality protocol
The client and internal product name are withheld. Use only approved screenshots or a sanitized redrawn architecture diagram, with no private endpoints, credentials, customer data, or operational identifiers.
Build with Marsos
Bring us the difficult system.We will make it buildable.
Start with a clear technical direction, an architecture that can scale, and a delivery plan your team can trust.