Shipping label generation, built from the ground up.

Every carrier wanted the same parcel described a different way, and the difference was being absorbed by people rather than by software.

Carrier APIs disagree about addresses, service codes and what counts as a valid weight. Left unresolved, that disagreement turns into re-keyed data, rejected labels and parcels that sit still while somebody works out which field was wrong.

Narrative drafted from the brief — replace with the engagement detail

1. A

   The failures clustered in a handful of carrier-specific edge cases, not across the board.

2. B

   The existing backend already held everything a label needed; nothing was missing, only unreachable.

3. C

   Adding a carrier was a code change, which is why the list had stopped growing.

One Node.js label service on AWS in front of the carriers, so the rest of the business describes a parcel once.

• Carrier adapters

  One per carrier, each owning that carrier’s quirks so nothing leaks into the rest of the system.

• Backend integration

  Reads the order and address data already held in Postgres rather than asking anyone to enter it twice.

• Failure handling

  A rejected label says which field the carrier objected to, in language the warehouse can act on.