This is Part 10 of our series on the hidden cost of carrier connectivity. For the full lifecycle, see Anatomy of a Carrier Integration.
Nine posts in, the question is not whether carrier connectivity is hard. The series has been a long answer to that. The question is whether building it should be on your roadmap at all.
The honest answer depends on a small number of variables. The math is harder to dodge than it looks. And the part of the math that almost no in-house build plan carries is not the engineering — it is the category cost of work that turns out, in production, to be permanent.
The cost stack the build estimate doesn't carry
The visible cost of a carrier integration is the part a spreadsheet can hold. In our build-vs-partner modeling we see roughly $300K per integration to stand up — two engineers, sixteen hundred hours, fully loaded — and roughly $75K per integration per year to maintain. That maintenance number is recurring, not amortizing. It does not get smaller.
Multiply across a launch plan and the number starts to move. Six carriers across four lines of business is twenty-four integrations, not six. Twenty-four integrations is roughly seventy-six thousand engineering hours just to stand up — about three and a half calendar years with ten dedicated engineers, assuming the integrations parallelize cleanly, which they don't. The five-year build-and-maintain cash cost lands in the high eight figures before forgone revenue enters the picture. Once it does, the decision is structurally an eight-figure one.
That is the visible cost. The cost the spreadsheet misses is the cost of the categories of work this series has spent nine posts documenting. Each one is a permanent function.
The procurement layer runs on a six-to-twelve month critical path per carrier, and headcount does not compress it. The API-and-docs layer is twenty-four unrelated integrations, not one — different transports, different auth, different discovery surfaces, and contracts that are right often enough to be trusted and wrong often enough to ship customer-facing declines. The mapping layer — class codes, NAICS overlays, appetite tables — is not engineering. It is a permanent data-ops function with insurance domain knowledge attached. The UWQ layer is, in our experience, roughly ten times the size of what a carrier's API spec advertises, with graph-shaped dependencies and answers that can reshape the request itself. The silent-breakage layer runs at twenty to twenty-five percent of integrations every month, every month, forever. And underneath all of that is the testing and monitoring infrastructure that tells you, on any given Tuesday, whether the integration is actually working — because most carriers will not.
Six categories. Each one a beat in an earlier post. None of them is on the engineering line of a build estimate. All of them are real.
Two roadmaps, three years
Two engineering leaders signed off on carrier connectivity in the same fiscal year. One built in-house. One partnered.
Year one, the status reports were indistinguishable. Both teams demoed integrations. Both teams hit production with their first carrier. Both boards were happy.
Year two diverged. The in-house team was still shipping, but slower. Three engineers were now full-time on maintenance. Class-code dictionary drifts they had no advance notice of were eating sprints. Their UWQ team had grown to four. They had built their own canonical schema twice — the first one did not survive contact with the third carrier. They had decline-rate gradients running on two carriers and a backlog of work to roll it out on the rest.
The partner team had quietly added carriers in the background. Their engineering org had refocused on the agent-facing product their customers were paying them for.
Year three the gap is permanent. The in-house team has shipped nine of the twenty-four integrations they planned, and carrier maintenance is now a standing function they are actively recruiting for. The partner team is bound on all twenty-four plus four more the carrier rolled out mid-year on appetite, and has shipped a quoting product their competitors cannot match.
This is a composite. The trajectory is assembled from real customer arcs we have watched, no detail invented. One brokerage we now serve compressed the whole arc into eighteen months — a working sandbox integration to a single national WC carrier, ninety days of production decline patterns no one on their team could classify, then a migration to our platform. We had that carrier live in nine weeks. The codebase they had built in-house went to the codebase graveyard.
Year one looks similar. Year three is structurally different.
When build is the right answer
It sometimes is.
If your strategy is single-carrier, the multiplier on the cost stack disappears. A captive program, a single-carrier MGA, or an embedded product wrapped around one carrier can build to that carrier and live with the cost. Three hundred thousand dollars and seventy-five a year against one carrier is a tractable line item.
If you are the carrier, a vertically integrated player owning the underwriting needs no integration in the sense this series has used the word.
If your strategic differentiation lives in something the abstraction layer structurally cannot ship — a proprietary risk dataset, a captive program with proprietary forms, an underwriting model that needs end-to-end control of the submission — the integration is in service of a product no partner can deliver. Rare. Worth naming honestly when it shows up.
If you have an engineering capacity surplus large enough that your product roadmap genuinely does not need the headcount, you can absorb the work. We have not seen this often. We have seen it.
When build is the wrong answer
Everything else.
If you want more than two carriers, the per-integration cost multiplies and the silent-breakage tax compounds. If you want more than one line of business, the UWQ surface multiplies along with it — and the canonical-schema work is not amortized across carriers in any way that helps. If the integration is in service of a product, not the product itself, the math is structurally against you, because the engineering team you would be staffing is the same engineering team you need on the product. And if you do not have a standing carrier-relations function staffed independently of the integration engineers, the work that is supposed to be on the engineering line will quietly absorb half of theirs.
These conditions are not edge cases. They describe most of the brokerages, MGAs, networks, banks, and embedded platforms we have integrated with.
The thinnest layer wins
We closed Part 5 of this series on a single thesis: a carrier integration is only as strong as its thinnest layer. Auth, request transformation, transport and retry, response normalization, audit. Five layers, every one of them load-bearing. The integration that ships is the integration whose weakest layer survives production.
The build-vs-buy decision is, in effect, the same thesis at a different scale. Do you want your engineering team building all five layers against twenty-four carriers — with each layer requiring continuous investment, each carrier shipping silent changes against it, each layer's weakest link defining the integration's behavior on any given day — or do you want a partner whose entire product is those five layers, across thirty-plus carriers, with the silent-breakage tax already absorbed?
The answer to the math is the answer to that question.
The series in one sentence
A carrier integration is not an engineering project. It is the permanent operational discipline of running an engineering project that never finishes. Across thirty-plus carriers, sixty-plus live integrations, and ten posts of receipts, we have shown what that discipline looks like.
If you've read all ten of these and you are still sure you want to build this in-house, we will respect that — there are companies for whom it is the right call, and we have named the conditions where it is. If you'd rather keep your team focused on the product your customers are actually paying you for, that is the work CoverForce takes on. One integration into the abstraction layer, sixty-plus live across thirty-plus carriers, and the procurement, mapping, UWQ, silent-breakage, and monitoring functions become ours — not yours.
.png&w=1920&q=75)
