Approaching Mobile App Discovery for Logistics Companies

This post documents key insights from a recent mobile app engagement with a regional freight and logistics company. The client operates an established web platform for shipment management and sought to extend their digital presence with a native mobile application targeting receivers and distribution centers.

Project Context

The client is a well-established freight carrier with over a century of operational history. Their existing web platform handles core logistics operations including:

• Bill of lading creation and management
• Pickup scheduling and coordination
• Shipment tracking with ETA calculations
• Service time and density calculators
• Terminal locations and contact information

The mobile app initiative was driven by a desire to improve the experience for receivers—the end users at delivery destinations who currently have limited visibility into incoming shipments. The goal was not simply to replicate the web experience on mobile, but to create a contextually appropriate tool that accounts for how these users actually work.

Key Insight: User Context Changes Everything

One of the most valuable discussions during the proposal review centered on the fundamental difference between web and mobile contexts for different user types.

The client initially framed the project as "taking what we have on web and putting it on mobile." During our internal review, we identified why this framing is problematic:

Shippers (high-volume customers managing thousands of shipments) will almost certainly remain on desktop. The complexity of managing large-scale logistics operations doesn't translate well to mobile form factors, and these users are typically working from office environments with dedicated workstations.

Receivers (distribution center workers, dock staff, end recipients) operate in fundamentally different contexts. They're often mobile, working on loading docks, checking incoming freight, and coordinating with drivers. For these users, the priority is immediate visibility into what's arriving and when—not the full suite of shipment creation and management tools.

This distinction has significant implications for scope and feature prioritization:

User Type	Primary Context	Priority Features
Shippers	Desktop, office environment	Full shipment management, bulk operations
Receivers	Mobile, warehouse/dock	Delivery tracking, ETAs, notifications
Drivers	Mobile, in-transit	(Internal app considerations)

The lesson here is that simply porting web functionality to mobile ignores the jobs to be done for each user type in their actual working context. A receiver on a loading dock doesn't need to create bills of lading—they need to know when the next truck is arriving and what's on it.

Real-Time Tracking as a Differentiator

A significant portion of the initial prospect call focused on real-time tracking capabilities. The client expressed interest in "Uber-like" delivery visibility—allowing receivers to see truck locations and precise ETAs.

This feature represents both an opportunity and a technical challenge:

Opportunity: Real-time visibility reduces wait times at distribution centers and allows dock workers to prepare for incoming shipments. The client noted that this capability doesn't exist on their current website and would be a meaningful differentiator.

Challenge: The technical implementation requires exposing GPS data from driver devices, which introduces privacy and policy considerations. The client employs their own drivers (rather than using contractors), which provides more control over device policies, but legal review is still required.

During technical scoping, we identified that ETA and stop sequencing APIs are already available through existing backend services. This means we can provide meaningful delivery visibility even if precise real-time GPS tracking is delayed pending policy decisions. The phased approach allows the app to launch with ETA-based tracking while GPS integration is finalized.

Discovery Phase Structure

The proposal review resulted in a refined approach to the discovery phase that balances thoroughness with pragmatism. The key tension we navigated:

1. Doing enough upfront work to feel confident about build estimates and scope
2. Not overloading the discovery contract to the point where it becomes a barrier to engagement

Our approach structures discovery around three parallel tracks:

Product & Design Track

• Capture existing documentation, wireframes, and requirements that the client has already developed
• Conduct user research to validate assumptions about receiver workflows
• Synthesize findings into prioritized feature sets
• Produce a visual blueprint—a low-fidelity prototype demonstrating core user flows

The visual blueprint is intentionally scoped to essential features. It's designed to give the client enough to be excited about the build without attempting to cover every edge case. The goal is roughly 70% coverage of core functionality—enough to inform confident estimates, but not so comprehensive that discovery becomes a months-long effort.

Technical Track

• Inventory existing APIs and backend services
• Document data sources for each potential feature
• Identify technical gaps (e.g., real-time GPS exposure)
• Validate integration feasibility through exploratory testing
• Produce architecture recommendations for the mobile build

Business Track

• Understand budget constraints and internal approval processes
• Facilitate prioritization decisions against business value
• Structure deliverables to support the client's internal stakeholders

The output of discovery is a build brief—essentially the scope and contract for the next phase. This includes prioritized features, technical architecture, visual blueprints, and effort estimates broken into options (essential, core, comprehensive).

Concurrent Design and Development

A significant portion of the internal discussion focused on how design and engineering work should flow after discovery. The conclusion: front-loading all design before any development begins doesn't work.

From past projects, we've observed that designs inevitably change once the client sees a working implementation. Users interact with real software differently than static mockups, and feedback during testing often contradicts earlier design approvals.

The alternative is a feature-by-feature flow where:

1. UX/UI design for Feature 1 is completed and approved
2. Engineering begins building Feature 1
3. While Feature 1 is in development, design begins on Feature 2
4. Feature 1 completes and enters testing while Feature 2 development starts
5. The cycle continues through the feature backlog

This approach has several benefits:

• Design stays ahead of engineering but not so far ahead that designs become stale
• Client feedback on working features informs subsequent design decisions
• Scope changes are contained—adjustments to Feature 3 don't require reworking Feature 1

The tradeoff is coordination overhead. This requires clear handoff points, documented decisions, and responsive client review cycles. We plan to use linear project boards to make feature status visible and enforce review checkpoints.

Pricing and Scope Flexibility

One tactical decision from the proposal review: rather than quoting a fixed total price upfront, we're presenting a monthly rate range with the total engagement length determined by scope decisions made during discovery.

This approach addresses a common client concern: "How much is this going to cost?" without committing to a number before understanding the full scope. The message is essentially:

"Development will cost approximately $X-Y per month with a full team. How many months you build before launch depends on which features you prioritize. That's what discovery helps us determine together."

This frames the engagement as a partnership where the client has agency over scope/timeline tradeoffs rather than a fixed bid where every change triggers a contract renegotiation.

Takeaways

This engagement reinforced several principles that apply broadly to mobile app discovery:

1. User context matters more than feature parity. Mobile apps shouldn't just be smaller versions of web apps—they should be purpose-built for mobile use cases.

2. Start with jobs to be done, not screens. Before designing interfaces, understand what each user type is actually trying to accomplish in their working context.

3. Visual blueprints reduce scope creep. A low-fidelity prototype during discovery surfaces misaligned expectations early, before they become expensive changes during development.

4. Concurrent design/dev beats waterfall. For any project longer than a few weeks, flowing design and engineering in parallel produces better outcomes than front-loading all design.

5. Discovery contracts should be right-sized. Do enough work to feel confident about estimates, but don't let discovery become a barrier to getting started.

We'll document additional learnings as the project progresses through discovery and into the build phase.