Specialty insurance
Buy the intake, build the judgement
A marine cargo underwriting team wanted to automate submission intake. Treated as one decision it was a stalemate; split into two, document handling and risk judgement, it answered itself.
Build versus buy answered per component, not per project.
Problem
Submissions arrive as broker emails with spreadsheets and PDFs in no fixed format. Underwriters spend a large share of the day re-keying values before they can price anything. Two vendors offered end-to-end “AI underwriting”; the team asked which to buy.
Context
A team of nine underwriters and two assistants, writing a specialised book where pricing judgement is the product.
Current architecture
Policy administration system of record, a shared mailbox, and a pricing spreadsheet maintained by a senior underwriter.
Constraints
- Time: the renewal season sets a hard date after which nothing can be changed.
- Skills: no in-house ML engineers; two strong developers.
- Data: fifteen years of bound risks, but pricing rationale lives in underwriters’ heads and notes.
Evidence
Each statement placed on the ladder before it was used.
Submission formats vary by broker; the same broker changes template between placements. Counted across one month of the shared mailbox.
Re-keying consumes a large fraction of underwriter time. Estimated by the team, not timed.
The pricing model is the differentiator and is not to leave the firm’s control in any form.
Document extraction is a commodity; pricing judgement is not.
Buying intake means accepting a vendor’s extraction accuracy and a per-document fee for the life of the system.
Questions that changed the answer
- Which part of this work would a competitor also be buying off the shelf?
- If the vendor doubled its price in year three, what would we do?
- What accuracy does extraction need before it saves time rather than creating review work?
- Can we export our own extracted data in a form we could re-import elsewhere?
Options
Including the one nobody wanted to discuss.
Buy end-to-end
One vendor handles intake, extraction and indicative pricing.
What it costs: Puts the firm’s only differentiator inside a product every competitor can also buy, and makes exit a rewrite.
Build end-to-end
Build extraction and pricing in-house.
What it costs: Spends the scarce developer capacity on document parsing (a solved commodity problem) and misses the renewal date.
Buy intake, build judgement
Vendor extraction writes into a firm-owned schema; the pricing layer is built in-house against that schema.
What it costs: Creates an integration boundary that must be owned, and the schema must be designed before either side is built.
Economics
Four horizons, not one estimate.
- Build
- Lower than a full build: the effort concentrates on the schema and the pricing layer, which is where the firm’s knowledge already is.
- Run
- A per-document vendor fee that scales with submissions, modelled at three volume levels including one nobody expected to reach.
- Change
- The deciding column. New trade lanes change pricing monthly; on the bought side that is a roadmap request, on the built side an afternoon.
- Exit
- Contained by design. Extraction is replaceable because the firm owns the schema it writes into; the pricing layer never leaves.
Decision
Buy document intake from a vendor. Build the pricing layer in-house against a schema the firm defines and owns.
Why
Build versus buy is not a project-level question. Extraction is a commodity with many suppliers; pricing judgement is the reason the firm exists. The only real design work was the boundary between them.
Why not the alternatives
- Buy end-to-end: It would rent out the differentiator and make exit cost equal to a rewrite.
- Build end-to-end: It would spend the only two developers on a commodity and still miss the renewal date.
Trade-offs accepted
- A vendor dependency on the commodity half, accepted deliberately and bounded by an owned schema.
- An integration boundary that needs a named owner, or it silently becomes the most complex part of the system.
Reversibility
Deliberately engineered to be low. Because the vendor writes into the firm’s schema rather than its own, swapping extraction suppliers is an adapter change, not a migration.
Complexity budget
One integration boundary earned its place because it is what makes the vendor replaceable. A message bus, proposed early, did not. There are two participants and one direction of flow.
Decision gate
GO on the hybrid, with the schema defined and agreed before either side of the boundary is built.
Implementation
Schema first, agreed with the underwriters in a fortnight. Vendor connector behind an adapter with a documented contract. Pricing layer built against the schema, never against the vendor’s payload.
What the decision was expected to achieve
Underwriters should re-key less per submission, and the pricing layer should be changeable in a day. It would be proven by time from submission arrival to first quote, and by the number of vendor payload fields referenced outside the adapter, which should be zero.
No outcome is claimed. This is an illustrative example, so there is nothing measured to report, and a real engagement would state what happened and how it was verified.
Lessons
- Ask build-versus-buy per component. At project level it is usually a stalemate; at component level it usually answers itself.
- Own the schema and the vendor becomes replaceable. Adopt theirs and you have signed a longer contract than you read.
- The boundary is the architecture. Everything else was procurement.