Home/ Case Studies/ Smart Logistics SaaS Platform
SaaS · Logistics · Multi-Carrier

A Multi-Carrier Logistics SaaS That Processes 50,000+ Shipments a Month

A D2C-focused logistics startup needed a single platform that could aggregate 15+ shipping carriers, pick the cheapest rate per shipment, generate labels in bulk, and handle NDR (non-delivery report) workflows end to end. Seven months later, the platform was processing 50,000+ shipments a month and saving brands ~20% on shipping cost.

50,000+Monthly Shipments
15+Carriers Integrated
~20%Avg Shipping Cost Saved
₹2 Cr+GMV in Year One

Project at a glance

Industry
Logistics SaaS · D2C shipping aggregator
Scope
Multi-tenant web app, rate engine, label automation, tracking, NDR workflows, carrier admin, billing
Team size
10 engineers + 1 PM + 1 designer + 1 QA
Timeline
7 months to v1 launch · 11 months to 50,000 monthly shipments
Regions
India-wide; architecture built for cross-border roll-out
Status
Live · ongoing retainer with ITD GrowthLabs for feature roadmap

The client & the problem

The founders had spent years inside a D2C brand and knew the pain firsthand: every carrier has its own portal, every portal has its own rate card, every label has its own format, and every NDR needs to be handled by a different dashboard. Brands shipping a few thousand orders a month were losing money on two fronts — paying above-optimal rates because switching carriers mid-volume is painful, and spending disproportionate ops time on tracking and NDR reconciliation.

They wanted to build the shipping layer D2C brands actually needed: one API, one dashboard, one invoice, and rate-shopping logic that did the math automatically per shipment. Their specific pain points:

  • No single source of truth: brands were logging into 4–6 carrier portals daily to book, track, and resolve issues.
  • Sub-optimal rates: choosing the "cheapest" carrier manually per shipment is theoretically possible, practically impossible at scale.
  • NDR black hole: failed delivery attempts were disappearing into carrier support queues — some for weeks.
  • No bulk workflow: generating 500 labels meant 500 clicks across multiple tools.
  • Finance reconciliation pain: weighing discrepancies, COD remittances, and refund claims were a monthly nightmare.

The solution: one platform, many carriers, smart routing

We built a multi-tenant SaaS platform where brands sign up, connect their store (Shopify, WooCommerce, Magento, or custom REST), and ship through the carrier network without ever touching a carrier portal. The architecture splits cleanly into four layers.

1. Carrier integration layer (the engine room)

A normalized adapter pattern wraps each carrier's API behind a common interface. Every adapter exposes the same five operations: getRates, bookShipment, generateLabel, trackShipment, and cancelShipment. Carrier quirks (rate caching, weight-slab rounding, serviceability rules) live inside the adapter so the business logic on top stays clean. Adding a new carrier is a ~2-week effort for the engineering team, not a platform overhaul.

2. Rate engine

For every shipment, the rate engine fetches live serviceable rates from every carrier in parallel, scores each against the brand's routing policy (cheapest / fastest / most-reliable / weighted mix), and returns a recommendation. Brands can accept the recommendation, override it, or let the system auto-select. The engine caches carrier rate cards per origin-destination-weight slab to avoid hammering carrier APIs during bulk imports.

3. Operations dashboard (React)

Brand's daily driver. Bulk order import (CSV, Excel, Shopify sync, WooCommerce sync), inline editing, rate shop → book → print label in one flow, tracking monitor with configurable alerts (stuck shipments, NDRs, RTOs), NDR resolution with one-click re-attempt requests, COD reconciliation, weight dispute management, and invoice downloads. Role-based access for multi-user brands.

4. REST API & webhooks (for engineering teams)

Well-documented REST endpoints for create-shipment, fetch-rates, track, and cancel. Webhooks fire for every status change — brands consume them to update their own OMS and trigger customer notifications. Full OpenAPI 3.0 spec + sandbox environment for testing.

Tech stack & why

This is a multi-tenant data-heavy SaaS where we need to stay fast under bursty imports (5,000+ orders at once during sales) and still keep each tenant's data isolated. The stack reflects those priorities:

Node.js (NestJS) TypeScript React 18 Next.js PostgreSQL 15 Redis BullMQ (job queue) AWS EC2 + RDS + S3 CloudFront Elasticsearch Datadog + Sentry GitHub Actions Docker

NestJS for the backend: the modular structure pays off hard on a large SaaS — 15 carrier adapters, rate engine, billing, NDR service, and auth are independent modules. DI makes them trivial to mock and test.

PostgreSQL for tenant data, Redis for hot paths: PostgreSQL handles the relational truth (shipments, orders, invoices). Redis caches carrier rate cards, session data, and the rate engine's short-lived quote tokens. Rate-engine response p99 stays under 400 ms even during peak.

BullMQ for every carrier call that isn't user-facing: bulk label generation, webhook delivery, NDR retry loops, and COD reconciliation all run on queues with exponential backoff. The dashboard stays snappy because it never awaits a slow carrier.

Elasticsearch for search: brands shipping 50,000/month need free-text search across AWB, customer phone, order ID, product SKU, and failure reason. Postgres full-text would've been fine at 10k — at 50k+, ES was a clear win.

The hardest technical problem we solved

The rate engine under bursty load. This was the single feature brands compared us against the incumbents on, and it had to be fast, accurate, and honest.

Fetching live rates from 15 carriers for every shipment, every time, is impossible: some carrier APIs take 3–6 seconds and throttle hard. A naive parallel fetch would blow our request budget in the first bulk import of the day. We solved it with a layered cache and a smart fallback:

  • Layer 1 — warm rate cache: rate cards from each carrier are prefetched and indexed by origin pin, destination pin, weight slab, and dimensional factor. Expiry is per-carrier (some publish fresh rates daily, others weekly).
  • Layer 2 — serviceability map: a carrier-vs-pincode lookup that answers "can this carrier even deliver here?" in under 5 ms. Cuts wasted live calls.
  • Layer 3 — live call pool: when the cache misses (new pincode, special weight), we fire a bounded parallel call — with a strict 2-second SLA. Responses that arrive late are dropped from the current quote but stored for next time.
  • Layer 4 — honesty guardrail: the returned rate is always the one we will actually book at. If a live quote comes back different at booking time, we absorb the delta and flag the cache miss for engineering — brands never see a bait-and-switch.

Net effect: p99 rate response under 400 ms even with 1,000 concurrent bulk-import requests, and zero support tickets for "my booked rate didn't match what I was quoted."

Go-to-market & ramp

The founders ran a 90-day closed beta with 8 friendly D2C brands, which caught the important bugs (NDR state transitions, weight-dispute edge cases, duplicate webhook fires). Public launch came with a transparent pricing page, self-serve onboarding, and a 14-day no-card trial — unusual in logistics SaaS at the time.

Growth was driven by content SEO (rate calculators, pincode-serviceability tools), carrier marketplace partnerships, and a free Shopify app that acted as an on-ramp. By month 11, steady-state monthly shipment volume crossed 50,000 with ~180 paying brands.

Results in year one

50,000+Monthly Shipments
15+Carriers on the Platform
~20%Avg Shipping Cost Saved per Brand
₹2 Cr+Platform GMV
<400 msRate Engine p99
180+Paying Brand Accounts
99.95%Platform Uptime
60%NDR Resolution Time Cut

"We evaluated three platforms before picking ITD GrowthLabs. What sold us was that they understood the carrier quirks — not in theory, but in the specific, painful way they show up on a Monday morning during a sale. The platform has paid for itself in shipping savings alone."

Co-Founder & CTO

Multi-Carrier Logistics SaaS · Bengaluru

What we would do differently

Two things. First, we would stand up the carrier sandbox environment in week one instead of month three — most early bugs were in the long tail of carrier response edge cases, and a sandbox-first workflow would have surfaced them before they hit beta customers. Second, we under-invested in the billing engine for the first six months. When volume crossed 10k/month, weight-dispute reconciliation and COD remittance workflows became the #1 support ticket source for weeks until we rebuilt that module properly.

Building a logistics SaaS or aggregator?

We have built multi-carrier rate engines, label pipelines, tracking layers, and NDR workflows enough times to know where the quicksand is. Let's scope your v1 against what actually works at scale.

Get a Free Consultation

Get Digital Growth Tips in Your Inbox

Weekly insights on app development, web design, SEO, and marketing. No spam — just actionable advice.

Join 2,500+ business owners. Unsubscribe anytime.