A mid-sized Los Angeles-based specialty carrier we talked to was paying $1.2M/year in software licensing across three platforms, a policy admin system from the early 2010s, a bolt-on claims module from a different vendor, and a broker portal that was essentially a PDF upload form wearing a web interface. Renewals were handled by email. Underwriting decisions lived in spreadsheets on seven different laptops. When the founder asked for last quarter’s loss ratio by product line, the answer took eleven days.
This is what insurance software looks like at most carriers, MGAs, and brokerages that have been around more than five years. Not broken, exactly. Just slow, disconnected, and expensive, with a compounding tax on every new regulation, product line, or distribution partner.
This guide is for the people buying the next version of that: carriers, brokers, MGAs, and InsurTech founders who need software that fits how insurance actually works. We cover what insurance software development companies build, how to evaluate build-versus-buy against Guidewire, Duck Creek, and Salesforce Insurance Cloud, what compliance you cannot skip, and what makes insurance projects fail, because most of them do.
What Insurance Software Development Actually Covers
Insurance is not one product. It is a bundle of workflows that differ by line (P&C, life, health, commercial), by role (carrier, MGA, broker, TPA), and by regulator (NAIC model laws, 50 state DOIs, HIPAA, GLBA). “Insurance software” usually means one or more of these systems:
Policy administration. The core system of record, quote, bind, issue, endorse, renew, cancel. Everything else hangs off of this. Legacy PAS platforms from the early 2000s are still running at major carriers; replacing them is the single most expensive project a carrier can undertake.
Claims processing software. First notice of loss (FNOL), adjuster workflow, reserves, payments, subrogation, fraud flags, reporting to the bureau. A good claims system touches accounting, document management, and usually a customer self-service portal.
Underwriting automation. Rules engines, third-party data pulls (MVR, credit, CLUE, ISO), rating tables, referral thresholds. Most carriers want straight-through processing for small and mid-market business and underwriter workbench tooling for anything larger.
Agency management systems. For brokers and MGAs: producer licensing, commission tracking, download from carrier partners (IVANS, ACORD feeds), e-signature, client-facing portals, renewal pipelines. AMS360, Applied Epic, and HawkSoft dominate this space, but they are rental platforms, you do not own your data model.
Insurance CRM development. Policyholder view, household view, cross-sell workflows, marketing automation, retention scoring. Most carriers end up with Salesforce-based CRMs that they extend far enough to be effectively custom anyway.
Customer self-service portals. Document retrieval, COI generation, payments, policy changes, FNOL intake. This is where most modernization starts because it is customer-facing and measurable, NPS moves in weeks.
Reporting, regulatory filing, and analytics. Statutory filings, rate filings (SERFF), loss ratio analysis, reserve reporting, combined ratio dashboards. The NAIC maintains the model laws most states adopt, your software has to keep up.
The question is rarely “do we need insurance software”, everyone does. The question is which of these systems you buy off-the-shelf, which you extend, and which you build. That is where most of the budget decisions happen.
Build, Buy, or Extend: The Three Real Options
Insurance buyers get pitched two extremes. Vendors like Guidewire, Duck Creek, and Majesco sell turnkey suites. Consultancies sell full custom rebuilds. Both are usually wrong for your situation.
Here is how to think about it honestly.
Buy the suite (Guidewire / Duck Creek / Majesco / Insurity). Right when you are a medium or large carrier writing multiple lines, you are willing to conform your processes to the vendor’s data model, and you have the budget, Guidewire implementations routinely run $20M–$100M over 3–5 years for a Tier 2 carrier. You get a known, regulator-familiar platform and a big partner ecosystem. You lose differentiation: your competitors run the same platform, and customization is expensive and brittle.
Buy Salesforce Insurance Cloud / Financial Services Cloud. Right when your center of gravity is distribution and relationships, agents, brokers, producer management, service, and less about policy admin itself. It gets you to a working CRM fast. It becomes expensive once you try to make it do real policy administration, which it was not built for.
Buy an AMS (Applied Epic, AMS360, HawkSoft, EZLynx). Right for agencies and small MGAs. Wrong the moment you have a proprietary product, a non-standard commission structure, or need portals and workflows the vendor does not offer. You will outgrow it and end up exporting CSVs.
Extend what you have. Right when the core system works but specific workflows are the bottleneck, usually customer portals, producer portals, claims intake, or reporting. You keep the system of record and build modern interfaces on top through APIs. This is the most common correct answer.
Build custom. Right when the software IS the business. InsurTech startups disrupting a line. MGAs with a unique underwriting model that no platform supports natively. Specialty carriers whose product is too niche for the vendor templates. Digital-first brokerages whose growth depends on a customer experience the AMS cannot produce. This is also where LCGC spends most of our insurance work.
The real decision is rarely binary. Most projects we do in insurance are extend-plus-build: a custom layer (portal, workflow, analytics, integration) that sits on top of a legacy PAS or AMS, speaks to it through APIs, and gives the carrier the features their vendor cannot ship for another three years. You get modernization without the $40M rip-and-replace.
For the deeper version of this trade-off, we wrote a longer piece on custom software vs. off-the-shelf, the economics apply directly here.
Common Insurance Software Projects
Here is what carriers, brokers, MGAs, and InsurTech founders actually hire us to build. Numbers are typical ranges for well-scoped work, every project gets a fixed bid after discovery.
| Project | Who it is for | Typical scope | Timeline | Ballpark |
|---|---|---|---|---|
| Policyholder self-service portal | Carriers, MGAs | Document access, payments, COI generation, endorsements, FNOL intake | 10–16 weeks | $80k–$160k |
| Producer/broker portal | Carriers, wholesalers | Quote retrieval, commission statements, policy downloads, submission tracking | 10–14 weeks | $75k–$140k |
| Claims intake + triage | Carriers, TPAs | FNOL form, photo uploads, triage routing, SMS/email updates, adjuster handoff | 8–14 weeks | $70k–$130k |
| Underwriting workbench | Commercial carriers, MGAs | Submission intake, third-party data pulls, rules engine, referral workflow | 14–24 weeks | $150k–$320k |
| Agency management for a specialty book | MGAs, wholesalers | Policy records, commissions, producer licensing, renewal pipeline | 16–24 weeks | $160k–$280k |
| InsurTech MVP (direct-to-consumer) | Seed/Series A startups | Quote-bind-issue flow, Stripe billing, Sure or Boost carrier API integration, onboarding | 12–20 weeks | $120k–$250k |
| Legacy PAS integration layer | Carriers with 10+ year-old systems | REST/GraphQL APIs on top of AS/400 or mainframe, data normalization, event streaming | 12–20 weeks | $130k–$240k |
| Regulatory reporting + SERFF automation | Carriers, MGAs | Statutory data extraction, filing prep, rate filings workflow | 8–12 weeks | $60k–$120k |
The projects that blow budgets in insurance almost always try to replace the core PAS. Projects that deliver on time and on budget almost always sit alongside it, integrate through APIs, and own a specific workflow end-to-end. Scope discipline matters more here than in any other industry we work in.
Compliance Is Not a Phase, It Is a Foundation
Insurance software has a compliance floor you cannot skip or bolt on after launch. If your development partner treats compliance as a QA checklist at the end, find another partner.
NAIC model laws and state DOI rules. The NAIC publishes model laws on data security, privacy, market conduct, claims handling, unfair trade practices. Most states adopt them with variations. The NAIC Insurance Data Security Model Law (adopted in some form by over 25 states) requires a written information security program, incident response, vendor oversight, and annual board reporting for licensed entities. Your software has to generate the audit trails this program needs.
GLBA (Gramm-Leach-Bliley Act). Applies to financial institutions including insurance. Nonpublic personal information (NPI) must be protected in transit and at rest. You owe customers a privacy notice and the right to opt out of certain information sharing. Audit logs of who accessed what records are not optional.
HIPAA (for health, dental, vision, and some disability/LTC products). If you touch protected health information, HIPAA applies end-to-end: encryption, access controls, business associate agreements with every vendor, breach notification in 60 days. Most general insurance software firms understate what HIPAA actually requires.
State privacy laws (CCPA/CPRA, Colorado, Virginia, etc.). Consumer rights to access, delete, and correct data. Opt-out of sale/sharing. These overlap with GLBA exemptions in tricky ways, your engineers need to know which applies to which data class.
SOC 2 Type II. Not a regulatory requirement, but carriers and reinsurers will ask for it before they integrate with you. If you are an InsurTech startup or MGA platform, plan for this from day one. The controls are easier to build in than to retrofit.
Statutory filings and SERFF. Rate filings, form filings, annual statements. Your software either produces these or feeds the system that does. Getting the data model right the first time is the difference between a 2-week filing and a 2-month filing.
E-signature and e-delivery (UETA, ESIGN). Policy documents, endorsements, disclosures. The compliance here is boring and well-understood, but skipping it leaves policies unenforceable. Use DocuSign, Adobe Sign, or a self-hosted UETA-compliant flow, do not invent one.
Good [custom software development]/services/custom-software-development/) in insurance means building the compliance controls in the data model, not in a spreadsheet a compliance officer updates quarterly. Access logging, field-level encryption for NPI, retention policies, audit trails, these get designed in week one, not week twenty.
Integrating with Legacy Carrier Systems
Most insurance modernization projects fail at the integration layer, not the UI. The legacy PAS, the claims system, the general ledger, the data warehouse, they were built in different decades, by different vendors, with different assumptions about what a policy, a claim, or a loss was. Your new portal has to talk to all of them, and it has to handle what happens when one of them is down.
The patterns that work:
An API gateway in front of the legacy. Even when the core system is a mainframe or an AS/400 application from 1998, we can usually stand up a REST or GraphQL gateway that reads from its database or message queue and normalizes the data. The legacy keeps running. The new application talks to modern APIs. This is an [API integration]/services/system-integration/) problem first and a UI problem second.
Event streaming for reconciliation. Policies, endorsements, and payments happen in the PAS. Everything else, portals, analytics, CRM, needs to react. A Kafka or Kinesis event stream with replay capability means your downstream systems can recover from outages without manual reconciliation scripts.
Read/write boundaries. New systems should mostly read from the legacy and write to their own data store, with a carefully-scoped writeback path for the fields the legacy owns. This is how you avoid the double-entry problem and the “which system is right” problem that kills data quality.
ACORD forms as the integration contract. The ACORD standards (AL3, XML, JSON) are the lingua franca for policy, claims, and download data between carriers, agencies, and bureaus. If your integration speaks ACORD, you can talk to almost any carrier partner. If it speaks only your own schema, you are stuck.
Real-time data pulls with graceful degradation. MVR, CLUE, credit, ISO, LexisNexis, these third-party services fail. Your underwriting flow has to handle a 30-second MVR timeout without breaking the submission. Build retries, circuit breakers, and fallback workflows from the start.
This is why [legacy modernization]/services/legacy-modernization/) in insurance is rarely “replace the mainframe.” It is usually “put a modern API layer on top, move specific workflows off the mainframe one at a time, and eventually the mainframe runs less and less.” The strangler fig pattern was almost invented for insurance.
Why Insurance Software Projects Fail
We have been on enough rescues to see the patterns. Projects fail for the same reasons, regardless of the vendor or the budget.
Scope defined in terms of features, not workflows. The RFP says “claims system with 147 features.” The real question is “what does an adjuster’s first hour of the day look like, and what are they clicking through to get it done.” If the requirements doc never answers that, the software will not either.
No one on the team has written production insurance code. Insurance has domain quirks that cost six months to re-learn: effective dates vs. transaction dates, policy versioning, proration, cancellation reasons that drive different downstream behavior, state-specific forms, retroactive endorsements. Generalist developers always underestimate this. Ask your partner for specific prior insurance work.
Compliance deferred to “phase 2.” Audit logs, encryption, role-based access, retention policies. If these are not in the first release, the retrofit costs more than the original build. We have seen companies spend $300k retrofitting what would have been $40k designed in.
Integration underestimated. The team budgeted 15% of effort for “integrate with the PAS.” It takes 45%. Legacy systems are not documented, vendors charge for API access, ACORD mappings have edge cases, and test data is impossible to get. Assume integration is the hard part. Budget accordingly.
Too much at once. A single project trying to replace the PAS, the AMS, the claims system, and the portal. Three years in, nothing is live. Break it apart: one workflow, one system, one user group at a time. Ship in 12-week increments.
No carrier/regulator in the room. For MGAs building on a fronting carrier, for brokers building on AMS downloads, for InsurTechs building on a capacity provider, the external party has approval rights you did not budget for. Loop them in at week one, not month six.
Vendor lock-in designed in. Teams default to the SaaS plugin ecosystem (Salesforce managed packages, Guidewire PolicyCenter extensions) and end up unable to move. Every major feature gets priced at enterprise-tier rates. Build on portable standards (REST, ACORD, SQL) where you can. See custom software vs. off-the-shelf for the longer version of this argument.
Most of these are process problems, not technology problems. They are the same failure modes we see in [SaaS development]/services/saas-development/) and other regulated industries, insurance just has bigger consequences because the paper policy is a contract and the regulator is a state.
What Insurance Software Costs
A real number conversation. For reference:
A Guidewire InsuranceSuite implementation at a Tier 2 US carrier: $20M–$80M, 3–5 years. Sometimes more. This is a license + implementation + integration + change management number, not just software. Gartner’s InsurTech research tracks these projects, and the cost curve has not bent downward in a decade.
Salesforce Insurance Cloud + Financial Services Cloud: $200k–$2M for initial implementation, $150–$500/user/month ongoing, plus customization and managed packages. Makes sense for distribution-heavy operations.
A modern AMS (Applied Epic, AMS360): $75–$150/user/month plus setup. Works for most agencies. Breaks down the moment you have non-standard commissions, proprietary products, or custom portals.
A custom policyholder portal built on top of a legacy PAS: $80k–$160k, 10–16 weeks. Owned outright, maintained by whoever you want, no per-user licensing.
A custom underwriting workbench for a commercial MGA: $150k–$320k, 14–24 weeks. Same ownership model.
An InsurTech MVP (quote-bind-issue for a single product, direct-to-consumer): $120k–$250k, 12–20 weeks. Enough to go live with a carrier partner, collect real data, and raise the next round.
Custom software is an asset on the balance sheet. Licensed software is an expense line that compounds. At year 3–5, the custom build is almost always cheaper than the SaaS equivalent, and that is before accounting for the strategic value of owning the data model and not paying a vendor to ship your next feature. McKinsey’s published work on insurance technology costs lines up with this pattern.
The right question is not “what does custom cost”, it is “what is our 5-year total cost of ownership under each option, and which option lets us ship the customer experience we actually want.”
Why LCGC Builds Insurance Software Out of Los Angeles
Los Angeles is an insurance town, specialty carriers, entertainment insurers, commercial brokers serving the aerospace, logistics, healthcare, and real estate sectors across the western US. LCGC is based here. We work with LA-based carriers, brokerages, and InsurTech founders directly, in the same time zone, with senior engineers who have shipped production insurance software, not offshore handoffs or junior developers billed at senior rates.
What you get when you work with [our team]/about/):
- Senior engineers who have built policy admin APIs, claims workflows, underwriting engines, and carrier integrations before. No re-learning the domain on your budget.
- Fixed-scope engagements with milestone deliverables. You see working software before approving the next phase.
- Full IP transfer on completion. You own the code, the data model, the documentation. No licensing, no lock-in.
- Compliance designed in, not bolted on. Encryption, audit logs, role-based access, retention, and SOC 2-ready controls from day one.
- Integration-first architecture. If you have a legacy PAS, an AMS, a GL system, or a carrier partner, we design the integration before we design the UI.
- Cloud-native deployments on AWS, GCP, or Azure depending on your existing infrastructure and compliance posture. See our [cloud solutions]/services/cloud-solutions/) approach.
We cover the whole stack insurance buyers need: [custom software development]/services/custom-software-development/) for the system of record, [SaaS development]/services/saas-development/) for InsurTech platforms, [legacy modernization]/services/legacy-modernization/) for carriers running on AS/400 and mainframe, [system integration]/services/system-integration/) for connecting PAS, AMS, claims, and analytics, and [cloud solutions]/services/cloud-solutions/) for the infrastructure under all of it.
What To Do Next
If you are a carrier, MGA, broker, or InsurTech founder evaluating insurance software development companies, the first useful step is not picking a vendor; it is writing down what you actually need, in workflow terms, not feature lists.
Pick the single workflow that is costing you the most (customer complaints, staff time, regulator pain, missed renewals, lost submissions). Map what happens today, every click, every email, every spreadsheet, every phone call. Then ask: what would this workflow look like if the software actually fit it.
That is the scope document. The software gets built against that, not against a 200-line RFP.
If you want a second opinion on whether custom, extend, or buy is the right answer for your situation, [schedule a free 30-minute call]/book/) and bring the workflow you are thinking about. We will tell you honestly what we would do, including when buying a suite or sticking with your AMS is the better call. Not every insurance problem needs custom software. The ones that do usually know it, and the ones that do not usually get oversold by a vendor.
Insurance is a slow industry that punishes sloppy software. Get the scope right, the compliance right, and the integration right, and you end up with an asset that compounds. Get those wrong and you end up with another $1.2M/year line item you cannot get out of.