How to build a freight platform like Flexport

The freight market does not have a visibility problem. It has a margin problem.

Flexport raised $2.3 billion and processes over $19 billion in freight per year. The business model charges 3-8% on the freight itself. For an importer moving $10M in goods annually, that margin costs $300K-$800K per year, on top of the actual freight cost.

Freight forwarders, 3PLs, and large importers who want branded shipment visibility for their clients don't need Flexport's margin model. They need the tracking layer. This guide covers what that layer is, how it works technically, and what it costs to build it.

According to FreightWaves research, the global freight forwarding market exceeds $200 billion annually. Yet most freight forwarders still communicate shipment status by email or phone call. That gap is exactly where custom visibility platforms create value.

Key takeaways

• The platform costs $160K-$240K to build. Flexport's 3-8% margin on a $10M freight book costs $300K-$800K per year.

• The hardest part is not the carrier API. It is mapping 20-30 milestone events per shipment into a clean data model.

• Project44 gives you one API for all ocean carriers. Without it, you're building 6-8 separate integrations.

• A client portal reduces customer service call volume by 40-60% for freight forwarders who deploy it.

Who actually builds this

Flexport serves mid-market and enterprise shippers who want to outsource freight operations entirely. That is not the same market as the companies building custom platforms.

The companies building their own freight visibility layer fall into four categories.

Freight forwarders with 500 or more active shipments per year want to give their importer clients a branded tracking portal. Their clients are asking where the goods are. Right now, the answer is an email or a phone call to an operations coordinator. A portal eliminates 40-60% of those inquiries.

Third-party logistics providers (3PLs) already have a Transportation Management System (TMS) for internal operations. What they lack is a clean, client-facing layer on top of it. Their TMS is built for internal operators, not for the retailer or brand owner who needs to see their shipment status in plain English.

Importers moving 500 or more containers per year want to track all shipments in one dashboard across multiple freight forwarders and carriers. Right now they're logging into each freight forwarder's portal separately, or getting PDF reports by email. A single dashboard that consolidates all shipments removes that coordination tax.

E-commerce brands managing complex multi-carrier shipping (air for replenishment, ocean for planned inventory, courier for returns) want one view across all modes without switching between carrier portals.

The shipment data model

Before writing any code, get the data model right. Every other piece of the platform depends on it: milestone tracking, alerts, analytics, the client portal.

A shipment record has these core fields:

Origin and destination. Factory address, country, port of loading. Warehouse or customer address, port of discharge. These are not just display fields. Port codes drive carrier API lookups.

Cargo details. HS code (the international product classification code used for customs), weight in kg, volume in cubic meters, declared value in USD, number of packages, package type (cartons, pallets, containers).

Transport mode. Ocean (full container load or less-than-container-load), air, rail, or truck. This determines which carrier APIs to call.

Incoterms. The internationally agreed terms that define who pays for which leg of the journey. EXW (buyer pays everything from factory door), FOB (seller pays to port, buyer pays ocean freight), CIF (seller pays ocean freight and insurance), DDP (seller delivers to buyer's door). Incoterms determine where your platform's tracking responsibility starts and ends.

Carrier assignments. Ocean carrier, booking number, container number, bill of lading number. These are the identifiers you'll pass to carrier APIs to pull tracking events.

Milestones. An array of events, each with a milestone type, planned date, actual date, and location. This is the most important part of the model. Every alert, every status display, every analytics calculation derives from the milestone array.

Milestone tracking: the core value

A container's journey from a factory in Guangdong to a warehouse in New Jersey has 20-30 discrete events. RaftLabs has built logistics visibility platforms for 3PLs and freight forwarders, and the data model design takes longer than any API integration. Get the milestone schema wrong and every alert, analytics query, and client-facing view needs to be rebuilt around it. Here are the major ones for a standard FCL (full container load) ocean shipment:

1. Booking confirmed
2. Cargo packed and sealed
3. Container picked up from factory (inland drayage)
4. Arrived at origin container freight station
5. Customs cleared at origin
6. Container loaded on vessel
7. Vessel departed origin port
8. Transshipment (most Asia-US routes transship through a hub such as Singapore or Colombo)
9. Vessel arrived at destination port
10. Discharge from vessel
11. Customs entry filed
12. Customs cleared at destination
13. Container available for pickup
14. Drayage (port to warehouse) assigned
15. Container picked up from port
16. Delivered to warehouse
17. Container returned to carrier (if applicable)

Each milestone has a planned date set at booking time. When the actual date arrives, the system records it and compares. If the actual date is more than 24 hours after the planned date, the shipment is in exception status.

This planned-vs-actual comparison is what makes the platform useful. The question shippers ask is not "where is my container right now." It's "will it arrive on time, and if not, how late?" The milestone model answers that question continuously.

Gartner research found that supply chain visibility is the top investment priority for logistics leaders, with 79% citing it as critical to resilience planning. Milestone tracking is the core of that visibility.

Carrier integrations: don't build these from scratch

You do not track ships yourself. You pull data from carrier APIs and data aggregators.

"The biggest mistake shippers make is assuming carrier data is clean. Ocean carrier APIs return events in inconsistent formats, with different timestamp conventions per carrier. Any aggregation layer needs to normalize those events before they hit your milestone model."

-- Jeff Tucker, founder of Tucker Company Worldwide, speaking at the 2024 FreightWaves LIVE conference

The fastest path is a freight data aggregator. Project44 costs $500-$2,000/month depending on shipment volume and provides real-time tracking for ocean, air, rail, and drayage through a single API. FourKites is a comparable option. One integration handles all carriers. This saves 3-4 months of building individual carrier integrations.

The slower path is direct carrier APIs. Maersk, MSC, CMA CGM, Hapag-Lloyd, and Evergreen all have tracking APIs. Each has different authentication patterns, different event schemas, and different update frequencies. If your freight is concentrated on one or two carriers, direct integration is reasonable. If it spans six carriers, the aggregator pays for itself in build time savings.

For customs clearance status, integrate with your customs broker's system directly. Most licensed customs brokers either have an API or will provide status updates via EDI (Electronic Data Interchange) or flat file. Build a parser for their format.

For drayage (the port-to-warehouse truck leg), integrate with your drayage carrier's TMS. Drayage events (container picked up, in transit, delivered) are the last-mile data that completes the picture.

Document management

International trade generates a specific set of documents per shipment. Your platform needs to store them, version them, and make them accessible.

The six core documents are: the bill of lading (the contract of carriage, the most important document in ocean freight), the commercial invoice (value of goods, for customs), the packing list (what's in each package), the certificate of origin (country of manufacture, affects import duties), the customs entry (the import declaration filed with customs authorities), and the delivery order (the carrier's authorization to release cargo).

Bills of lading get amended. If the cargo weight changes after booking, the B/L is amended and a new version is issued. If the consignee changes, the B/L is amended. Your document system needs versioning, not just storage: store each version, mark the current version, and show a version history.

Store PDFs on AWS S3, linked to the shipment record by document type. Access control: importer sees all documents for their shipments. Importer's customer sees documents for their specific shipments only. The freight forwarder's operations team sees everything.

Exception management and alerts

When a milestone is more than 24 hours late relative to its planned date, the shipment enters exception status. The platform needs to communicate that automatically.

The alert flow: planned departure date passes without an actual departure event recorded, system marks shipment as delayed, sends alert to the freight forwarder's operations contact and the importer's logistics contact. Alert includes reason code if available (port congestion, customs hold, equipment unavailability, weather).

Reason codes matter. "Your shipment is delayed" is less useful than "Your shipment is delayed due to port congestion at Shanghai, estimated 4 additional days." Reason codes come from the carrier API when available. When they don't come from the API, an operations coordinator updates them manually.

Build an exception dashboard for the freight forwarder's operations team: all shipments in exception status, sorted by days overdue, with the reason code and the next planned milestone. This is the operations view that replaces the spreadsheet most freight forwarders are currently using to track delayed shipments.

Use SendGrid for email alerts and Twilio for SMS on critical delays (vessel rerouted, customs hold exceeding 48 hours). Set up alert preferences per user so operations contacts don't get SMS for every minor delay.

The client portal

The client portal is a branded, read-only view for the importer's customers: the retailer, the distributor, the brand owner receiving the goods.

The customer logs in and sees their shipments, each with a status indicator (on track, delayed, arrived), the next expected milestone, and a timeline showing all completed and upcoming milestones. They can download documents. They can see the exception reason if the shipment is delayed.

They don't call the freight forwarder to get this information. That is the entire value of the portal for the freight forwarder: the 40-60% reduction in customer service inquiries that their operations team currently fields.

The portal is whitelabeled: the freight forwarder's logo, their color scheme, a URL on their domain (e.g., tracking.yourfreightforwarder.com). The underlying platform can serve multiple freight forwarder brands simultaneously. One codebase, multiple branded tenants.

Analytics

The analytics layer turns shipment data into decisions.

The most useful reports: transit time by lane (Asia-to-US ocean average is 28 days; what is your customers' actual average, and which lanes are running slower?), on-time delivery rate by carrier (which ocean carrier has the best on-time performance on your freight lanes?), exception frequency by origin country or port, cost per kilogram by transport mode, and document completeness rate (what percentage of shipments had all documents uploaded before vessel departure?).

According to McKinsey's Global Flows report, supply chain disruptions cost global shippers an average of 45% of one year's profits over a 10-year period. Analytics that identify which lanes and carriers underperform are the clearest path to reducing that exposure.

These reports tell the freight forwarder where to have conversations with carriers, where to adjust planned transit times, and which lanes are systematically underperforming.

Build the analytics on top of your PostgreSQL database. Standard SQL aggregations handle these reports. Do not over-engineer this with a separate data warehouse until shipment volume exceeds 10,000 per year.

Tech stack

The platform runs on a standard modern stack with a few logistics-specific additions.

React for the importer portal and the operations dashboard. A single-page application with role-based views. Node.js for the API layer. PostgreSQL for the shipment database (the relational model handles milestones, documents, and multi-tenant access control cleanly). AWS S3 for document storage. Project44 or FourKites for carrier data ingestion. Redis for real-time shipment state caching (the dashboard shouldn't hit PostgreSQL on every refresh). SendGrid for milestone alert emails. Twilio for SMS on critical delays.

For the milestone ingestion pipeline, run a scheduled job every 15-30 minutes that pulls updates from Project44 for all in-transit shipments, compares new events to the stored milestone array, writes new events, and triggers alerts for any newly-late milestones. This is the operational heartbeat of the platform.

Timeline and cost

16-20 weeks to ship a production-ready platform with:

• Shipment data model and CRUD operations (weeks 1-3)

• Project44 integration and milestone ingestion pipeline (weeks 4-7)

• Exception detection and alert system (weeks 6-9)

• Document management with S3 storage and versioning (weeks 7-10)

• Operations dashboard with exception management (weeks 9-13)

• Client portal with branded multi-tenancy (weeks 11-16)

• Analytics and reporting (weeks 14-18)

• QA, penetration testing, and production deployment (weeks 17-20)

Cost: $160K-$240K. The range reflects scope decisions: basic platform with one freight forwarder tenant versus a multi-tenant SaaS with configurable branding, analytics, and document workflows.

For context: a freight forwarder moving $20M in goods per year and paying a 4% margin on freight-forwarding fees is spending $800K per year in freight margin. A $200K platform that they own, white-label, and charge clients to use is a different unit economics conversation.

For more on supply chain software architecture, see our supply chain software development page. If this is your first custom logistics platform, see the custom software development overview for how we structure the engagement.

Frequently asked questions

How much does it cost to build a freight visibility platform?

A custom freight visibility platform costs $160K-$240K. The major cost drivers are the carrier API integration layer (Project44 or FourKites plus direct customs broker and drayage integrations), the document management system with versioning, and the multi-tenant client portal. A minimal platform with one carrier integration and no client portal runs closer to $100K. Build time is 16-20 weeks.

What is Project44 and do I need it?

Project44 is a freight data aggregator providing real-time multimodal tracking data through one API at $500-$2,000/month. You don't strictly need it. Maersk, CMA CGM, and MSC all have tracking APIs. But building direct integrations with each carrier takes 3-4 months. Unless your freight is concentrated on one or two carriers, Project44 saves more in build time than it costs in subscription fees.

What is milestone tracking in freight software?

Milestone tracking records each discrete event in a shipment's journey with a planned date and actual date. A standard ocean FCL shipment has 20-30 milestones. The comparison between planned and actual dates is what drives exception detection, delay alerts, and on-time delivery analytics. Without milestone tracking, you have a location display. With it, you have a predictive visibility platform.

What documents does the platform store?

Six core documents per shipment: bill of lading, commercial invoice, packing list, certificate of origin, customs entry, and delivery order. Bills of lading are frequently amended, so the system needs version control on documents, not just storage. Store PDFs on AWS S3 linked to shipment records, with access control by user role and shipment ownership.

How do freight forwarders give their clients portal access?

Build a whitelabeled client portal on a subdomain of the freight forwarder's domain. The freight forwarder's logo and branding appear throughout. Their customers (importers) log in and see only their shipments. The importer can optionally grant read-only access to their own customers (retailers, distributors). Access is managed by the freight forwarder's admin team through a user management interface.