Logistics & Delivery Case Study
How Dev Entity built FastFly's courier platform and rider app, with shipment booking, tracking, COD reconciliation, delivery proof, and branch operations.
Context: FastFly Courier & Delivery Services, operated by FastFly Logistics Pvt. Ltd., is a Pakistani courier launched in 2024 for e-commerce sellers. Dev Entity builds and maintains its web platform, rider app, and integrations.
4
connected experiences: customer, branch, admin, rider
270+
API routes behind the platform
6 months
of continuous delivery since May 2026
Online sellers need more than parcel delivery. FastFly needed one system for booking and tracking, transparent charges, proof-based returns, and cash on delivery (COD) that sellers can reconcile, connected to the branches and riders doing the work.
A courier's records have to match what happens on the road. A single parcel passes through customers, branch staff, riders, and head office, while riders carry cash, work away from a desk, and need the app to keep working through a full shift.
The build choices were kept practical so the product could ship cleanly and remain easy to extend.
Assigned parcels, barcode scanning, pickups, photo and signature proof, failed attempts, COD collection, daily closing, and earnings.
Shipment and bulk CSV booking, labels, tracking, loadsheets, invoices, shipper advice, complaints, and support.
Receiving, sorting, dispatch, manifests, rider assignment, returns, self-collection, cash handling, and daily closing.
Rate cards, service areas, ledger entries, settlement cycles, invoices, payment proofs, reports, and staff access controls.
Parcel tracking without an account, plus separate registration flows for customers and riders.
A public API, Shopify and WooCommerce connections, signed webhooks, and API keys that sellers can create and revoke.
We built one application for the web portals and API, with code organized around courier domains: shipments, delivery, finance, branches, riders, pricing, and audit. Work began in May 2026 and has shipped continuously since.
Every role shares one shipment lifecycle. Customers, branch staff, riders, and admins see normalized statuses and tracking events that record who acted, so each screen describes the same parcel in the same way.
The rider app talks only to the HTTP API, and the server owns the amount a rider must collect. Development and production builds are separate apps with separate databases, so testing never touches live parcels.
Riders hand cash to branches, and branches remit it to head office. Each handover records the expected total and the cash physically received, and a shortfall needs a reason and stays open against the rider. Cash remittances need proof, and counter-booking charges sit in a separate ledger from customer COD.
Background tracking failed in ways that only appear on real phones. We fixed a crash from a missing boot permission, queued failed location posts and stopped duplicates, and restarted tracking that an app update left registered but stopped. Location now reports every 10 seconds while a rider has active parcels.
Stores retry requests, so shipment creation uses idempotency keys and each store order maps to one provider-scoped key. Inbound webhooks are verified and deduplicated by delivery ID, outbound webhooks are signed and retried, and test and live keys stay in separate environments.
Out-for-delivery WhatsApp messages are written to a durable ledger only after the status change is saved, with one record per idempotency key and an append-only history of attempts. The sender falls back from destination branch to origin branch to an authorized admin.
JavaScript fixes ship over the air, so riders do not wait on a store release. For native changes, the server sets a minimum supported version, and enforcement stays off until the new build is available on Google Play, so riders cannot be locked out by a release still rolling out.
An append-only log records who did what, when, from where, and what changed, and sensitive actions need a written reason. Parcel changes are captured by a plugin on the order model instead of calls in dozens of services, and personal data is redacted or masked in every entry.
FAQs
What courier, logistics, and delivery businesses usually ask before starting a platform or rider app.
It depends on your operation. FastFly covers booking, labels, tracking, rider assignment, branch dispatch, returns, COD reconciliation, invoicing, and an audit trail. Many teams start with the workflows that cause the most errors, then add the rest in stages.
Yes. A rider app can connect to your current system through an API or be built alongside a new platform. FastFly's Android app covers scanning, delivery proof, failed attempts, cash collection, and location sharing.
We track cash at each handover instead of only at the end of the day. On FastFly, the system compares expected and received amounts for riders and branches, keeps shortfalls open, and separates different types of cash into their own ledgers.
Yes. FastFly has a public API with Shopify and WooCommerce connections. Orders import with idempotency protection, so retries do not create duplicate shipments, and signed webhooks send shipment updates back to the seller's systems.
Yes, with clear rider disclosure. FastFly's rider app shares location during active delivery operations, and background tracking needs careful testing on real Android devices. We build in permission checks and retry handling for weak connections.
It depends on scope. FastFly has been in continuous delivery since May 2026 and keeps growing with the business. We usually phase a project, so a core booking and rider workflow can go live before finance and integrations are complete.
Share your parcel flow, your rider and branch setup, and your timeline. We will reply with our first thoughts on scope and next steps.
Book a 30-minute call