What a Logistics Platform's Driver App and Customer Web Portal Have to Decide Before a Single Screen Is Designed

A logistics platform serves two completely separate groups of people, and the decisions you make before a single screen is designed will determine whether either group trusts it enough to use it. Customers need to know their goods are safe and that the price they see is the price they pay. Drivers need to know they will be paid, that the system is fair, and that their time is not wasted on disputes they cannot win. These are genuinely different design and behavioural challenges, and conflating them at the start of a build produces a product that serves neither group well.

The choices made before design begins are the ones that are hardest to reverse once build is underway.

We worked on a logistics platform for transport-based deliveries and removals, building two distinct products: a web portal for customers and a mobile app for drivers. Because the drivers were third-party contractors operating on a gig economy model, we could not rely on employment relationships to manage accountability. Trust had to be built into the product itself. That meant thinking clearly, before any design work began, about verification, payment, onboarding, registration, and what to defer. The decisions made in that early phase shaped everything that followed.

What follows is an account of the questions that came up on that project and others, and how we worked through them. Not every logistics platform will face exactly the same context, but the underlying problems recur: how do you verify that a delivery happened, how do you hold payment fairly, how do you sequence trust so people do not drop off before they have seen any value, and how do you decide what to build now versus what to build later.

Two Sides, Two Different Products

The most important structural decision on the logistics platform was accepting early that the customer portal and the driver app were two different products with different users, different contexts, and different emotional states. A customer booking a removal is in planning mode. They are probably at home, on a laptop, with time to read and compare. A driver confirming a delivery is in motion. They are outside, possibly in poor weather, under time pressure, and glancing at a phone screen between jobs. Designing a single interface to serve both is a category error.

This also shaped the channel decision. We built the customer product as a web portal rather than a mobile app. Customers booking a removal or a delivery are making a considered, relatively infrequent decision. They do not need an app living on their home screen. A web product that works well on desktop and mobile browser is faster to build, easier to update, and removes the friction of an app download for something a person might use twice a year. The driver product, by contrast, needed to be a native mobile app. Drivers are on the move, need offline resilience, and rely on device features like camera and GPS that a web product handles poorly.

Splitting the build this way has cost implications and scope implications. It is worth naming that clearly at the start, because teams sometimes try to build one shared codebase to save money and end up with something that works adequately for neither group.

Trust Asymmetry: Why Customers and Drivers Cannot Be Treated the Same

Customers and drivers bring different fears to the same transaction. A customer's fear is that their goods will be damaged, that the driver will not show up, or that the final price will differ from the quote. A driver's fear is that the customer will claim a delivery did not happen, dispute the condition of goods, or that payment will be delayed or withheld. Both fears are reasonable. Both have happened on other platforms. The product has to address both without implying that either party is dishonest by default.

This asymmetry means the trust signals each group needs are different. Customers need to see that the platform holds drivers to a standard: verified identity, a clear record of completed jobs, a mechanism for reporting problems. Drivers need to see that the platform will not leave them exposed to unverifiable claims: a record of what was collected, what was delivered, and confirmation from the customer that it happened.

According to BusinessWire, 2020, 77% of consumers feel more confident about a purchase when they receive proof of delivery in the form of a photo or signature. That figure points to something real: the delivery confirmation is a trust moment for the customer. For the driver, it is equally a protection moment. Designing verification as a bilateral action, where both parties confirm, addresses both fears at once.

Web vs App Is a Behavioural Decision, Not a Technical One

The web versus app question comes up on almost every platform build, and it tends to get framed as a technical or budget question. It is neither. It is a behavioural question: how does this person arrive at the product, how often do they use it, what device are they likely to be on, and what does asking them to download an app cost in terms of drop-off?

On the logistics project, the customer use case clearly did not warrant a mobile app. Booking a removal or a delivery is something a person plans in advance, often from a desk. Asking them to download a dedicated app to complete a single booking creates friction with no real upside. A web product, built responsively, handles the job. The driver use case was the opposite. Drivers are mobile by definition. They need the product to work without a reliable internet connection, they need camera access for proof of delivery, and they will use the product every working day. A native app was the right answer for them.

The rule we apply is straightforward. If a user's primary context is a desktop or a browser, and their usage is infrequent, a web product is almost always the better choice. If a user's context is mobile and physical, and they use the product regularly as part of their work, an app is the right choice.

The channel decision should follow the user's context, not the team's preference for native code.

Getting this wrong at the start means retrofitting later, which is significantly more expensive than choosing correctly before the first line of code is written.

Verification: How You Prove a Delivery Actually Happened

Proof of delivery is where the commercial and the relational interests of the platform converge. Without a reliable verification mechanism, every disputed delivery becomes a judgment call the platform has to make, usually without enough information, and one party always feels the decision went against them unfairly.

On the logistics platform, we implemented a double-confirmation system using swappable codes and QR codes. At the point of delivery, the driver and customer both confirm the handover through the platform: the driver scans or shares a code, the customer confirms receipt on their side. Both actions are timestamped and logged. Neither party can later claim the exchange did not happen without contradicting a platform record that shows both of them participating in it.

The design of this interaction matters as much as the logic behind it. The confirmation step has to feel like a natural part of completing a job, not like filling in a form to protect the platform from legal liability. If it feels bureaucratic, drivers will skip it where they can, and customers will find it confusing. The interaction should be brief, clear, and happen at the moment both parties are physically present together.

Build the verification step so it takes under fifteen seconds for both parties to complete. Anything longer and drivers will begin treating it as optional.

We also considered photo confirmation as a supplementary layer, particularly for deliveries where the customer is not present to confirm in person. A timestamped photograph of the delivered goods at the door creates a record that protects the driver from false claims and gives the customer confidence about the state of their items.

Payment Trust and the Case for Escrow

Payment trust on a gig economy platform runs in both directions. Customers worry about paying for a service that does not happen, or that falls short of what was agreed. Drivers worry about completing work and not being paid promptly, or having payment withheld during a dispute. A platform that cannot resolve both fears will lose either its customers or its driver supply, and often both.

On a separate gig economy product, we implemented an escrow model. The customer's payment is taken and held by the platform before the job begins. The driver knows the money exists and is committed. Once both parties confirm the job is complete through the double sign-off mechanism, the funds are released to the driver. Neither party can unilaterally withhold payment or claim they never agreed to pay.

This structure does something important beyond the mechanics: it makes the platform the trusted third party rather than an absent referee. The platform is holding the conditions of the agreement from the start. That shifts the emotional dynamic for both parties. The customer does not feel they are sending money into uncertainty. The driver does not feel they are working on trust that may not be honoured.

Set clear, visible timelines for payment release. Drivers who cannot predict when funds will land will move to platforms that are more transparent about it.

Sequencing Trust Requests Before You Ask for High-Stakes Actions

On a map-based fitness social network we worked on, users were dropping off at a specific point: the moment the product asked them to share their precise location with a potential match. The drop-off was not because location sharing is unusual. It was because the request came before users had any basis for deciding whether to trust the other person. They had not had a conversation. They had not seen a profile. They were being asked for a high-stakes disclosure as the first meaningful action in the relationship.

The fix was sequencing. We restructured the flow so users could see a profile and exchange messages through the platform's built-in messaging before location sharing came up. By the time the location request appeared, users had already formed a view of the other person. The request still asked for the same thing, but it arrived at a point in the relationship where it made sense.

The same principle applies on a logistics platform. Asking a customer to pay a deposit before they have seen a verified driver profile and understood the cancellation policy is asking for trust before the platform has earned it. Asking a driver to upload detailed personal documents before they have seen what the platform pays and how disputes are handled is the same mistake. Map out every point where you are asking something of the user, and then ask whether the user has had enough experience of the platform to reasonably agree.

Apps that request permissions in the first session without explanation see up to 60% lower opt-in rates compared to apps that wait until the user understands the value being unlocked. That figure reflects the same behavioural pattern: the ask has to follow the value, never precede it.

Transparency Over Tidiness: What Hiding Fees Actually Communicates

On a travel booking product we worked on, we made an early decision to wrap the platform's Stripe booking fee into the total price shown to users. The reasoning felt sound: travellers want a clean number, not a breakdown of costs they cannot control. What we found was the opposite of what we expected. Users assumed the clean total was hiding something. They expected to see a platform fee as a separate line item, because that matches how they experience other apps and platforms. Not seeing it created a fear that an extra charge would appear later.

We switched to showing all fees as line items, including the platform fee, and user confidence went up even though they were now seeing more information. The total price was the same. What changed was that users could see the full picture and recognise it as complete.

That experience shapes how we think about fee transparency on logistics platforms. A removal quote that shows a single total is tidier than one that breaks out the distance charge, the driver fee, and the platform margin. But tidy is not the same as trusted. Users who cannot see where a number comes from will fill the gap with the assumption that they are being charged more than they should be. Showing the breakdown does not increase the price. It removes the anxiety that the price is unknowable.

Show every fee as a line item, even when the total is fixed. Users who can see the components trust the total. Users who cannot will assume the worst.

Registration, Onboarding, and What Users Must Commit to Before They See Value

Registration gates are a genuine design problem on logistics platforms because the two user groups need fundamentally different onboarding experiences. A customer who found the platform through a search and actively chose to use it arrives with intent. They understand roughly what the platform does. Their onboarding is primarily about how to use it. A driver who was directed to the platform by a recruiter or an agency arrives with a different question: what is this, can I trust it, and is it worth my time to complete a long registration?

On the anonymous messaging app we built, requiring upfront registration before users could see any value meant we could not drip-feed the product's purpose through use. Everything that would normally unfold through the experience had to be communicated before the user ever opened the app. That pushed us to invest heavily in out-of-app content: App Store listing copy, screenshots, and preview content all had to carry the full weight of explanation that onboarding would otherwise handle.

On a logistics driver app, the registration process is necessarily substantial. Identity verification, vehicle details, insurance, and bank account information are all required. That is a lot to ask before a driver has earned anything from the platform. The design challenge is to stage the registration so drivers see evidence of value as early as possible, and to explain clearly why each piece of information is needed, rather than presenting a lengthy form with no context.

Third-Party Drivers and the Identity Problem

Third-party drivers create an identity verification problem that employed drivers do not. An employee is verified through a hiring process. A gig economy driver is verified only through what the platform requires at sign-up, and the platform has a strong incentive to keep sign-up frictionless to grow its driver supply. Those two pressures pull in opposite directions.

Customers on a logistics platform are trusting the driver with physical access to their goods and, in the case of removals, sometimes their home. The platform's identity verification process is the only thing standing between a customer and a driver whose credentials have not been properly checked. Getting this wrong is a safety problem and a liability problem.

The design implication is that identity verification for drivers cannot be optional, abbreviated, or skippable. But it can be staged. A driver can complete enough verification to see available jobs and understand what the platform pays, and then complete the remaining verification before their first job is confirmed. That sequence lets the platform show value before asking for full commitment, without compromising the actual standards.

The customer side of this is equally important. When a customer opens their portal and sees a driver assigned to their job, what information do they see? A name and a rating is minimal. A verified profile with vehicle details, a photo, and a record of completed jobs is meaningfully more reassuring. The platform's verification work should be visible to customers, because that is partly what they are paying for.

What to Defer: Staged Integration and the Danger of Launching Dependent on Incumbents

On a toll management project, we had an early conversation with the client about API integration with established toll operators. The idea was to launch with direct data-sharing relationships in place, so users could see their toll balances and history from multiple operators in a single product. We made the case that a brand-new, unproven platform would struggle to negotiate API access with incumbents who had no particular incentive to cooperate with an unknown product.

The smarter approach was to launch using a preloaded credit model, which gave the platform control over its own data without depending on third parties who had not agreed to anything yet. API integrations with toll operators could be pursued once the platform had established credibility and had something concrete to offer in a negotiation. The client accepted this staged approach, and it was the right call: launching dependent on integrations that had not been agreed would have created a hard blocker with no fallback.

The same logic applies to any logistics platform considering integrations with mapping providers, address verification services, or third-party ID checking tools. Each dependency is a risk if it has not been formally agreed before build begins. Stage the build so the core product can operate without any integration that has not been confirmed, and plan the integrations as a second phase once the platform has something to show.

1. Identify every integration the product depends on to function.
2. Separate confirmed agreements from assumed ones.
3. Build the launch version to work without any unconfirmed dependency.
4. Pursue formal agreements in parallel, treating them as phase two scope.

The Decisions That Cannot Be Undone After Build Begins

Some decisions made in the early phase of a product build are cheap to change before development starts and very expensive to change afterwards. Knowing which category a decision falls into is one of the most useful things a design and strategy team can do for a client before a sprint is opened.

The onboarding flow structure sits in a particularly difficult position. Skipping discovery on one part of a product while investing heavily in another creates contradictions that surface later. On a dating app we worked on, significant effort went into onboarding verification and identity checking. But without the same rigour applied to the messaging feature, the messaging system was built generically and allowed the exact behaviour the onboarding was designed to prevent: fake, automated messages. The verification work and the messaging work did not connect because discovery had not been done on both parts together.

On a logistics platform, the equivalent risk is investing in driver verification while leaving the dispute resolution flow undiscovered. If a verified driver and a customer disagree about whether a delivery occurred, the platform needs a clear process. Without one, the verification work cannot do its job, because the consequence of a disputed delivery is unresolved.

Conclusion

The decisions that shape a logistics platform most are the ones made outside design sprints. They are the ones made in the weeks before design begins: whether to build two separate products or one shared one, how to verify deliveries in a way that protects both parties, whether to hold payment in escrow, how to sequence trust requests so users do not drop off before they have seen any value, and what to defer until the platform has earned the right to negotiate with incumbents.

On the logistics and removals platform we built, working through these questions before a screen was designed meant that the verification system, the payment model, and the dual-product structure all served the actual behaviour of actual users. The driver app worked for people in motion. The customer portal worked for people planning from a desk. The double-confirmation mechanism gave both parties a record they could rely on.

None of those outcomes required particularly complicated design. They required clarity about what the product needed to do and for whom, established before the build created pressure to decide quickly and cheaply. Getting that clarity early is always faster and less expensive than retrofitting it later, and the platforms that get it right almost always did the thinking before the first wireframe appeared.

If you are building a logistics platform, a gig economy product, or any two-sided marketplace and want to think through these questions before build begins, let's talk about your platform.

Frequently Asked Questions