A home quote is only as good as the rebuild value behind it. Where valuation data comes from, why market price is the wrong number, and how to engineer the pipeline that feeds the quote.
Every home insurance quote is built on one number: the sum insured. Get it right and the premium is fair, the claim pays in full, and everyone forgets insurance exists — which is the goal. Get it wrong in either direction and the product fails quietly. Too high, and the customer overpays for cover they can never claim. Too low, and the one time they need the policy, it pays a fraction of the loss. In engineering terms: the valuation is the input with the highest blast radius in the entire property quote pipeline, and it deserves to be treated like one.
The first thing to engineer out is a category error that even experienced teams make: the market value of a property is not the number insurance needs.
Market value is the wrong number
A property's market price bundles the land, the location premium, and the market cycle. None of those burn. The number a home policy needs is the rebuild cost — what it would take to clear the site and reconstruct the same building today, including demolition, materials, labour, and professional fees. In a city where land is the dominant share of price, market value can run far above rebuild cost, and a policy insured to market value quietly overcharges. In a construction-cost spike, the reverse happens and the policy silently underinsures.
So the pipeline's job is not to look up a price. It is to estimate a reconstruction cost from the attributes that actually drive it: built-up area, construction type, number of floors, finish quality, and the current cost of building in that region.
Where the data actually comes from
In practice a quote pipeline draws on four layers, in descending order of trustworthiness:
- Documents that already exist for another reason. A lender's valuation report, a deed, a building permit, an Ejar lease record. These were produced by someone with an incentive to be accurate, and in an embedded flow they are often sitting in the host platform's own data. This is the best source and the whole argument for embedding: the transaction already verified what the insurer needs.
- Structured platform data. A real-estate listing or property-management system knows the built-up area, property type, and age — self-declared once, but reviewed by more eyes than an insurance form ever gets.
- Customer declaration. Necessary as a fallback, weakest as evidence. People do not know their built-up area; they guess, and they guess in round numbers.
- Model inference. Given a geocoded address, you can infer neighbourhood construction era, typical property types, and regional cost indices. Useful for sanity-checking the other layers, dangerous as a sole source.
The engineering pattern that follows: never treat these as interchangeable. Tag every valuation with its provenance, and let underwriting rules key off provenance — a document-backed sum insured can flow straight through; a declared one above a threshold routes to review.
Validation is the actual product
The valuation pipeline earns its keep in the checks, not the lookup. The ones that matter most:
- Unit traps. Square metres versus square feet, built-up area versus plot area, price per unit versus total. A single confused unit produces a quote that is confidently wrong by an order of magnitude — the worst failure mode, because it looks plausible to a customer who also does not know the right number.
- Bounds by type and region. A two-bedroom apartment declaring 900 square metres, a villa declaring 60 — reject or flag at entry, because bad area data poisons everything downstream.
- Cost-index freshness. Rebuild costs move with materials and labour markets. A static cost-per-metre constant embedded in code two years ago is a slow leak of underinsurance across the whole book. Treat regional cost indices as data with an owner and a review date, not as configuration.
- Drift at renewal. The sum insured that was right at purchase decays. A renewal flow that silently carries last year's number forward compounds the decay annually; a good one re-runs the estimate and surfaces the change.
The sum insured is not a form field. It is a derived value with provenance, bounds, and a shelf life.
Underinsurance is a UX failure before it is an actuarial one
Most policies apply proportional reduction: insure a home for half its rebuild cost and every claim — even a small kitchen fire — pays out at half. Customers discover this rule at the worst possible moment. The engineering response is to make the good path the easy path: pre-fill from the strongest available source, show the customer what the number means in plain language, and make adjusting it deliberate rather than accidental. A slider that lets a customer drag their sum insured down to cut the premium is a lawsuit with good UX.
For platforms embedding property cover, the practical summary is short. Your valuation data is probably better than anything the insurer could collect on its own — that is your contribution to the risk, and it is worth real money in pricing accuracy. Pass it with provenance, validate it at the boundary, refresh it at renewal, and never let a market price masquerade as a rebuild cost.