In July, global container schedule reliability fell to 56.4%, a drop of 6.1 points in a single month and the sharpest one-month decline since January 2021. Shanghai took the worst of it: 21% of vessels arrived on time, a level the port has not recorded in fourteen years of data outside the pandemic. Singapore came in at 43.2%, Busan at 40.9%, Port Klang at 33.3% (Sea-Intelligence, via FreightWaves and Container News).
Somewhere in a few hundred companies that month, an internally built tracking dashboard kept showing ETAs that were quietly wrong. Not broken, which would at least be visible. Wrong, and confident about it.
That gap is where the build-versus-buy question actually gets decided, and it is usually not where the decision gets made.
The month a homebuilt tracker stops being right
Most in-house visibility projects start well. A data team pulls three or four carrier APIs, lands the events in a warehouse, builds an ETA view, and ships something genuinely useful. The demo lands. Leadership approves more headcount.
What the build encodes, silently, is the shape of the network on the day it was written. Transit times behaved a certain way. Carriers published schedule updates on a certain cadence. A port omission was rare enough to handle by email. When reliability drops six points in a month and one major origin port falls to 21% on time, every one of those assumptions moves at once, and nothing in the code raises its hand to say so.
The dashboard does not fail. It keeps rendering. The planner who trusted it last quarter now finds out about a blank sailing or a port omission from the customer, three days after the vessel skipped the call. The build did not break. It just stopped tracking reality, and there was no line item in the project plan for keeping up.
What you are actually choosing between
The question gets framed as software versus software: our build, which we control, against a platform, which we do not. That framing is wrong on both sides. You are choosing who carries a permanent maintenance obligation.
Carrier feeds are not a fixed target. They change formats, deprecate endpoints, add status codes, alter the meaning of existing ones, and go silent without notice. A forwarder gets acquired and its EDI profile changes. A carrier retires a tracking API on a twelve-month clock. None of this is exotic. It is the ordinary rate of change across forty trading partners, and it never stops.
So the real question is whether you want to own that obligation forever, with the staffing it implies, or rent it from someone whose whole business is keeping up with it.
The part of a build that never gets scoped
Connecting to a carrier is the easy fifth of the work. Making the connections produce comparable data across carriers is the hard four fifths, and it is a data engineering problem rather than an integration problem.
Take one milestone. Carrier A stamps "delivered" at the driver scan. Carrier B stamps it when the paperwork uploads, six hours later. Carrier C sends nothing until the invoice generates the next day. Concatenate the three feeds and your OTIF number is fiction. Real consolidation means a canonical milestone model, a mapping per partner, and rules that resolve conflicts when two sources disagree. We have written about what consolidating freight tracking across carriers actually takes, and the honest summary is that the normalization layer is the product.
This is the line where a command center like Orkestra earns its place in the stack rather than competing with it. Orkestra sits above ERP, TMS, and WMS instead of replacing any of them, and the 200+ pre-built carrier and system connectors come with the normalization already done and maintained by someone else. Your team stops writing mapping rules for a carrier's new status codes and goes back to working exceptions, which is the job you actually hired them for.
Note what that does not claim. Your PO data still has to be right. What changes is narrower: the grinding, permanent work of keeping forty partner feeds comparable stops being yours.
Time to value is a cost, not a nice-to-have
Build timelines get quoted in quarters and land in years, and that delay is not neutral. Every month without a reliable exception signal is a month of demurrage you did not see coming, expedites you paid for, and customer calls your service team took blind.
The contrast is worth being concrete about. On Orkestra, the Defense Logistics Agency consolidated visibility across carriers in a four-week deployment and saw an 83% increase in proof-of-delivery visibility across thousands of shipments a week. Whatever your internal estimate says, compare it against four weeks, then against your own build history rather than its plan. Most teams have a replatform or integration project in recent memory that ran long, and the reasons have not gone away.
When building is genuinely the right answer
Buying is not always correct, and pretending otherwise is how vendors lose credibility with operators. Build when one of these is true:
Your process is a real differentiator. If how you allocate, sequence, or prioritize freight is competitive advantage rather than table stakes, encoding it yourself is defensible. Rent the data layer, build the logic on top.
Your network is small and stable. Three carriers, two lanes, one mode, low change rate. The obligation is small enough to absorb, and a platform's breadth is capacity you will not use.
You have the team and it is funded permanently. Not a project team. A standing team with on-call, an owner who will still be there in three years, and budget that survives the next cost review. If the visibility layer depends on one engineer who knows how the mappings work, you do not have a build. You have a risk.
Sovereignty or regulatory constraints rule out external processing. Rarer than it gets claimed, but real in some defence and public-sector contexts.
When buying is the right answer
Buy when the visibility layer is infrastructure rather than advantage: many partners, multiple modes, a change rate you cannot staff against, and a team whose time is better spent resolving exceptions than maintaining feeds. Buy when you need a signal in weeks because the cost of blindness already shows up in your demurrage and expedite lines.
And buy when the alternative on the table is not really "build" but "replace." Ripping out a working ERP to get visibility is the most expensive version of this decision. Connecting the systems you have usually beats replacing them, and it gets you there faster.
Once buying is settled, the next document decides how useful the responses are. Writing the RFP from your own incident log rather than a feature template is what stops five vendors answering it the same way.
Five questions that settle it
Answer these in writing, with names attached:
- Who owns this system in three years? A person, not a team name. If you cannot answer, do not build.
- What is the annual run rate, not the project cost? Count engineering time for feed maintenance, on-call, warehouse spend, and the analyst hours currently spent reconciling numbers by hand.
- How many partners, and how often do their feeds change? Pull the last twelve months of integration incidents. That rate is your future, not your best case.
- What does a month of delay cost? Put a number on unseen demurrage, expedites, and missed cutoffs. It is usually larger than the build's monthly burn.
- Is the logic differentiating, or is the plumbing? Build the first. Rent the second.
If you are already past this and into vendor conversations, the criteria large enterprises actually use to choose supply chain software is the next question, not this one.
Where to start Monday
Do not start with a build-or-buy debate. Start with a count. List every partner feeding you shipment status, how you receive each one, who fixed it the last time it broke, and how you found out it was broken. That single table settles most of these arguments on its own, because it makes the maintenance obligation visible for the first time.
Then price the delay. A visibility layer that arrives in four weeks and one that arrives in four quarters are not the same product at different prices. They are different decisions about how many more months you are willing to hear it from the customer first. If buying looks likely, test it on the lanes that already hurt rather than the ones that behave: how to run a supply chain visibility pilot that proves something.
If the count comes back large and the delay comes back expensive, the answer is to rent the data layer and spend your engineers on the logic that is actually yours. That is the split Orkestra is built around: normalized partner data and exception detection underneath, your process on top, core systems left where they are. See how it connects the systems you already run, or book a demo and bring your partner list.
