
Product design · Logistics
Shipora
Ordering, tracking and on-time delivery in one mobile app, with the research and persona work behind it.
View case studyLogistics product design and build, from Dhaka
I'm Maniruzzaman Jubayer. With the senior team I lead, I design and build logistics products: delivery and courier apps, fleet and dispatch dashboards, driver apps and the tracking pages customers check while they wait. The goal is a status people believe, screens that work in a cab or a warehouse aisle, and exceptions that reach someone who can fix them.
2 logistics case studies on this site · Apps in React Native and Flutter · Web in React and Next.js

Design engineer and product design lead, with a senior team behind me
04 problems
Four things I hear on intro calls with delivery, courier and fleet teams, and what I do about each.
When the app says "in transit" for a day, people call support or stop trusting the estimate. I design status as a timeline of real events with times beside them, an arrival window instead of a false-precise minute, and a plain message when something slips, so the customer knows before they have to ask. It's the thinking behind Shipora, a delivery app built around live tracking that my team designed.
Drivers use a phone in a cradle, in glare, often in gloves, with one hand and patchy signal. I design for that: large targets on the main action, high contrast, scanning before typing, as few taps per stop as the job allows, and an offline queue that shows clearly what has synced and what has not.
A dashboard that treats every vehicle the same hides the three that need help. I put exceptions first and keep normal operations quiet: late vehicles, route deviations and failed stops at the top, each with a time, an owner and a next step. It's how I approach screens like FleetPulse, a fleet management dashboard my team designed.
Orders, pricing, refunds and support tickets sit in different places, so a failed delivery bounces between people. I map the order from booking to proof of delivery, then design one admin view where counts by status, a live map and queues to approve or reject sit together, and every problem has somewhere to go.
Shipora, a delivery app built around live tracking, and FleetPulse, a fleet management dashboard, both designed by my team.

Product design · Logistics
Ordering, tracking and on-time delivery in one mobile app, with the research and persona work behind it.
View case study
Product design · Logistics
Real-time control over vehicle networks: tracking, scheduling and performance in one dashboard.
View case studyHave a delivery app or fleet dashboard that people only half trust? Let's look at the status model together.
Start a projectMost logistics businesses need several of these, and they all read from the same status, so I design them as one system.
Booking in steps, service and pickup options, a tracking timeline, checkout and order history for the customer, with an admin side for orders, zone pricing, support and refunds.
KPIs against last week, a live map, an alert feed, route suggestions, driver comparison and maintenance, laid out so a fleet manager sees what is going wrong in seconds.
The day's stops in order, navigation handed to the map app the driver prefers, barcode scanning, proof of delivery, failed-stop reasons and an offline queue, all usable with one hand.
Receiving, picking and stock views for tablets and handheld scanners, with capacity planning for the coming days and clear states for short picks, damaged goods and returns.
A tracking page that opens from a text message without an app or a login, with the arrival window, the next event and a way to change the delivery, plus the messages that point to it.
Portals where business customers book in bulk, upload manifests, print labels, follow many shipments at once and download invoices, with roles for the warehouse, finance and the account owner.
These shape screens, copy and flows. This is design guidance, not legal advice: your own counsel and compliance team confirm which rules apply to your operation and market.
Regulation (EC) No 561/2006 sets EU limits for drivers of road haulage and passenger vehicles: daily driving of no more than 9 hours (10 hours twice a week), and a break of at least 45 minutes after 4½ hours at the latest. For a driver app, that means showing the time left before the next break, and for dispatch, not offering a run that cannot be finished inside it. The tachograph stays the legal record; the app only reflects it.
GS1's Serial Shipping Container Code identifies a logistic unit, such as a case, pallet or parcel. On screens, I design scanning first, show the human-readable code after every scan, confirm with sound and vibration as well as colour, and keep a typed entry with check digit validation for labels that will not scan.
Apple calls When in Use authorisation the preferred choice for its privacy and battery life, asks apps to request Always only when necessary, and advises asking when someone engages the part of the app that needs location. So a customer app asks when they set an address or start tracking, a driver app asks at the start of a shift, and both have a working state for "no".
Google Play allows background location only when it is core to the app, approved through a Permissions Declaration Form with a short video that shows the prominent disclosure. Its list of features that could use foreground location instead includes delivery tracking for users, not drivers. I design customer tracking to work in the foreground and draw the disclosure screen a driver app needs for review.
Success criterion 2.5.8 asks for pointer targets of at least 24 by 24 CSS pixels, with listed exceptions. That is a floor, not a goal. In a moving van, in gloves or in a cold store, I make the main action of each driver and warehouse screen far larger than that, and space the rest so a slip does not mark the wrong stop as delivered.
Photos at the door, signatures and a driver's location trail are personal data. The UK regulator's guidance on storage limitation says you must not keep personal data longer than you need it, and should set standard retention periods. I design proof-of-delivery capture that frames the parcel, and admin screens that show how long each record is kept and when it is deleted.
The same four steps as every project, with the checks a delivery or fleet product needs added in.
We talk through one parcel or one vehicle's day: who books, who dispatches, who drives, who answers the phone when it goes wrong. No slides and no sales pitch, just an honest view of whether I can help.
The scope lists each role (customer, driver, dispatcher, admin), each platform, the systems the product talks to and the full list of statuses. You get one fixed quote for the whole project before any work starts. No retainer.
Weekly sprints in Figma, an update every 48 hours in Slack and a review call each week in your time zone. Driver and warehouse screens are checked at arm's length, outdoors and one-handed, and every permission has a refused state drawn.
A design system, a state table for every status and exception, and a walkthrough with your engineers. If you want it, my team builds the apps in React Native or Flutter and the dashboards in React and Next.js.
Everything your team needs to build the product, or to let mine build it, from the status model to the last empty state.
Every status an order or vehicle can be in, what moves it on, who sees it, and the words each audience reads. This is the document the rest of the design hangs on.
Booking, tracking, changing a delivery and getting help, on iOS, Android and a tracking page that opens from a text message without an app.
Stops, scanning, proof of delivery and failed-stop reasons, with large targets, high contrast and offline states for basements and rural roads.
Exceptions first, a live map, KPIs with their comparison, and queues where each alert has an owner and an action, on desktop and tablet.
Orders by status, pricing by zone, support tickets by priority and refunds to approve or reject, in one place.
Location, camera and notification prompts with their priming and refused screens on both platforms, plus sync, retry and stale-data states.
Components, tokens and usage rules, in light and dark, ready for more than one language, so the customer, driver and admin sides stay consistent.
Apps in React Native or Flutter and web in React and Next.js, by the team that designed them. See development.
Pick one, or combine them: most logistics products need a mobile side and a web side.
From statistics offices, quoted as published, with the year each figure covers.
An honest comparison, including the rows where the other two win.
| What you get | My team | Large agency | Freelancer |
|---|---|---|---|
| Senior people doing the work, not just selling it | Yes | Sometimes | Yes |
| You talk directly to the people designing | Yes | Usually via an account manager | Yes |
| Customer app, driver app and dashboard as one system | Yes | Yes | Often too much for one person |
| Design and build by the same team | Yes | Often | No |
| Cover when someone is ill or away | Yes | Yes | No |
| One fixed quote for the agreed scope | Yes | Sometimes | Sometimes |
| Workshops on site at your depot | No | Often | Sometimes |
| Many large workstreams at once | No | Yes | No |
Working with Jubayer and the team has been a blast. Their creativity has honestly taken our platform to new heights. Incredibly professional and so proud to work with, we’re over the moon with their results, and we can’t wait to team up with them again.

I highly recommend Jubayer for any design project. He quickly grasps complex concepts, excels in standard design practices, and responds promptly.

Writing on the dashboards, permission flows and app reviews that delivery and fleet products depend on.

SaaS dashboard design best practices for a product people open daily: start from the morning decision, then pick metrics, charts, states, alerts and colour.

App Store rejection reasons I design around: account deletion, Sign in with Apple, permission prompts, in-app purchase, privacy labels and demo accounts.

A WCAG 2.2 React checklist for level AA: what changed in 2.2, the components that fail most, short TypeScript fixes and the tests that keep them fixed.
Straight answers to what delivery, courier and fleet founders ask before they start.
It depends on how many roles the product serves (customer, driver, dispatcher, admin), how many platforms, which systems it connects to, such as telematics, carrier or payment APIs, and whether drivers need offline work or more than one language. After a free 30 minute intro call I write a scope and give you one fixed quote for the whole project, so you know the cost before you commit. There is no retainer and no hourly billing.
It depends on how many roles and flows the first version needs. A customer app with booking and tracking is a smaller job than customer, driver and admin sides together, and offline work or a second language adds time. A focused first version is usually a matter of weeks, not months. The written scope after our intro call sets out the timeline flow by flow, so you can plan a launch on a real schedule.
Yes. My team designed FleetPulse, a fleet management dashboard. I start from the decision a fleet manager makes in the next hour, then put exceptions first: late vehicles, route deviations and maintenance that is due, each with a time and a next step. Routine numbers stay calm, every headline figure has a comparison beside it, and the same screens work on a tablet in the yard.
The customer side usually does not. Google Play lists delivery tracking for users, not drivers, among features that could use foreground location, and Apple prefers When in Use access. A driver app that tracks a route with the screen off may need more, which on Google Play means a declaration and a video of the disclosure screen. I design both paths, and your developers confirm what the build needs.
It should, because basements, lifts and rural roads drop signal every day. I design an offline queue: scans, photos and signatures are saved on the phone, the screen shows what is waiting to sync, and nothing is lost if the app closes. My team builds driver apps in React Native or Flutter, and we agree the sync rules with your backend team during the scope.
Yes. Most logistics products sit on top of systems that already exist, so I map what your current software holds and which screens read from it before designing. My team builds the front end against your APIs, or hands your developers a design system and a state table for every status. I do not need to replace your backend to improve what drivers, dispatchers and customers see.
Yes, as design guidance. Under EU rules a driver takes a break of at least 45 minutes after 4½ hours of driving at the latest, so a driver app can show the time left before the next break, and dispatch can avoid offering a run that does not fit. The tachograph stays the legal record. Your compliance team confirms how the rules apply to your fleet and market.
Yes, everything. Every Figma file, the design system with its components and tokens, the prototypes, the status model, the handoff notes and any code my team wrote are yours, with no licence fees and no lock-in. Your developers can carry on without me the day the project ends, and I'm happy to sign your NDA before you share anything.