From a fifth attempt to 1,073 shipments in one month

The situation

UrShipper was not starting from a blank brief. Founder Gil Nugraha had already made four attempts to turn the product into dependable multi-carrier shipping software. The pattern will be familiar to anyone who has inherited a failing build: the app technically existed, but every new feature broke something else, and the operations team bridged the gaps by hand — carrier rates, shipment documents, tracking, Shopify orders.

RaftLabs became the fifth delivery attempt in July 2024. The first useful question was not "what is wrong with the code?" It was the one buyers wish vendors had asked them earlier. What do you do when the system cannot handle something? Which tasks are still done by hand? The initial build took about 14 weeks, but the engagement did not end there: Shopify acceptance, carrier-specific improvements, and production releases stretched into 2026.

The clearest results are dated rather than rounded up. Project reporting recorded 214 migrated customers using the portal by June 2, 2025, 1,005 shipments between May 5 and June 2, 2025, and 1,073 shipments in March 2026.

The decisions that made the recovery credible

• Diagnose the operating failure, not only the codebase

  The visible problem was an underperforming application. The business problem was broader: customers and administrators had poor experiences, carrier rules were not consistently represented, and everyday shipment work created too much operational load. That distinction changed the recovery plan. The team organized delivery around the complete order-to-shipment journey and the people responsible for it, rather than treating each screen as an isolated feature.

  For a similar rescue, the first useful artifact is a failure map: where information enters, who touches it, which external system decides the next state, how the failure is detected, and what the operations team does when automation stops.

• Treat carrier integrations as separate operating contracts

  The hardest part of a shipping platform is not scaling the system. It is surviving the APIs it depends on. Each carrier API behaves like it was built in isolation, because it mostly was. The same shipment can return wildly different prices from different couriers, and an API can return a success response for a shipment that was never actually created.

  That means you cannot just show the cheapest price. You need logic to trust the price. UrShipper's testing exposed rules that were not fully known at estimation time, and project records show carrier-specific work around package measurements, chargeable weight, insurance, tracking updates, and commercial invoices.

  Aramex is a useful example. The delivered flow needed backend commercial-invoice generation and upload during shipment creation. When aggregated tracking updates were insufficient, the team added direct Aramex tracking work and polling. These are not edge-case embellishments; they determine whether staff receive the document and status needed to operate a real shipment.

• Verify commerce flows as business workflows

  The Shopify integration was not accepted because an API returned a successful response. The completed QA record covered connecting stores, importing orders, displaying live shipping rates at checkout, and updating fulfillment status. That is the relevant acceptance boundary: the merchant can complete the job, and both systems agree on what happened.

• Budget explicit discovery for external-system unknowns

  One lesson from the project was that the initial estimate should have reserved more time for carrier research and experimentation. Some rules emerged only while testing real carrier behavior. Before estimating a logistics software project, count the systems it needs to connect with, not just the features you want to see on the screen.

  That is a more honest plan than hiding uncertainty inside a fixed estimate. It also gives the client a clearer view of which risks belong to the product team and which depend on carrier accounts, contracts, or API behavior.

1. Rate comparison continued into a bookable shipment

   Merchants enter shipment details, review available services, and carry the selected option into booking, labels, documents, and tracking. The important design choice was continuity: the rate screen was not a standalone calculator. It began a shipment record that staff could later inspect and support.

   The platform also had to preserve carrier-specific requirements. A normalized comparison helps the merchant choose, but it cannot erase the rules needed to create the selected shipment successfully.

   

2. Shopify orders joined the same fulfillment flow

   Connected stores could bring orders into UrShipper instead of asking staff to re-enter them. Live rates could appear during checkout, and fulfillment status and tracking could be written back after shipment creation. The December 2024 QA record confirms these connected-store, rate, order-import, and fulfillment flows were tested and accepted.

   

3. Three roles shared one operational record

   Customers created and tracked shipments. Staff handled shipment exceptions, documents, verification, and support. Administrators controlled accounts, commercial rules, and reporting. Separating permissions while retaining one underlying shipment record reduced the need to reconcile customer activity against a separate back-office tool.

   

4. Commercial controls sat beside shipment operations

   The product documentation records account tiers, carrier markups, billing thresholds, consolidated invoicing, and customer-account controls. Keeping these rules near shipment data made it easier for UrShipper to trace how a carrier transaction became a merchant-facing price and an operations task.

   

How it runs

Hasura

Hasura supported the shared data layer behind customer, staff, and admin workflows. This case study does not publish UrShipper's private schema or permission rules.

React and Next.js

React and Next.js powered the role-specific web experiences used by merchants and the operations team.

AWS

Retained product documentation records AWS services supporting identity, compute, background processing, monitoring, and deployment. Exact production configuration remains private.