Two platforms, one customer
A warranty company had two live systems that had never been connected. One knew its dealers. The other knew its customers. Both were taking real money, and neither knew the other existed.
Fractional CTO & lead engineer · 14 weeks · 2026
2
Live systems, both moving real money
0
Safe windows to break either one
4
Facts allowed to cross between them
1
Silent bug that would have corrupted every contract
Dealers went from bottleneck to channel
The condition that made it work: dealers had to end up better off, or none of them would have agreed to send their customers somewhere else.
Before
- Every sale needed a dealer to sit down and type the order in by hand.
- Growth was capped at how much selling the dealers felt like doing.
- The company never met its own customers. Renewals and complaints went through a middleman.
- There was nothing to put on a flyer, an email or a QR code in a shop.
After
- Customers buy directly from a branded page the dealer can hand out.
- The company owns the relationship, the renewal and the claim.
- The dealer earns on that sale and on every renewal after it.
- Dealers stop being a bottleneck and become a marketing channel.
Three things that removed the easy options
The codebase was production
No safe copy to practise on. Every change could reach a paying customer the same day.
Money moved both ways
Charges, refunds, commissions, clawbacks, chargebacks. A quiet data error here is a financial one, not a cosmetic one.
Five systems had to agree
Two backends, two web portals and a mobile app, all of which had to keep working while the ground moved underneath them.
Deciding where the truth lives
When two systems both think they know a customer's status, they will eventually disagree. Not loudly. One of them will just be a little bit wrong, for a while, about something that matters.
So the first real decision was not a feature. It was a rule: for every single piece of information, exactly one system is allowed to be the truth.
One exception, deliberately: commission terms are frozen onto the order at the moment of purchase. Before that, commission was calculated from the live product settings, which meant an administrator editing a product silently changed what every existing dealer had already earned. Freezing it made the past stop moving.
The bug that did not break anything
That rule was not how the system started. Both sides had been keeping their own copy of the customer, and the copies had already drifted. So the rule had to be imposed on a system that was live and taking payments, in stages. Partway through, this happened.
What broke
Five screens stopped showing data. Obvious, visible, annoying. The kind of thing you fix one at a time in an afternoon and move on.
What I did instead
Stopped, and went through all five systems listing every single place that read any piece of information we had moved. Slower, and it felt like overkill at the time.
What that found
One piece of code was still asking for the coverage level, the waiting period and the excess from a place they had just been moved out of. It did not fail. It returned zeroes and defaults, and the other system wrote them into the customer’s permanent record.
What it meant
A customer who paid for premium cover, with a ten day wait and an excess, was stored as standard cover, no wait, no excess. Those are the terms you argue about when someone makes a claim. That is not a display bug. That is the contract.
Every new customer was being recorded with the wrong contract terms. Nothing crashed. No test failed. No one would have noticed for months.
We fixed the code, wrote a one-off job to repair the affected records, checked a real one by hand, and then built the automated check below so it could not happen again. The part worth keeping is this: the five visible bugs were the cheap ones. Fixing only what I could see would have shipped the expensive one.
Four things that outlast me
A fix repairs one bug. The useful work is making a whole category of bug hard to ship. None of these are clever; all of them are boring on purpose.
A written list of who owns what
One document naming every piece of information and which system is allowed to hold it. Not a diagram anyone could ignore. A list you can check something against.
A build that fails if the list is broken
An automated check compares the real systems against that list on every change and stops the release if they disagree. I tested it by deliberately breaking the rule, to confirm it went red.
Tests that check money, not shapes
Most tests confirm a screen loaded. These confirm the customer was charged the right amount, the refund subtracted claims already paid, and the commission matched to the penny across signup, renewal and mid-contract changes.
A written record of what we chose not to build
Five things were deliberately left out, each written down with the reason. A gap stays a decision instead of quietly becoming a surprise later.
The paths nobody demos
Any system can take a payment. The difficult parts are all the ways money comes back out, and those are the parts that never make it into a specification.
Refunds ignored claims already paid
If someone cancels after the company has already repaired their phone, a full refund means paying for the repair and handing the premium back. Cancellation now works out a proper pro-rata figure, net of anything already claimed, across the main plan and any extras.
Would have cost: the repair and the premium, every time
Card disputes went unanswered
The system was not listening for disputes at all. A customer could dispute a charge, get their money back, and keep working cover while the dealer kept the commission. And an unanswered dispute is lost automatically.
Would have cost: every dispute, including the winnable ones
A failed card was a dead end
Reviewing work I had already delivered, I found the "your payment failed" message offered nothing but an email address, and adding a new card did not retry the outstanding invoice. I flagged it as my own defect and fixed it at no charge.
Would have cost: customers who wanted to pay, and couldn’t
Cashback pays by card, not coupon
Customers earn cashback on a prepaid card they can spend anywhere, rather than credit locked to this company. Checking the provider first also revealed it cannot report whether the card was ever spent, which killed a reporting feature before it was built.
Saved building: an entire redemption system
Fourteen weeks, in order
A readiness gate
Before any codeNine blockers tracked to closure before a line of feature code was written, including the payment provider’s business verification, which had a multi-week lead time and would have stalled everything if it had been discovered late.
Pages, bundles, checkout
Phase oneBranded partner pages with downloadable QR codes, bundles with slot rules and multiple price points, and a checkout that creates a real customer on the other system.
The correctness programme
Phase twoThe part nobody asks for. Removing the duplicated copies of customer data, imposing the ownership rule, auditing every reader of every moved field, and the bug sweep that followed.
The money paths
Phase threeCancellations and pro-rata refunds, dispute handling, failed-payment recovery, and the commission clawbacks that have to happen when money goes back out.
Reporting and payouts
Phase fourCommission payouts for dealers and their brokers, an exportable reporting suite, dashboards, and a signup funnel that shows where people drop out.
Live, and what is honestly not
- Branded partner pages with QR codes
- Bundles with slot rules and price tiers
- Checkout and customer signup
- Device registration
- Extra devices bought mid-contract
- Renewals and dunning
- Claims for bundled devices
- Cancellations and pro-rata refunds
- Dispute and chargeback handling
- Commission payouts, dealer and broker
- Reporting suite and dashboards
- Signup funnel and drop-off tracking
The interesting work was not building the features. It was deciding where the truth lives, and then proving nothing else quietly disagreed with it.
If you have two systems that grew up separately and now have to agree about money, that is the shape of problem this was. Happy to talk about yours.
More on this client in the GetCover platform overview, or read how the same warranty platform processed its first $1M in claims.
Risk-Free Start
In 30 minutes, I'll review your SaaS idea, suggest the right architecture, and give you a realistic timeline.
Free Strategy Call
First SaaS strategy call completely free. Discuss your idea, get architecture advice, no commitment.
Free Work Sample
Up to 5 hours of actual work at no cost. See my process and quality firsthand.
Why I offer this: Building a SaaS is a big decision. This lets you experience my problem-solving approach, communication style, and technical expertise before you commit.