Every brokerage, wholesaler, MGA, bank, and insurtech eventually asks the same question: should we build this ourselves?

It sounds like an engineering question. It isn't. It's a commitment question. And almost every organization that asks it is working from an incomplete map.

We've built more than sixty carrier integrations across thirty-plus carriers. Along the way we've learned something that isn't obvious from the outside: a carrier integration is not a project you ship once. It's an operational discipline you commit to indefinitely. The code is the smallest part.

This is the first post in a ten-part series on the hidden cost of carrier connectivity. Think of it as the map. Every post that follows is a deep dive into one region of that map.

Why we're the ones drawing this map

We've built more than sixty carrier integrations across thirty-plus carriers. Travelers, Liberty Mutual, Chubb, AmTrust, CNA, Nationwide, Employers, Guard, Pie, Coterie, Hiscox, Coalition, and most of the rest of the admitted and surplus market. Six lines of business: Workers' Comp, BOP, General Liability, Cyber, MPL, and Property. The full carrier list, by line and state, lives in our appetite guide.

Our platform powers ISU, AmWins, One80/PMC, Jencap, Bridge Specialty Group, Normandy, and many more.

We ship five to ten new integrations every quarter. Our team can take a new carrier from first technical call to production in eight to ten weeks. The industry average for a single direct carrier integration, from what peer teams tell us, is closer to nine months.

More than one carrier has told us, unprompted, that we were the fastest integration they'd ever worked with.

We say all of that not as a credential check, but because everything that follows in this series comes from scars. We've made most of the mistakes the series is about to describe. The map we're drawing is the one we wish someone had drawn for us four years ago.

The map

A carrier integration, end to end, is seven stages. Only three of them look like engineering.

1. Legal and business case. Data-sharing agreements, PII handling, and aligning on the business case with the carrier. Often the first thing to stall, and the last thing anyone plans for.
2. Technical kickoff. Finding the actual engineers on the carrier side, getting documentation, getting credentials for the sandbox and a test agency, agreeing on how both teams will communicate for the next two months.
3. Capability mapping. Which of the seven capabilities does this carrier's API actually support — bindable quote, quote proposal, bind, payment plans, policy documents, appetite, underwriting questions? Almost no carrier supports all seven. The gaps are the work.
4. Build. Mapping the carrier's data model to a canonical model, handling authentication quirks, implementing retry and idempotency, building the error taxonomy, writing the audit log that has to be replayable for years.
5. Carrier testing. Running the carrier's test cases. Re-running them when sandbox and production diverge — which they will.
6. Rollout. Staged launch: internal dogfood, pilot agencies, then broader release, with per-carrier monitoring that surfaces what testing missed.
7. Monthly maintenance. Appetite revisions, class-code changes, underwriting-question drift, API version upgrades, new functionality. Forever.

Most internal estimates describe stages three through five. That's where teams imagine the work lives. In our experience, stages one and seven are where the calendar actually disappears — regardless of whether the company doing the build is a brokerage, a wholesaler, or an insurtech.

The part the carrier team rarely sees

Here is the central insight we've earned by doing this sixty-plus times:

The team that built the carrier's API rarely experiences the real integration burden.

They wrote a spec. They implemented it. They tested it against their own internal callers. They didn't translate their class codes into someone else's canonical schema while that schema also had to work for twenty-nine other carriers. They didn't maintain a conditional underwriting-question engine that renders the right questions for the right applicant to the right carrier — versions of which will change without notice. They didn't reconcile a bind confirmation against a payment captured two systems away.

Every one of those problems is real. Every one of them is where the time goes. And every one of them is invisible from the side of the table that wrote the API. That asymmetry is the source of most of the misaligned expectations in this work.

The tax you pay every month

The other thing missing from most build estimates is maintenance.

Carriers ship appetite changes. They revise class codes. They add required underwriting questions. They deprecate API versions. They fix a bug in production that quietly changes the shape of a response. None of this arrives with a changelog you can subscribe to.

Across our integrations, something changes on the carrier side roughly every week. It's on the integrator to detect, reconcile, and either absorb transparently or surface to the customer — before an agent finds out the wrong way.

If your organization builds this in-house, every hour your engineers spend here is an hour they are not spending on the product your customers are actually paying you for. That opportunity cost compounds — whether you're a brokerage, a wholesaler, or an insurtech building a differentiated experience on top of carrier rails.

What the rest of the series covers

Every post from here is a deep dive into one piece of this map.

• Part 2 — Before the first line of code. Discovery, identifying technical POCs, spinning up a test agency, and getting access to the carrier's developer environment.
• Part 3 — Reading the menu. How to assess a carrier API before committing to build against it.
• Part 4 — The translation problem. Data normalization: class codes, legal entities, payroll, losses, limits.
• Part 5 — The integration stack. Authentication, transformation, retry, normalization, audit — layer by layer.
• Part 6 — The 500-question iceberg. Underwriting questions: the single most underestimated piece of a carrier integration, and the one that reshapes the application as you answer it.
• Part 7 — Testing carrier integrations. Why sandbox isn't enough, and what replaces it.
• Part 8 — Beyond quote. Bind, payment, and document retrieval — where integrations quietly fall apart.
• Part 9 — The silent-breakage tax. Why every carrier integration decays without notice — class codes, underwriting questions, and appetite all change without a changelog — and what it costs to keep one alive.
• Part 10 — Build vs. buy. The honest decision framework, once the full picture is on the table.

If you're evaluating the build

Over the next few months we'll go deep on each of these. If your company is evaluating whether to build carrier connectivity in-house — brokerage, wholesaler, MGA, bank, or insurtech — start here. It's the cheapest place to change your mind.

We've been down this road more than fifty times. We'd rather you make the decision with a clear map than a clean slate.

‍