Build vs. Buy for Warranty Claims Software

I've been on both sides of this decision, and I got it wrong at least once.

At Sears Home Services we ran one of the largest appliance repair operations in the country and bought more appliance parts than any other service provider or warranty company in the United States. When we needed software that didn't exist, we built it, including the first engine in this category that could source parts across multiple suppliers at once. The engineer who built it with me works with me today. So I'm not going to tell you that building is a bad idea. I've done it, and in that case it was the right call.

I've also sat in the rooms where a platform transformation gets approved with real conviction and quietly stops mattering eighteen months later, while the operations team keeps running the business out of a spreadsheet. 

I've watched a build get scoped in a quarter and then three years of integration work is still underway and the new product is more complicated than the old. And at ProPay, I spend a lot of time on the other side of the table watching companies decide whether to build something or work with someone who already has.

What I've come to believe is that most Warranty companies get this decision wrong not because they choose badly, but because they frame the question badly. So here is how I'd frame it to help you make an informed decision. 

There are three options, not two

Calling this "build vs. buy" collapses two very different purchases into one word, and that's where the trouble starts.

• Build. Your team develops warranty claims software internally, shaped exactly to how you operate and maintain integrations to all of your other systems.

• Replace. You buy a claims management platform and migrate onto it, retiring what you have.

• Overlay. You keep your system of record and run software on top of it that handles specific parts of the claim, writing everything back into what you already own.

Those three have almost nothing in common. Different cost structures, different timelines, different people who have to say yes, different consequences if you're wrong. When you score them as a single "buy" option against building, you end up choosing a decade-long migration when what you wanted was a six-week fix.

Building it yourself

The argument for building is stronger than most vendors will admit, so let me make it properly.

Nobody understands your coverage logic, your contract terms, your regional network, or your claim mix the way your own team does. Software built to that specification fits better than anything you can buy. And if your operation genuinely does something structurally different from the rest of the market, building may be the only way to protect that difference. That was true at Sears. Nothing existed that could do what we needed, so we made it.

Here's what I'd encourage you to think hard about before you go that way - 

It has to win a roadmap slot

At most warranty companies I talk to, the people who feel claims pain most acutely have the least influence over what engineering actually builds. I've spoken with presidents of business lines who have no meaningful input into their own technology roadmap. Claims tooling competes against billing, policy administration, the customer portal, and whatever compliance work arrived last quarter. It rarely wins, and "we could build that" quietly becomes "we'll get to it”, and then you never do.

The build is the small number

This is the mistake I see most often. Teams scope the initial development and compare it to a licence fee. But claims software doesn't sit still. Coverage terms change. States change. You add trades. Parts catalogs churn constantly, and every supplier integration has to be maintained as their systems change underneath you. 

When you're managing hundreds of thousands of active contracts across many policy variations, you're not funding a project with a completion date — you're funding a permanent engineering team.

Compare five-year total cost of ownership including maintenance. If your build estimate doesn't have a standing headcount line in it, it isn't finished.

You only learn from your own claims

Whatever your team figures out: where triage guesses wrong, which suppliers quietly drift on lead times, which coverage language generates disputes, they figure out from your volume, on your timeline, and you pay for the discovery once, alone.

Two states over, another warranty company is running the same experiment on their own data and hitting most of the same walls, a quarter ahead of you or a quarter behind. Neither of you finds out. This industry isn't short on smart operators. It's short on any mechanism for one company's expensive mistake to become everyone else's starting point.

That's the line that never appears in a build estimate. You're not only funding the software, you're funding the process of rediscovering, one carrier at a time, things the rest of the market has already paid to learn.

Quality gets unpredictable

Not because your engineers aren't good. Because this isn't what your company is organized to be excellent at. A business built to underwrite risk and distribute policies will produce claims software of variable quality, and the variance is the actual risk. It might be great. You won't find out until the money is spent.

The people you have may not be the people you need

Most warranty companies have IT organizations, not product organizations. Those are different jobs. IT teams are usually very good at implementing, integrating, and maintaining systems, that's the mandate. 

Designing a product from nothing and iterating it against users for years is different work, with a different hiring pool and a different management model. Some warranty companies have both. More of them incorrectly assume they do because they have engineers.

When someone tells me technology is their moat

I hear this a few times a year, and for a small number of warranty companies it's true. For most it deserves a harder look.

When I break a warranty business apart, everything lands in one of two buckets: 1) the things that make you different from the warranty company down the street, and 2) the plumbing that just has to work.

Three things live in the first bucket:

1. Demand: how you acquire customers and keep them. 

2. Supply: how you attract good service providers and keep them choosing your jobs over someone else's, which in this industry is closer to a real moat than most people treat it. 

3. And your actuarial model, because how you price risk is genuinely yours and nobody can sell it to you.

Claims infrastructure lives in the second bucket, plumbing. Nobody in this industry set out to build claims software. They built it because nothing good enough existed to buy. It’s the same reason companies once built their own CRMs, right up until buying one became obviously correct. You're not building your own Microsoft Excel today. I don't think you should be building claims plumbing either, when it's headed the same direction.

So if you want to be a technology company, I'd encourage it. But put that engineering capacity on demand, on supply, and on how you price risk. Not on the parts of the stack that will be commodities in a year or two.

Replacing the platform

The case for replacing is that it's decisive. One decision, one vendor, one migration, and fragmentation gets solved rather than managed. Boards understand it. Full platforms tend to be feature-rich because they've accumulated capability across many customers over many years.

My concern is commitment. These deployments commonly run a year or more from signature to production, and during that window you're paying without benefiting. The organizational energy required is enormous: legal, security, IT, operations, and change management all pulling at once.

And you're not just choosing for three years. You're choosing for ten, because switching again is expensive and disruptive enough that most warranty companies only do it when something forces them. So the question isn't just whether the platform is good now, it's whether the vendor is still meaningfully building it. 

Some warranty platforms are effectively finished with limited ongoing development, thin APIs. That's a fine trade if you're confident your requirements are stable. I don't think many warranty companies should feel confident about that right now.

Running something on top of what you have

The case for an overlay is that it's a smaller bet with faster proof. Your core system stays where it is. You start with one workflow like parts, invoices, or dispatch triage. You see whether it produces the result, and expand only if it does. If it doesn't, you've spent a fraction of a migration and disturbed nothing.

The honest case against it is that you're adding a layer rather than fixing what's underneath. If your core system is genuinely at end of life, an overlay postpones that reckoning. And an overlay only works if it integrates properly. If the software can't write results back into your system of record, you've just created a second place your team has to look, which is worse than where you started. Ask to see the API documentation before you believe anyone's integration claims, including ours.

Scoring the three

The variable that matters more than the choice

Here's the thing I'd tell you if we only had five minutes.

Every technology initiative at a warranty warranty company has to cross three bridges: business and operations, legal and compliance, and IT. Most companies cross them one at a time. Four months aligning the business. Six months in legal. Three months with IT. Enablement happens last, if it happens. Eighteen months later you're still rolling out and a competitor has shipped twice.

The companies that move cross all three in parallel. Legal gets scoped in week one instead of month six. IT is in the room from the start rather than receiving a finished decision. The business co-creates instead of approving. Same three bridges, same scrutiny, a third of the elapsed time.

This matters more than build vs. buy, because a well-run build will beat a badly-run purchase every time. If you know your organization crosses these sequentially, double every timeline above and consider fixing that before you fix anything else.

What I'd ask before deciding

What's the five-year cost of each option, including maintenance? If the build number doesn't include the team that keeps it alive, it isn't a number yet.

Where does this sit on a roadmap and do you have influence or control over it? If getting it prioritized is a project of its own, that's your real timeline.

What does it cost to be wrong? A failed pilot costs a pilot. A failed migration costs years. Weight the options by the downside, not just the upside.

Can you get everyone who has to say yes into one room? If not, you're crossing your bridges sequentially, and every estimate here roughly doubles.

Why we built ProPay the way we did

I'll be direct, because you've read this far and you can tell where I sit.

For most warranty companies, I think the overlay is the right answer — and that conviction is the entire reason ProPay exists in the shape it does.

We built it to run on top of whatever you already have. It writes back into your system of record rather than replacing it, so nothing gets ripped out and your team keeps working where they work. It can run headless, with no interface for anyone to learn, if that's what your setup calls for. I made that choice because I've watched too many good ideas die waiting for a platform migration that was never going to be scheduled.

We also built it modular, and that mattered to me just as much. Every product stands alone. You can take parts procurement and nothing else, run it against your actual claims, and see the number before you commit to anything further. Then add dispatch triage. Then invoice processing. It's a phased path rather than an all-or-nothing decision, which means you're never asking your organization to approve something enormous on faith — you're asking it to approve the next small step, with evidence from the last one in hand.

Those two decisions, the overlay and the modularity, aren't features we tacked on. They're a direct response to why I watched innovation stall at every large company I've worked in. The ideas were rarely the problem. Getting them across three bridges at once was.

If you're weighing this decision now, my suggestion is to stop arguing about it in the abstract. Send us about ten thousand of your historical claims and we'll show you where the money is going and what's actually recoverable — in your numbers, not our benchmarks. Then you'll be deciding with evidence instead of estimates, which is what I'd want if I were still sitting on your side of the table.