By Nikhil Garg — ex-CTO, 13+ years building and shipping software
Most "case studies" you read are sanitized. Everything went perfectly, the client was thrilled, the end. This isn't that. This is the honest behind-the-scenes of how I built a warranty management platform that has now processed over $1M in claims — including the parts that were hard, the decisions I'd revisit, and what actually made it work.
The problem: warranty management was stuck in a spreadsheet
The warranty industry runs on a surprising amount of manual labor. When I started talking to the team behind what became MHHC Enterprises Inc, the reality was this: warranty registrations, claims, approvals, and payouts were being tracked across spreadsheets, email threads, and a few disconnected tools.
Every claim was a manual judgment call. Someone had to find the original warranty, verify it was still valid, check the terms, decide whether the claim qualified, and then process the payout — by hand. At low volume, that's annoying but survivable. At scale, it's a disaster. Errors compound. A mis-keyed claim or a missed expiry date isn't a typo — it's real money out the door, or a customer wrongly denied.
There was no single source of truth, no audit trail, and no way to scale without linearly adding people. The business couldn't grow because every new customer meant more manual processing. That's the textbook signal that you need real software — and it's the same broken-industry pattern I wrote about in why the warranty industry is stuck in 2010.
What we decided to build — and what we deliberately left out
The temptation with a project like this is to build everything at once. We didn't. The v1 scope was ruthless on purpose.
What went in: a central warranty registry (every policy in one place, with real validity rules), a claims intake and processing engine, role-based access for the team, and an admin dashboard to see claim status, payouts, and the numbers that matter. That's it. Those four things were the difference between "spreadsheet chaos" and "a system."
What we deliberately left out of v1: customer-facing self-service portals, automated fraud detection, deep analytics dashboards, multi-currency support, and a mobile app. Every one of those is a legitimate feature. None of them mattered until the core claims engine was proven and processing real volume.
This is the discipline most founders skip. The "not now" list is more important than the feature list, because it's what keeps you shipping. We could always add a customer portal later — and we did. But building it in v1 would have delayed the one thing that actually needed to work: reliable, auditable claims processing. It's the same ruthless-scoping approach I lay out in from idea to MVP in 30 days.
The technical decisions — including one I'd make differently
People always ask about the stack, so here it is, with the honest reasoning.
Why Next.js. I wanted one framework for the admin dashboard, the API layer, and eventually the customer-facing pages — server-rendered where it helped SEO and performance, client-rendered where the dashboard needed interactivity. Next.js gave me that without stitching together a separate frontend and backend. For a small team that needs to move fast and not maintain two codebases, it's the boring, correct choice.
Why Firebase. This is the one that surprises people for a financial-ish system. But Firestore's real-time updates meant the team saw claim status changes instantly, Firebase Auth handled role-based access out of the box, and serverless functions meant I wasn't managing infrastructure while trying to ship features. For a platform that needed to get to production fast and scale without a DevOps hire, it was the right trade. The same architecture backs the Jacana Warranty build.
How the claims engine works. At its core, a claim flows through states — submitted, validated against the warranty's terms and expiry, approved or rejected, then queued for payout. The engine encodes the warranty rules so validation isn't a human guessing; it's deterministic logic with a full audit trail on every transition. That audit trail is what makes $1M in processed claims defensible.
The decision I'd make differently. I leaned on Firestore for everything, including reporting. For transactional claims data, Firestore was great. For the complex aggregate reporting that came later — payout totals across time, cohort analysis — a document database fights you. I'd have planned a proper reporting layer (or a relational read-replica) from the start instead of bolting it on. It's exactly the kind of call I flag in the technical decisions that haunt startups.
The challenges nobody puts in the case study
Three things genuinely tested the build.
Warranty rules were messier than anyone admitted. "Just validate the claim against the warranty" sounds simple until you discover the edge cases — partial coverage, transferred warranties, products with different terms under one policy. The fix wasn't more code; it was sitting with the team and mapping every real rule before encoding it. The clean engine came after the messy conversation.
Data migration from the spreadsheets was a minefield. Years of historical warranties and claims lived in inconsistent spreadsheets — missing fields, duplicate entries, dates in five formats. I wrote a migration pipeline that validated and normalized as it imported, and flagged anything it couldn't resolve for a human to check rather than silently guessing. Importing dirty data cleanly is unglamorous and took longer than expected.
Getting payout logic exactly right. This is money. There's no "we'll fix it in the next sprint" when a payout is wrong. I built this conservatively, with extra validation and a manual approval gate before any payout finalized, until everyone trusted the numbers. Trust was earned by being slow and correct first, then fast.
The outcome: $1M+ processed, and still running
Today the platform is the operational backbone of the warranty business. It has processed over $1M in claims — every one validated, traceable, and auditable. What used to be a manual, error-prone scramble is now a system: warranties registered in one place, claims intake and validation handled by the engine, payouts processed against deterministic rules, and a dashboard the team actually uses to run the business.
The customer portal and analytics we deferred from v1? Added later, once the core was proven — exactly as planned. The platform scaled with the business instead of capping it. That's the whole point of building real software instead of stretching a spreadsheet until it snaps.
What actually made this engagement work
I've seen plenty of technically-sound projects fail anyway, so this part matters.
It worked because the team treated me as a partner, not a pair of hands. They gave me access to the real domain knowledge — the messy warranty rules, the edge cases, the "oh, we also do this sometimes." You cannot build correct software for a domain you don't understand, and they let me understand it.
It worked because we agreed on a ruthless v1 scope and held the line. Nobody panicked and demanded the customer portal in week three.
And it worked because there was trust to build conservatively where it counted — to be slow and correct on payouts before being fast. This is the kind of relationship I described in the blueprint for digitizing a broken industry: a founder who knows their domain, paired with an engineer who ships, with a clear scope between them.
If you're sitting on a spreadsheet that's about to snap
If your business is running on manual processes and disconnected tools, and you can feel the ceiling coming — that's exactly the moment to build real software, before the errors get expensive.
I help founders turn messy, manual operations into platforms that scale. Not bloated enterprise software, and not a fragile prototype — a focused system that does the core job reliably and grows with you, the way this one processed its first dollar and then its millionth.
If that's where you are, let's talk. Bring me the spreadsheet, the workflow, the thing that breaks when you add customers. I'll tell you honestly what it takes to turn it into something real.
