America’s largest homebuilders may be sitting on one of the most valuable housing datasets, yet almost nobody outside their organizations knows how to compare it.
Warranty data.
Every callback, leak, HVAC failure, plumbing repair, and construction defect tells the industry something about how houses should be built.
The problem isn’t a lack of data in homebuilding. The problem is that we don’t agree on what the data means.
What’s a warranty event? When does the clock start? When does it stop? What’s a callback versus rework? What’s the denominator? And are two builders even measuring the same thing when they use the same terms?
Until we answer those questions, millions of observations remain trapped within individual companies rather than becoming industry knowledge.
That’s a problem because homebuilding is chasing scale. Companies are consolidating. Institutional capital is moving deeper into land. Land is being removed from balance sheets. Purchasing is becoming more centralized. Technology is proliferating. Builders increasingly describe themselves as manufacturers.
But getting bigger is different from getting smarter.
The promise of scale should be simple: every house we build should teach us how to build the next house better. I’m not sure we’re there yet.
I learned why in healthcare.
What 20 million patient records taught me
I spent 12 years building a medical data intelligence company and invested millions of dollars to answer a simple question: what happens when you give really smart people better information?
At our peak, our platform accessed approximately 20 million patient records.
Healthcare wasn’t suffering from a shortage of data. It was drowning in it. Information lived in different systems, formats, and definitions. Important clinical information existed, but it didn’t appear when and where a physician needed it.
We normalized the data and built dashboards that reflected how physicians practiced medicine, rather than relying on hypothetical models. We didn’t ask physicians to change their workflow for our technology. We made the technology fit their workflow.
With clean, normalized information, we improved identification of certain potentially deadly cardiac diseases by 300%. We documented the results in a paper that was accepted and presented at the American College of Cardiology’s national conference.
I didn’t make the doctors 300% smarter. They already had the knowledge. The data already existed. We made it usable.
Then I learned something else: better information doesn’t necessarily lead to better decisions if the incentives point in the opposite direction.
A meeting in Boston
We once traveled to Boston to seek funding from a large insurance company. An executive interrupted my presentation.
“Three hundred percent more what?”
“Identification.”
He looked at me. “Mr. Finfer, this meeting is over.”
It took me a moment to understand. Better identification could mean more diagnosed patients, which could lead to more treatment, procedures, medication and follow-up. The clinical benefit and the payer’s economic incentive didn’t necessarily align.
That meeting taught me something I’ve never forgotten: having the data and having the incentive to act on it are two completely different things.
Eventually, someone else gave us the opportunity. Julie Kemp, a senior leader at Medtronic, got us into a room in Minneapolis. Pat Mackin, then President of Medtronic’s Cardiac Rhythm Disease Management business, was at the table as his team pressed us with the obvious questions.
Where’s the proof? Where’s the validation? Where are the results? We couldn’t provide them with the proof they wanted without first having the opportunity to produce it.
Finally, Pat cut through the circular argument. His point was simple: nobody could expect us to prove it if nobody gave us the chance to try.
We left with more than a million dollars in funding. Eventually, we proved it. We were preparing to go live, under a signed agreement, as an official clinical decision-support tool of the American College of Cardiology, whose professional community included roughly 29,000 FACC and MACC physicians.
We weren’t hoping physicians would find our software. We were preparing to integrate the technology into their existing workflow. We were headed for scale.
Then scale taught me its own lesson.
Our early monolithic architecture had been an advantage. It allowed us to build and iterate quickly and reach a minimum viable product. But onboarding and adoption grew faster than we could have imagined. The architecture that got us to market wasn’t capable of supporting the scale we were approaching. We were hyper-growing with negative unit economics, and our efficiency was actually decreasing as we grew.
We needed to re-architect the platform around microservices while continuing to onboard and serve a rapidly expanding user base. That required time and capital. The capital markets shifted before we could complete the transition.
We had the technology, the clinical results, and the distribution opportunity. What we lacked was enough runway to rebuild the infrastructure beneath them and make the economics of growth work.
It may have been the most expensive lesson of my career: what gets you to scale isn’t always what lets you operate at scale. Scale doesn’t cure bad unit economics. It magnifies them.
Which brings me back to homebuilding.
Scale should mean learning faster
A builder producing 80,000 homes has obvious advantages over one producing 800: purchasing power, capital, technology, resources and brand. But the real question is what it learns from all those additional houses.
Which materials work? Which fail? Which construction details cause callbacks? Which trades outperform? What happens to the warranty when cycle time falls? Which purchasing savings are real, and which simply shift costs elsewhere?
And perhaps most importantly: does the knowledge travel?
If Phoenix discovers something that improves the house, Dallas should be in the loop as soon as possible. If Houston eliminates a defect, Orlando shouldn’t have to rediscover the same solution three years later or the hard way.
That’s scale. Not just buying refrigerators for less money. Learning faster because you built more houses.
Yet an industry cannot learn collectively from data it doesn’t define consistently. I’ve run into this problem while researching this Chasing Scale series, an ongoing analysis of the homebuilding industry. What’s a market? What’s a division? When does cycle time begin and end? What’s included in vertical construction costs?
You cannot benchmark what you cannot consistently define. Warranty may be the best place to begin.
The houses are already talking
Every large homebuilder knows what it’s sitting on: water intrusion, HVAC, plumbing, electrical, roofing, windows, flooring, foundations and appliances. Behind every claim can be the community, floor plan, elevation, material, supplier, trade contractor, superintendent, climate, cycle time, repair cost and recurrence.
That’s an extraordinary amount of operational intelligence. The houses are already talking to us. The question is whether we’re listening.
Don’t give a division president 100,000 rows of warranty claims. Tell her which communities are performing differently.
Don’t give a superintendent an enterprise spreadsheet. Show him which details, products, and trades are generating callbacks on his houses.
Don’t tell purchasing it saved $200 on a component. Show whether that component caused $600 in downstream warranty expense.
Don’t tell design only which floor plans sold the most. Show which produced fewer problems, higher customer satisfaction, better absorption, and more predictable construction.
And don’t celebrate cutting 10 days from cycle time until we know what happened after those 10 days disappeared.
Same underlying data. Different dashboard. Different decision. That’s what we learned in healthcare. I didn’t need to teach cardiologists