A property decision engine that admits what it does not know

Buyers make the largest purchase of their life on a listing page and a gut feel. The information that would change the decision exists. It is spread across public records, tax assessments, permit history, hazard maps, and comparable sales, and assembling it manually is a week of work per property.

The partner wanted a product that takes a listing URL and returns a decision.

The hard part was never data collection. It was deciding what a buyer should be told, in what order, and how confident to sound.

The market research. We launched against the New York market first, which meant understanding how that market behaves before deciding what to score.

New York is not one market. It is co-ops, HDFC co-ops, condos, high-rise towers, and a long tail of apartment and house types, and the pricing model behaves differently for each. Unit count in the building changes what a comparable sale means. Building area, proximity to comparable stock, and above all the condition of the specific unit, whether it needs renovation and how much, move the number more than the headline square footage does. A single generic model across all of those produces confidently wrong answers, which is the worst failure mode this product has.

The research decided which factors were worth building and which were noise in this market.

The scoring architecture. How the engines decompose, how factors are weighted, how buyer profile personalisation flows through the system, and how confidence gets surfaced instead of hidden.

The build. I worked with the developers through implementation of all three engines: pricing, risk, and decision. Not handing over a spec and leaving.

The weighting model needed adjusting once real data started coming back, and that only happens if the person who designed it is still in the room.

Paste a listing URL. The system ingests and geocodes the property, enriches it against roughly twenty-five public and commercial data sources in parallel, then runs three sequential engines.

Pricing engine. Fourteen factors across four categories: comparable sales, cost of ownership, market context, and property-specific adjustments. Outputs a fair value range, an asking price verdict, a true monthly cost breakdown, and a hidden repair estimate.

Risk engine. Seventeen factors across five weighted categories.

• Environmental, about 30 per cent. Flood exposure, contamination, natural hazard, climate.
• Financial, about 25 per cent. Price fairness, tax liens, insurance burden, affordability stress test.
• Structural and condition, about 20 per cent. Permit and repair history, code violations, systems age.
• Location and neighbourhood, about 15 per cent. School quality, socioeconomic trajectory.
• Transaction and legal, about 10 per cent. Title and ownership pattern, encumbrances.

Decision engine. Produces the verdict and the reasoning. A separate confidence and explainability layer scores completeness and source reliability before anything reaches the user.

Running alongside all three is a buyer profiling engine. It captures intent and concerns up front, then feeds weights into the pricing engine, the risk engine, and the decision engine.

A first-time buyer stretching on affordability and an investor buying for yield get different weights on the same seventeen factors, and therefore different verdicts on the same house.

Weighted personalisation instead of one score. The obvious product is a single number. Easy to read, easy to market. I did not build that, because a single number hides the model’s uncertainty behind a decimal point. A buyer who sees 72 out of 100 trusts it more than it deserves. A buyer who sees flood risk rated moderate with the source named and confidence marked high, sitting next to a factor marked unknown because no records exist, knows exactly where to push and where to hire an inspector. The cost is a heavier interface and a slower read. I took it.

Confidence and explainability as their own layer, not a footnote. Every factor carries its source and a confidence rating, and completeness is scored before the verdict renders. This is the decision I would defend hardest. The system assembles public data of wildly varying quality, and for some properties it will have nothing at all. Designing that state as a first-class output rather than an error case is the difference between a product a buyer can act on and a demo.

Tiering by data cost, not by feature count. Report tiers map to what each factor costs to produce. The lowest tier runs on free and low-cost public sources. Higher tiers unlock factors requiring commercial data or photo-based condition analysis. That kept the entry tier honest, because it says less rather than saying the same thing worse, and it made the pricing structure defensible on unit economics rather than on feel.

A confident wrong answer on a house purchase is worse than a slower right one.

The product is live and used by real buyers, launched against the New York market first. All three engines are built: thirty-one scored factors across pricing and risk, roughly twenty-five data sources feeding them, and the confidence layer running on every report.

The house-type problem made the report heavier than it should have been. Every property type needs its factors weighted differently, and each of those differences arrives on the page as more surface for the buyer to read.

Thirty-one scored factors is a lot for someone buying their first home, and I leaned on tiering to manage that load.

Tiering is a business decision. Cognitive load is a design one. I used the first to solve the second.

What the report needed was a real information hierarchy: the three things that should change your mind about this specific property, then everything else available on demand. I built breadth and then rationed it by price instead of ordering it by importance. Those look similar in a spec and they are not the same product.