Multi-Carrier Shipping & Logistics Platform

What was on the table

A NetSuite-native shipping software vendor had a working product but a fragmented codebase: an Angular front-end, a NetSuite SuiteApp, an AWS Lambda tier, and tightly-coupled integrations with FedEx and UPS that broke whenever carriers shipped undocumented API changes.

The team needed:

• A carrier-agnostic abstraction so the next integration didn’t require touching the same code six times.
• Reliable test coverage across the stack — unit tests for SuiteScripts and Restlets, unit and end-to-end tests for Angular, integration tests for AWS Lambda.
• A continuous-integration pipeline that actually caught regressions before they reached customers.
• Faster shipment creation — the serial rate-shopping pattern was costing seconds per label.

What we built

A clean carrier abstraction layer lives in the NestJS backend on AWS. Each carrier is a plugin against a shared interface — rate, validate, label, void, track. Adding a new carrier is a contract implementation, not a rewrite.

The SuiteApp side handles the NetSuite-bound concerns: pulling orders into the rating workflow, writing back labels and tracking numbers, posting transaction records, and surfacing carrier exceptions where the operations team can act on them.

The Angular admin application talks to both surfaces. We rebuilt its testing story from scratch — unit tests against components and services, end-to-end tests with a stable selector strategy that survives layout changes.

CI runs on every push: lint, unit, integration, build artifact, deploy-to-staging. Code coverage is reported per-package. Pull-request reviews see the actual diff coverage, not a single summary number.

What broke along the way

Carrier APIs are a moving target. Mid-engagement, FedEx changed the response shape of their label endpoint and stopped returning a documented field — PackageRating.PackageRateDetails.NetCharge — without updating their public OpenAPI specification. The first sign was production label requests returning rate-of-zero.

We documented the actual response shape, built a fallback to the alternate location where the rate was now appearing, and added regression tests pinned to the real production response so the next undocumented change would fail the test suite instead of the customer’s billing.

This is the kind of work that does not show up in a marketing case study but defines whether a shipping platform is reliable in practice.

What changed for the business

Shipment creation went from a serial wait against each carrier to parallel rate-shopping with a configurable timeout. End-to-end label creation dropped from multi-second to sub-second for the common case.

Carrier additions are now a known cost — the abstraction tells the team exactly what they need to implement and exactly which tests to satisfy. New customers requesting unsupported carriers are no longer architectural events.

The CI pipeline catches API regressions before they reach production. The on-call rotation sleeps better.

What this looks like as a service

If you ship product via multiple carriers, write back to NetSuite (or any ERP), and have an integration layer that fights you every time a carrier ships an API change — this is exactly the kind of system we know how to fix.