Insurance Software Development: A Working Guide for European Insurers, MGAs, and Brokers

Insurance software development is the design and build of the systems an insurer, MGA, or broker actually runs on: policy administration, underwriting, claims, broker and customer portals, and the integrations that connect them to a market that still exchanges structured files. With a European dedicated team, a scoped first build (a portal, a claims intake, a data hub) typically costs €60,000–270,000 and reaches production in 3–9 months. Core-system replacement at a tier-1 carrier is a different project and a different budget entirely.

Most of what ranks for this topic was written for a different reader: US enterprise playbooks debating eight-figure core replacements, or feature lists with no numbers attached. A technology lead at a mid-market European insurer, an MGA, or a sizeable broker is weighing narrower questions — build versus buy, the honest cost, and what DORA and BiPRO do to the plan.

Who this guide is for (and who it is not for)

If you are a tier-1 carrier evaluating Guidewire against Duck Creek, you have consultants for that. This guide is for the layer below: regional and specialty insurers, MGAs building schemes, brokers who have outgrown spreadsheets and portals from 2012. Companies where a six-figure build is a serious decision, made by three people, one of whom will personally answer to BaFin or the local regulator if it goes wrong.

That layer is underserved by both worlds. Enterprise platforms price and implement for carriers ten times their size. Off-the-shelf tools cover the standard 80% of workflows and stop exactly where the interesting 20% begins, and the interesting 20% is usually why the company wins business at all.

Build, buy, or extend: the actual decision

The useful question is not "custom or off-the-shelf". It is: does this specific workflow win us business, or does it just need to work?

Workflows that just need to work (general ledger, billing, standard CRM) should be bought. Nobody chooses an insurer for its beautiful accounting. Workflows that win business deserve custom software: the underwriting rules a specialty team refined over fifteen years, the scheme logic an MGA negotiated with its capacity provider, the claims experience that renews a fleet customer, the broker portal that makes your products easier to sell than the competitor's.

The pattern we see most often in practice is the third column: keep the core system you have, even a dated one, and build the differentiating layer around it. Strangler-style modernization — new modules taking over one function at a time while the legacy core keeps running — costs less, de-risks the timeline, and delivers something usable every quarter instead of a big bang in year two. Each module is also a separately auditable, separately cancellable contract, which matters more than it used to; the regulation section below explains why.

When custom insurance software is the wrong call

We build custom software for a living, so read this list as against interest. Do not start a custom build if:

• The workflow you want to automate is not written down. If two claim handlers describe the process differently, software will freeze the disagreement. Run three workshops first; they cost days and save months.
• You need it live next quarter. Configured platforms deploy in weeks. A custom build that must ship in eight weeks will ship its corners cut, in code you now own.
• The volume is not there yet. An MGA processing forty claims a month does not need triage automation; it needs a shared inbox with discipline and a spreadsheet it trusts. Come back at four hundred.
• The differentiator is actually your people. If clients renew because your senior underwriter answers the phone, software that routes around her subtracts value. Build tools that give her better data instead.
• Nobody on your side owns the product. Custom software without an internal decision-maker becomes the vendor's product roadmap. That is a bad deal at any rate card.

If none of these apply, the economics favour building the differentiating layer, usually well before the point where stacked platform licences exceed the cost of owning your edge outright. And whoever you build it with, the questions that expose a weak vendor are the same in insurance as anywhere else.

What insurance software development costs with a European dedicated team

Published cost figures for insurance software run from "contact us" to seven figures, which helps nobody planning a budget. Here is our math instead, from the rates we publish: a senior European nearshore developer costs €3,500–7,000 per month on a dedicated-team model, typically 30–40% of what the same seniority costs in-house in Germany.

Three worked examples, bottom-up:

• Broker or customer portal MVP. Two or three developers plus a shared designer/QA, four months: €60,000–90,000. Quoting, document download, first-notice-of-loss submission. The BiPRO question decides a chunk of this budget; a portal German brokers will actually adopt speaks the market's norms, not a proprietary API.
• Claims intake and assisted triage. Four to five people, six to nine months: €150,000–270,000. Structured intake from mail, portal, and broker feeds; automatic coverage checks; a review queue for everything the system is not sure about. The review queue is not a compromise. It is the design, as the automation section argues.
• Policy administration modernization. Six to eight people, twelve months and beyond, shipped in slices: from €350,000. This is the honest number for taking over policy lifecycle functions incrementally around a legacy core. If a vendor quotes materially less for a full replacement, ask which half of your product catalogue they are planning to drop.

Compliance work — audit trails, access control, data residency, deletion concepts — is inside these ranges, not an add-on. In insurance it is the cost of building the thing correctly once. The full arithmetic behind these tiers, including running costs and the levers that move any quote, is in our custom software development cost guide.

The rules the US guides skip: DORA, GDPR, BiPRO

The top-ranking guides we analysed before writing this one cover American regulation in depth (state DOI variations, NAIC reporting) and treat European rules as one word in a compliance list, when they appear at all. For a European insurer the regulatory shape of a build is different, and two items change how you select a development partner in the first place.

DORA is about your vendors, including us. The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied to insurance undertakings since 17 January 2025, and its third-party provisions treat a software development partner as ICT risk to be managed contractually. Concretely: your ICT contracts belong in a register of information, and the contracts themselves need audit and access rights, incident-notification cooperation, transparency about subcontracting, and a documented exit strategy. Translated out of regulatory language: you need a partner whose delivery is inspectable — clean repositories you own from day one, documented decisions, reproducible environments — and whose departure would not strand you. When we wrote in our engineering handbook that we work as if we could be replaced tomorrow, we meant it as professional ethics. Under DORA it is also what your compliance team must demand in writing.

BiPRO decides whether German brokers use your software. The BiPRO norms standardize data exchange between insurers, brokers, and platforms in the German market: tariffing and offer processes, document transfer, deep links into portals. A broker integration that ignores them forces every broker house to build against your one-off API, which in practice means they will not. Legacy tape still matters too. Plenty of real-world data flows arrive as GDV-format files, and a claims or policy hub has to ingest them without ceremony. If your distribution is German brokers, BiPRO support belongs in the first architecture diagram, not in phase three.

GDPR you know, so only the two points that bite in insurance builds: health data inside claims files raises the bar to special-category processing, which constrains where models run and which cloud regions hold data; and data-subject deletion collides with retention duties on policy records, so the deletion concept has to be designed, not bolted on. Ask any vendor how they handle both before signing. If the answer is generic, so is their insurance experience.

Automation an auditor will accept

The seductive pitch in insurtech is straight-through everything: claims settled by a model in seconds, underwriting without underwriters. The version that survives contact with an audit — and with BaFin — is less cinematic and more useful.

We learned the shape of this pattern outside insurance, on a categorization platform we built for a US financial advisory firm. Their problem rhymes with claims handling: a steady stream of incoming transactions, each needing a category from the firm's own taxonomy, every decision traceable for audit, and errors that cost real money downstream. The design that worked was not "the model decides". The system proposes with a confidence score; whatever passes the confidence gate and the firm's validation rules flows straight through, and everything else lands in a reviewer queue where an analyst confirms, remaps, or splits the item. Every decision, human or machine, lands in an audit trail and feeds the next round of proposals. Throughput went up because people stopped touching the routine majority; defensibility went up because a person owns every hard call.

Map that onto claims: first notice of loss arrives from portal, mail, or broker feed; the system checks coverage, proposes a category and a reserve, and attaches its confidence; routine glass-damage claims flow through in minutes while the ambiguous liability case goes to a handler with all context prepared. The threshold is set per line of business and tuned openly. It is a business decision, visible in a config, not something buried in a model. When the auditor asks why claim 4711 was settled automatically, there is a specific, timestamped answer.

This is also our position on AI in insurance software generally, stated so you can disagree with it: models belong in the proposal seat, people in the decision seat, and the audit trail underneath both. Anything that processes client data through AI tooling runs under our written AI-usage policy — which client code and data may pass through which tool is governed by policy, not individual convenience. Regulated clients tend to ask about this in the first call; we would rather answer before being asked.

Starting insurance software development without replacing the core

The lowest-risk first step we know: pick one workflow that wins you business and still runs on attachments and goodwill — broker onboarding, FNOL intake, renewals for one product line — and scope a 3–4 month build around it. Small enough to cancel, real enough to prove the model.

A dedicated team assembles in 2–4 weeks and works module by module against a core nobody wants to touch in year one; that is the shape we steer insurtech work toward. If you want a second opinion on a build-versus-buy decision you are weighing right now, including the answer "buy, and here is why", talk to us and bring the workflow that currently lives in an inbox.

However that decision lands, DORA has settled an older argument in your favour: inspectable delivery, repositories you own, and a documented exit are no longer concessions a vendor grants. They are the entry ticket.