What an insurance app really costs, and what actually drives the number

Ask what an insurance app costs and most published answers give a range so wide it is useless, because they price the screens and ignore the machine behind them. An insurance app is a thin face on deep plumbing: every quote it shows calls a rating engine, every policy it displays queries a versioned contract ledger, every claim it opens writes into a claims system with its own workflow. The plumbing determines the price.

This guide prices the build honestly: the scope tiers that actually describe insurance apps, the integration tax that separates cheap projects from expensive ones, the team behind the numbers, the recurring costs that continue after launch, and the specific mistakes that double budgets. The figures are planning ranges from real projects, not quotes; your core systems can move any of them.

If you have not yet mapped the systems this app must talk to, read the insurance software guide first: it explains the policy administration, claims and billing cores that every cost paragraph below assumes. For the contract ledger specifically, policy administration systems explained goes deeper.

Why published cost ranges mislead

The generic app cost article prices features: login costs this, push notifications cost that, sum the list and add a margin. Insurance breaks that arithmetic because the visible feature is rarely where the work is. A policy details screen is an afternoon of UI, but behind it sits the question of which policy version to show, how endorsements display, what a mid-term cancellation looks like, and whether the core system can even answer those queries through an API. The screen is priced in hours; the plumbing is priced in weeks.

The second distortion is that insurance apps are never greenfield. A consumer startup builds its own backend and controls every interface. An insurance app is born into a carrier's existing estate: a policy core of some age, a claims system, a billing system, an authentication regime, and a compliance function with opinions. The app project inherits the estate's condition, which is why two carriers with identical feature lists receive honestly different quotes, and why any fixed price offered before an integration audit is a guess wearing a suit.

The third distortion is survivor bias in public numbers. Agencies publish their smoothest projects; the app that spent four months wrapping a mainframe before the first screen shipped does not become a case study. Planning ranges should include the unglamorous middle of the distribution, which is what the tiers in this guide try to do.

None of this makes cost unknowable. It makes cost conditional, and the conditions are auditable in advance: what the core systems expose, how products are modeled, what compliance requires, and how much of the lifecycle the app should own. A one-to-two-week technical discovery against those questions turns the range from folklore into an estimate, and it is the single highest-leverage spend in the whole project.

The three scope tiers, with ranges

The claims-intake tier is the smallest serious insurance app: report a loss, photograph the damage, submit documents, track status. It touches one core system in a controlled way, first notice of loss is a write with a well-understood shape, and it delivers measurable value fast because claims contact is the moment customers actually care about their insurer. Expect 60,000 to 120,000 dollars for a well-built version against reasonable APIs, on a three-to-four-month schedule.

The quote-and-buy tier sells one product end to end: risk questions, a live rated premium, payment, and policy issuance, with the policy then visible in the app. This tier crosses the full width of the stack, rating engine, underwriting rules, policy issuance, billing, payments, and its cost is dominated by how those systems expose themselves. Expect 120,000 to 250,000 dollars for one product line, four to seven months, with the range position set almost entirely by core API quality.

The full self-service tier is the carrier app customers imagine: multiple products quoted and bought, policies viewed and endorsed, documents downloaded, claims opened and tracked, payments managed, renewals handled. Every core system is engaged in both directions, and product-line breadth multiplies the surface: each line brings its own questions, rules, documents and endorsement types. Expect 250,000 to 400,000 dollars and beyond, seven to twelve months to a first full release, and a roadmap rather than an end date.

Two cross-cutting adjustments apply to every tier. Regulated-industry overhead, security review, data protection compliance, audit trails, penetration testing, adds 10 to 20 percent over an equivalent consumer app and should be a visible line, not a surprise. And the legacy adjustment dominates everything: if the core needs an API wrapper built before the app can talk to it, the wrapper is its own workstream, typically 30,000 to 100,000 dollars depending on the core's condition, and pretending it is part of the app budget is how projects earn their overrun.

The tiers, priced

Tier	What it owns	Range (USD)	Schedule
Claims intake	Report, photograph, submit, track one loss type	60k to 120k	Three to four months
Quote and buy	One product: rate, purchase, issue, view	120k to 250k	Four to seven months
Full self-service	Multi-product lifecycle: buy, endorse, claim, renew	250k to 400k and up	Seven to twelve months
Legacy wrapper	API layer over a core that has none	30k to 100k additional	Runs first or parallel

Planning ranges for a competent external team; internal costs vary with loading. Legacy wrapping is additional where needed.

The integration tax: where the money actually goes

Take a quote-and-buy build and open the invoice, and the distribution surprises people who price apps by screens. Roughly a third of the engineering goes to integrations: the rating call and its error cases, policy issuance and the document flow, billing schedule creation, payment provider integration, and the authentication bridge into the carrier's identity regime. The visible UI is a quarter or less. The remainder is the connective tissue: data modeling, state handling for flows that can fail mid-purchase, testing against core system behavior, and compliance work.

Each integration has a visible cost and a hidden one. The visible cost is the happy path: call the rating API, show the premium. The hidden cost is the unhappy paths, and insurance is rich in them: the rating engine declines the risk, the underwriting rules refer it to a human, the payment succeeds but issuance fails, the core is down mid-purchase, the quote expires while the customer hesitates. Handling those honestly, with the customer told the truth and the state recoverable, is routinely half of each integration's budget.

Core system API quality moves every one of those numbers. A modern core exposes rating, issuance and policy queries as documented APIs with sandboxes, and integration proceeds at the speed of reading documentation. A legacy core may expose a nightly batch file and a screen-scraping surface, and every integration becomes an archaeology project. This is the single variable that most separates a 150,000 dollar project from a 300,000 dollar one with the same feature list, and it is knowable in the first week of discovery.

The practical advice follows directly. Audit the integration surface before committing budget: for each core touchpoint, does an API exist, is it documented, is there a sandbox, and has anything external integrated with it before. Sequence the riskiest integration first, not last, so the schedule's biggest unknown resolves early. And hold a contingency, 15 to 20 percent, explicitly against integration discovery, because that is statistically where it will be spent.

Where a quote-and-buy budget goes

About one third Integrations and their error paths Rating, issuance, billing, payments, identity. The unhappy paths are half of it.

About one quarter Visible UI and flows The screens people price the project by, and the smallest major slice.

The remainder Data, state, testing, compliance Connective tissue plus the regulated-industry overhead of 10 to 20 percent.

The team behind the numbers

The ranges above assume a compact senior team, and the shape matters more than the size. A typical quote-and-buy build runs a product designer, two to three engineers across mobile and backend, a QA engineer, and a part-time project lead, five to six people for five-ish months. The backend weighting is the insurance-specific part: consumer app teams run frontend-heavy, but here the hard work is the integration layer, so the strongest engineer on the team should be the one facing the core systems.

Domain experience is worth paying for, and this is not a platitude. An engineer who has integrated a rating engine before knows that quotes expire, that referred risks need a human queue, that policy documents generate asynchronously, and designs for all three before they surface as production incidents. A team learning these on your project learns them on your invoice, at the rate of roughly one rediscovered edge case per week. In vendor selection, one question separates the tiers: walk me through how you handled issuance failure after successful payment, on a past project, specifically.

Location strategy moves the same scope across a wide price band. The blended rates of an experienced team in Vietnam or similar offshore engineering centers run 25 to 45 dollars per hour against 100 to 180 in the US and Western Europe, which is how the same quote-and-buy app can be quoted at 130,000 or 350,000 by teams of comparable competence. The judgment questions, covered properly in the offshore engineering guide for Vietnam, are about communication structure and domain depth, not about whether the arithmetic works.

One anti-pattern deserves its own paragraph: the oversized team as schedule insurance. Insurance app critical paths run through a small number of gnarly integrations, and ten engineers do not make a rating integration land faster than three who understand it; they generate coordination overhead and idle frontend work that gets rebuilt when the integration reality arrives. Scale the team after the integration spine works, when parallel product lines and features genuinely parallelize.

A sane build sequence

1. 1

   Discovery and integration auditWeek 1 to 2

   One to two weeks against the core APIs. Turns the range into an estimate and finds the wrapper work early.

2. 2

   Integration spine firstFirst third

   The riskiest core integration built and proven end to end before the UI grows around it.

3. 3

   One flow end to endMiddle third

   A single product quoted, bought and visible in the app, in production behind a flag. The seams are now real.

4. 4

   Widen and hardenFinal third

   Error paths, edge cases, compliance review, penetration test, store submission. The unglamorous final third.

5. 5

   Operate and iterateFrom launch

   The recurring budget takes over: maintenance, data services, and the roadmap the first release opened.

The recurring bill nobody quotes

The build cost is the visible number; the ownership cost is the honest one. A working planning figure for maintenance is 15 to 25 percent of the build cost annually, and it is not padding, it decomposes into named work: operating system and store compliance updates twice a year, dependency and security patching, core system changes that ripple into the app every time the carrier upgrades anything, and the defect tail every production system carries. An app left unmaintained in a regulated industry is not static, it is decaying toward a compliance finding.

Infrastructure and services are the second recurring line. Hosting for the app's backend-for-frontend layer, monitoring and crash reporting, push notification services, document generation and storage, and payment provider fees per transaction. Individually small, they sum to hundreds to low thousands of dollars monthly at moderate scale, and they should be in the total cost of ownership model from the start rather than discovered on the first invoice.

The third line is the one that grows: the roadmap. A launched insurance app immediately generates demand, the second product line, the endorsement type the first release deferred, the claims status detail customers actually ask for, and the renewal flow that retention economics argue for loudly. This is not scope creep, it is the product working; but it means the launch budget and the annual budget are different conversations, and carriers that only had the first one feel deceived by their own success.

Frame all three lines at decision time, not launch time. The useful executive summary is total cost of ownership over three years: build cost, plus roughly 20 percent of it annually, plus services, plus the roadmap capacity the carrier intends to fund. For a quote-and-buy app that is typically 1.6 to 2 times the build cost over three years, and a decision made on that number survives contact with reality in a way that a build-cost decision does not.

The ownership lines to budget

• Maintenance at 15 to 25 percent annuallyStore compliance, security patching, dependency updates, core-change ripple, defect tail. Named work, not padding.
• Infrastructure and servicesBackend hosting, monitoring, push, documents, payment fees. Hundreds to low thousands monthly at moderate scale.
• Roadmap capacityThe second product line and the deferred features. Success generates this demand; budget it as intent, not surprise.
• Core upgrade coordinationEvery carrier core upgrade ripples into the app. The app team needs a seat at that table, and hours against it.

The mistakes that double budgets

The first doubler is the invisible wrapper. A carrier prices the app, signs the budget, and then discovers the policy core cannot answer the app's questions through any API that exists. The wrapper gets built inside the app project, unplanned, and the schedule and budget absorb it as an overrun rather than a decision. The fix costs nothing: audit the integration surface in discovery and price the wrapper as its own visible line, built once and reused by every future distribution experience.

The second doubler is premature breadth. The full self-service vision, every product, every lifecycle event, gets attempted in release one, and the product-line multiplication does its arithmetic: each line brings its own questions, rating rules, documents and endorsements, and five lines at 60 percent finished ship nothing. The compounding path is one product end to end, in production, generating feedback and confidence, then widening with the integration spine already proven.

The third doubler is treating error paths as polish. The happy-path demo works in month two, everyone relaxes, and then the final third of the project discovers that payment-succeeded-issuance-failed needs a recovery flow, that referred quotes need a human queue and a callback, and that the core's downtime window needs graceful degradation. These were always half the work; scheduling them as if they were finishing touches is how a project that looked 80 percent done stays there for a quarter.

The last doubler is churn at the decision layer, and it is the client-side one. An app that re-litigates its product scope monthly, that adds a stakeholder per quarter, that redesigns the purchase flow after it is built, pays for every reversal at engineering rates. The discipline that protects the budget is unglamorous: a named product owner, a scope document that requires a decision to change, and the willingness to put new ideas in the next release rather than this one.

Budget protection, in practice

Do this

• Pay for discovery firstOne to two weeks against the core APIs converts the widest cost variable into a known quantity before the big commitment.
• Price the wrapper separatelyIf the core needs an API layer, it is its own line and its own asset, reused by everything built after.
• Ship one product end to endThe integration spine proven in production is the foundation breadth builds on cheaply.
• Schedule error paths as core workUnhappy paths are half of each integration. They belong in the plan's middle, not its margins.

Not this

• Accept a blind fixed priceA quote issued before anyone inspected your core systems prices the vendor's risk, not your project.
• Launch five product lines at onceProduct-line multiplication is the classic insurance scope trap; partial breadth ships nothing.
• Demo the happy path and relaxThe month-two demo measures a third of the work. The error paths are still ahead.
• Re-litigate scope monthlyEvery reversed decision is paid at engineering rates. Park new ideas in the next release.

A worked example: one carrier, one product, real arithmetic

Make it concrete with a composite drawn from real projects. A mid-size general insurer wants quote-and-buy for its motor product plus claims intake, on iOS and Android, against a core that is ten years old but has partial APIs: rating and policy queries exist, issuance is batch, and claims intake has no external interface. Discovery takes two weeks and produces the honest map: two of five integrations are clean, one needs work on the core side, two need a thin wrapper.

The priced plan comes out as follows. Wrapper work for issuance and claims intake: 45,000 dollars, built as a separate service the carrier keeps. The app itself, motor quote-and-buy plus claims intake, shared codebase across platforms: 165,000 dollars over six months with a team of five. Compliance overhead, security review and penetration test included in that figure as a visible 12 percent. Contingency held at 18 percent against integration discovery, of which about half is ultimately spent when the rating API's quote expiry behavior turns out to be undocumented.

The three-year ownership picture, presented at decision time: build plus wrapper roughly 210,000, annual maintenance modeled at 20 percent of build, services at 1,500 monthly, and a funded roadmap line for the second product in year two at 80,000. Total three-year cost of ownership lands around 480,000 dollars, and the carrier decides on that number, against a business case built on direct sales commission savings and claims handling cost per case.

The instructive part is what the arithmetic did to the conversation. The wrapper stopped being an overrun and became an asset with a name. The contingency was spent on the thing contingencies exist for, and everyone had agreed in advance that it would be. And the year-two roadmap was a plan rather than a disappointment. None of the numbers were remarkable; the structure around them was the difference between this project and the ones that end in procurement disputes.

Frequently asked questions

An insurance app is a thin face on deep plumbing: the screens are priced in hours, the core system integrations in weeks, and published cost ranges mislead because they price the wrong one. Before budgeting a build, see what actually drives an insurance app budget, tier by tier, with the integration tax made visible.