Most of this you should build yourself
A decision framework from a firm that loses work when you apply it honestly. Three parts of this series described failures. This one is about who should fix them.
Build-or-outsource conversations reliably start from the wrong question. The wrong question is whether you have engineers free this quarter. That is a scheduling problem, and answering it with an outside firm produces exactly what you would expect: a system that works on the day it ships and belongs to nobody eighteen months later.
The right question is which systems have to compound inside your company. Some of what breaks in a 3PL is the thing your customers actually pay you for, and it needs to live on your payroll forever. Some of it is plumbing that should be built once, correctly, and then stop being interesting. And some of it is a hazard — a thing that will fail on the Monday before Thanksgiving and turn into freight that does not move.
Those three categories take three different answers, and mixing them up is how firms like mine get hired for work that should never have left the building.
Differentiator, commodity, hazard
Differentiator. Your rating and margin logic. Your exception playbook — what your operation does when the appointment is missed, the pallet is damaged, the carrier rejects the tender. The promise you make to a customer and how you price it. These encode the judgment your business is sold on, they change constantly, and every change is a commercial decision wearing a technical costume. Build them, own them, keep the people who understand them. If you outsource the thing your customers pay you for, in three years you will own a vendor relationship instead of a business.
Commodity. X12 envelope handling and control-number management. GS1-128 label generation. PDF invoice extraction. VAN and AS2 plumbing. Retry queues. None of this is a differentiator for anyone — your competitors have the same 856 spec you do. Buy it, or have it built once by someone who has done it before and hand it over finished. The test is whether a competitor could copy it and gain nothing. If so, it should be the cheapest line in your budget, not the one your best engineer is maintaining.
Hazard. The carrier adapter layer at peak. The database under the pick list. The 856 pipeline into a retail account with a routing guide and a deduction schedule. These are not differentiators — a customer will never praise you for them — but the cost of being wrong is a physical event. Hazards are where outside help usually earns its price, because the value is not the code, it is having already seen the failure.
Most of the argument in a build-or-outsource meeting is people from different departments each correctly describing a different category and assuming they are describing the same system.
Four questions, answered honestly
Will this system still be changing in eighteen months?
If yes, permanent knowledge beats borrowed knowledge, every time. Anything that changes weekly needs an owner who is in the standups, hears the customer complaint, and remembers why the exception exists. If no — a migration, a partitioning exercise, an accelerator, a one-time rebuild — the experience is worth more than the hours, and it is not worth acquiring permanently.
Does it encode a decision your customers pay you for?
Ask whose judgment is in the code. If the answer is your operations director’s, build it. If the answer is “the standard says so,” it is commodity and you are paying a premium to hand-roll a solved problem.
If it fails at 2am on the Monday before Thanksgiving, who picks up?
If the honest answer is the CTO, you do not have a build-or-outsource question yet — you have an operating-model gap, and it will swallow whatever you decide next. That was the position at the 3PL hub in C09: night incidents closed personally by the CTO after a phone call, 45 to 90 minutes to respond, no SLOs, no runbooks, no incident process. The organization was paying its most expensive person for the absence of an operating model. Fixing the model — SLOs per integration, tiered on-call, forty-plus runbooks — took P1 MTTR to 11 minutes and closed 100% of night and weekend incidents without the client involved (C09). Notice that the fix was a process with software underneath it, not a headcount decision in either direction.
Has anyone in the room done this exact thing before?
Not “do we know this language.” Has anyone here migrated a multi-billion-row table with no downtime, or run a retail EDI onboarding against a live deduction schedule, or rebuilt a carrier layer after one carrier's API change took rating down for three weeks? If yes, build it — you will do it better than any outsider because you also know your business. If no, the first attempt is where the tuition gets paid, and the only real choice is whose budget pays it.
Where “build it yourself” is plainly the right answer
I would rather say this on a public page than in month two of an engagement.
Your integration surface is small and stable. One EDI trading partner on a map that has not changed in two years, two carriers, no new retail account coming. That is maintenance. Do not buy an audit to confirm it.
Your volume never crosses the point where the plan changes. The pathologies in part three of this series are volume-triggered. If your largest table is not growing by an order of magnitude and peak is barely distinguishable from a normal Tuesday, tuning beats re-architecting — and tuning is something your own team can learn once and keep.
The leak is process, not code. There is a clean test for this, and it is the same one I gave in part one. If the same three people fix the problem every time, if the fix is a policy nobody enforces, if the leak survives a code change — you have a process problem, and an engineering firm will faithfully build you an expensive monument to it.
You already have the pattern and just need it applied again. At the express operator in C04, we standardized courier integrations behind one internal interface and connected three partners. The client connected the fourth themselves, using the same pattern (C04). That is the correct end state of any integration work — the second one is yours.
The failure mode of outsourcing, named
Outside engagements fail in a specific way, and it is not the way procurement worries about. They fail by shipping something that works and leaving nothing behind that lets you change it.
The exit criterion has to be written at the start, not at the end. Runbooks, architectural decision records, a codebase walkthrough with your own engineers holding the keyboard, and a named person on your side who owns each system on the day the engagement closes. If a proposal does not describe the handover, the handover is not going to happen — and the second year of that arrangement costs more than the first.
Ramp is the other half of the bill. A firm that has to learn what an ASN is, that carriers throttle, that peak season exists, that a rate table has a version history, learns it on your budget and inside your window. This is the one place where a vertical specialist has an argument that is not marketing: not that we are better engineers, but that we are not starting from zero on the domain. Large integrators often need months of ramp; most of it is domain, not code.
What we do not have, stated plainly. No SOC 2 and no ISO 27001. No WMS or TMS vendor partnership to display. If your procurement gate requires a certification, we will not clear it, and you should know that now rather than in week six. Before you commit to anything, our CTO will take any case on this site apart with you.
How to price the decision before you make it
The cheapest version of this decision is to buy the inventory rather than the opinion. You cannot sequence build-or-outsource across ten systems until you know which of them are differentiators, which are commodities, which are hazards, and what each one currently costs you per month.
That is what our two-week diagnostic is: $7,500, fixed scope, and the findings document is yours whether or not we ever work together. Ranked failure list, dollar cost per item, the evidence underneath each one.
There is precedent for the audit paying for itself before the engagement starts. The mid-market 3PL in C10 had spent eight months on AI with nothing in production and $42,500 a month running in LLM API costs, including calls firing from staging into integrations nobody used. The audit turned those off in week one — $14,000 saved immediately — dropped two vendors whose “AI features” turned out to be regex under technical verification, and took monthly spend to $16,000, down 62%, with no working initiative lost (C10).
Three doors open at the end of the two weeks. Continue with us. Act on the document with your own team. Or do nothing, because the ranked list says the top item is worth less than the fix. The third door is normal: that conclusion is part of the product, not a failed sale — and it is the only version of this offer that is worth buying.
Buy the inventory before you buy the opinion
Two weeks, $7,500, fixed scope. Every failure ranked by what it costs you, with the evidence, and the document is yours to act on with us, with someone else, or with your own team.