Who The Shipping Hack is and what they needed
The Shipping Hack is a parcel forwarding company. A shopper in Puerto Rico buys from a retailer that only ships to the mainland, sends the order to a warehouse address provided by The Shipping Hack, and the company receives it, consolidates it with anything else waiting, and forwards it on — right up to a driver handing it over at the door. The business operates warehouses in the United States and Puerto Rico and its own last-mile fleet, which puts it in the small group of forwarders that control the whole chain rather than dropping parcels onto a third-party courier at the border. That control is exactly what makes logistics software hard to buy off the shelf: no generic tool covers intake, consolidation, carrier rating, payments, dispatch, and delivery in one record.
The brief was an end-to-end parcel forwarding platform that replaced the manual process for every role in the business — customers, business accounts, warehouse staff at both sites, drivers, and the admins pricing and overseeing it all — along with a reusable design system so future features would not have to be designed from scratch each time.
The problem: manual forwarding across two warehouses
Forwarding a parcel is a chain of handoffs, and each one was being tracked by hand. The pain showed up in predictable places:
- Spreadsheets, phone calls, and email chains were the system of record, so a parcel’s status depended on whoever last updated a row.
- No single system spanned customer, warehouse, driver, and admin — each role worked from a different partial view and reconciled by messaging.
- Carrier rates, labels, and payments were handled through separate tools with no shared parcel record tying them together.
- Two warehouses meant two sets of shelves and two sets of staff, with no reliable way to know which site was holding which parcel at a given moment.
- There was no consistent UX, no component library, and no accessibility standard, so every new screen was a fresh design decision.
The stack we built it on
The platform has five surfaces on one backend. Customers use a mobile app and web portal; business accounts get their own portal; warehouse staff in the US and Puerto Rico work from React panels; drivers carry a mobile app; and admins run everything from a console. The customer and driver apps are built in Flutter, the web surfaces in React, and the backend in Node.js with Redis and WebSockets carrying the real-time layer. FedEx supplies rates, labels, and carrier tracking; Stripe handles cards, wallet balances, and invoices. This is the shape of most of our custom software and mobile app work in logistics: several thin clients over one authoritative model.
Design decision 1: the parcel is a state machine, and location is part of its identity
Every screen in the system reads from one parcel record that moves through a fixed set of states, and every state carries the warehouse or vehicle currently responsible for it. That single decision is what lets a customer’s tracking page, a warehouse status timeline, a driver’s task list, and an admin’s global order view all agree without reconciliation. The lifecycle looks like this:
- Pre-alerted — the customer registers an inbound parcel (retailer, tracking number, destination warehouse) before it arrives.
- Received — intake staff scan the parcel at the US or Puerto Rico warehouse and match it to the pre-alert.
- Binned — a scan-to-bin step assigns the parcel a shelf location, so the record knows which site and which bin hold it.
- Consolidated — multiple received items are combined into one outbound shipment at the customer’s request.
- Rated and paid — the customer picks a FedEx service from live rates, with any business-tier discount already applied, and pays through Stripe.
- Labeled — the carrier label is generated and printed at the warehouse.
- In transit — the shipment is moving between sites or on the carrier network, with FedEx tracking mirrored into the timeline.
- Assigned to driver — a delivery task lands in a specific driver’s app for the last mile.
- Out for delivery — the driver has scanned the parcel onto the vehicle.
- Delivered — proof of delivery (recipient name plus photo) is attached and the customer is notified.
Design decision 2: a reusable design system before feature screens
Five surfaces built by one team could easily drift into five visual languages. The project started in Figma with a component library, prototypes, and Dev-Mode specs, so buttons, forms, status chips, and tables were defined once and reused across the customer portal, warehouse panels, and admin console. Accessibility rules were set at the component level rather than checked screen by screen. Our UI/UX designers then ran design QA against the written acceptance criteria for each feature, so what shipped matched what was specified.
Design decision 3: role-based access with an audit trail
Warehouse staff, drivers, business users, and admins all touch the same parcel records, so the backend enforces role-based access control on every endpoint and writes an audit log for pricing, surcharge, and status changes. When a parcel’s history is questioned, the answer is in the log rather than in someone’s memory.
How the platform is built and run
The Shipping Hack is engineered the way a real-time, multi-role logistics platform has to be — one parcel record, an event layer that keeps every surface in sync, and access that is auditable:
- Five surfaces on one backend — a customer app and portal, a business portal, React warehouse panels for the US and Puerto Rico sites, a driver app, and an admin console — with the customer and driver apps in Flutter and the web surfaces in React.
- The parcel modeled as a state machine whose every state carries the warehouse or vehicle currently responsible for it, so the customer’s tracking page, the warehouse timeline, the driver’s task list and the admin’s global view all agree without reconciliation.
- A real-time event layer: each state transition is written once to the Node.js backend and published through Redis to WebSocket connections held by every client in scope, so a driver marking a stop delivered updates the customer’s screen and the warehouse timeline within the same second — and Redis lets the backend scale horizontally.
- FedEx for live rates, labels and carrier tracking mirrored into the timeline, and Stripe for cards, wallet balances and invoices, all tied to the one parcel record.
- Role-based access control enforced on every endpoint, with an audit log for pricing, surcharge and status changes.
- A reusable design system built first in Figma — component library, prototypes and Dev-Mode specs, with accessibility set at the component level — so five surfaces share one visual language.
- Automated delivery: Playwright end-to-end suites cover the customer portal, warehouse panels and admin console, including the multi-role flows, and run on every pull request through GitHub Actions, while Fastlane builds and submits the mobile apps.
What we implemented: across five surfaces
Sigi designed, built and shipped all five surfaces over one backend. Here is what we implemented across the customer app and portal, the business portal, the warehouse panels, the driver app and the admin console.
Customer app and portal
- Signup with a personal forwarding address and an address book for delivery destinations.
- International pre-alerts so the warehouse expects each inbound parcel before it lands.
- Consolidation requests that merge several received items into one outbound shipment.
- Rate shopping across FedEx services with the price shown before checkout.
- Stripe checkout with card and wallet options, plus invoices for business use.
- Label download and live tracking from pre-alert to proof of delivery.
Business portal
- Company onboarding with multiple user roles under one account.
- Tier discounts applied automatically during rate shopping, so the negotiated price is the displayed price.
- Analytics on shipment volume and spend for the account.
Warehouse panels for the US and Puerto Rico sites
- Intake screen that matches an arriving parcel to its pre-alert by scan.
- Scan-to-bin shelving so location is captured at the moment of storage.
- Consolidation workflow for combining items and recording the new package’s weight and dimensions.
- Label printing at the packing station.
- Per-parcel status timelines that show every scan, who made it, and at which site.
Driver app
- Job assignment pushed in real time, so a new delivery task appears without the driver checking in.
- QR scans at pickup and handover to confirm the right parcel is on the right vehicle.
- Proof of delivery capturing the recipient’s name and a photo at the door.
- An earnings view so drivers can see completed jobs and what they have been paid.
Admin console
- Global order view across both warehouses, filterable by state, site, customer, and driver.
- Pricing and surcharge management, including the business tiers that feed rate shopping.
- Driver and vehicle management for the last-mile fleet.
- Role-based access control and audit logs for sensitive changes.
Delivery practice: design QA, Playwright, GitHub Actions, and Fastlane
Each feature went from Figma prototype to Dev-Mode spec to written acceptance criteria before engineering started, and back through design QA before release. Playwright end-to-end suites cover the customer portal, warehouse panels, and admin console — including the multi-role flows where a warehouse scan must show up on a customer’s tracking page — and run on every pull request through GitHub Actions. Fastlane builds and submits the customer and driver mobile apps, so a store release is a pipeline step rather than a manual process. This is the same DevOps and CI/CD practice we apply to any multi-app product where a regression in one client breaks the others.
The team and expertise behind the build
The Shipping Hack platform was delivered end to end by one cross-functional Sigi team — product strategists, UI/UX designers, mobile and full-stack engineers, and QA — working as a single unit rather than handing the build between vendors. Sigi hires only specialists: every engineer is an expert in their own field, and we invest in the team as they deliver, supporting certifications and continuous learning so expert, motivated engineers stay on every build. It is the model we have run since 2016: deep, cross-industry expertise owning the whole stack, from the Flutter customer and driver apps and the React warehouse and admin panels to the Node.js backend and the Redis and WebSocket event layer that keeps five surfaces in sync. Keeping one parcel record consistent across five roles and two warehouses in real time is exactly the kind of demanding, multi-surface engineering our team is built for — the same capability behind our custom software and mobile app development work.
What shipped: one parcel record from pre-alert to proof of delivery
The Shipping Hack now runs intake, consolidation, carrier rating, payment, dispatch, and delivery from one parcel forwarding platform. Customers get pre-alerts, consolidation requests, and checkout in the app; warehouse staff have scan-to-bin and photo evidence instead of memory; business accounts see their tier discount inside rate shopping, which makes costs predictable; and the component library means new features start from existing parts.
The customer app is available as The Shipping Hack on Google Play. The Play listing markets the app more broadly than the operation described here — carrier comparison, live tracking, booking, and shipping to more than 200 countries and territories — while the two warehouses and the driver fleet in this case study serve the United States–Puerto Rico lane. The driver app is not on a public store listing; the developer’s Play page lists only the customer app.
Related logistics work and what comes next
The driver app and dispatch model here share DNA with two other courier builds: the Bix Delivery courier platform, an on-demand package delivery service with customer, courier, and admin surfaces, and the Antrak courier platform, where real-time job assignment was the core requirement. For the cross-border side, the Pacifrica Express logistics platform covers similar warehouse-to-doorstep tracking across borders. On the warehouse floor itself, the 3DLogistiX warehouse management system is the deeper treatment: a multi-tenant WMS with a live 3D view of the floor, where scan-to-bin is the whole product rather than one step in a parcel’s lifecycle.
If you run a forwarding, courier, or warehouse operation that still reconciles parcel status by hand, contact Sigi to scope a parcel forwarding platform with real-time tracking across every role, or read more about our work in logistics.
