For business owners about to sign off on a fix — and what has to be true before you call it finished.
A service engineer opens a form he’s filled in a hundred times before. Job description, visit notes, the usual fields. The firmware version field didn’t pre-populate this time, so he leaves it blank and submits. Nothing complains — no error, no warning, nothing in red. The form behaves exactly the way it always has.
What actually happened: the firmware and software version records for that equipment were erased. So were the records for every sub-component linked to it. Not flagged for review. Not queued anywhere. Gone, with nothing on screen to say so. In the fix documentation, this one is marked Critical: permanent data loss, no warning, no recovery path. There’s no way, from inside the system, to tell how many other installations it had already happened to.
This was one of four defects found in this client’s CRM before anything new got built for them. All four had to be fixed first.
Why fix before you build?
The engagement is scoped in five phases. The first is called Fix First: nothing new gets built on data nobody can trust yet. A report is only as good as the numbers behind it. Whatever gets built on top of broken data inherits the problem, usually without anyone noticing. A report carries that risk one way — someone reads a wrong number. An automation or an agent acting on the same data, without a person checking first, carries it worse.
So before any new report or dashboard, the first phase was simple: close four active defects. Nothing else started until that was done.
What four things looked like — until you looked closer
Each of these passed as normal at the moment it happened. That’s the pattern worth noticing more than any individual bug:
| What it looked like | What was actually happening | Business impact |
|---|---|---|
| A supplier order gets created from an invoice. Conversion complete. | The source invoice never locked. It could be converted a second time, silently, with no warning it had already been used. | Nothing in the system would catch a duplicate order going out. |
| A supplier order’s line items show a price and a tax figure for each product. | Those figures still carried the customer’s list price, not the recalculated supplier cost. The correct numbers were computed — just never saved to the database. | Figures can’t be reconciled without a manual re-check, every time. |
| A service form submits cleanly. | A blank version field silently overwrote the firmware and software records for that equipment, and every linked sub-component. Nothing on screen showed anything had changed. | Nobody can tell what’s actually installed at a site next time it matters, whether that’s a support call or a warranty claim. |
| A sales record gets duplicated. Copy looks complete. | The line items didn’t copy — they moved. The original was left showing zero. Nobody would notice until they opened it. | Pricing and history on the original record are gone, and don’t come back. |
None of these threw an error. That pattern is what made them worth finding first.
What “done” actually meant
Each of the four followed one sequence: reproduce the failure, gather evidence from two independent angles, apply the fix, then repeat the exact flow and gather that evidence again. The proof had to match, twice.
Take the supplier order line items. Before the fix, converting an invoice into a supplier order looked completely normal: the record was created, the line items showed numbers, nothing complained. But those numbers were the invoice’s original customer-price figures, not the recalculated supplier-cost figures the conversion was supposed to produce. The system did compute the correct numbers. It just saved the record a step too early, before they were written back. Those correct numbers existed for a moment, mid-calculation. Then they vanished. The database kept the old invoice figure. So did the screen.
After the fix, that conversion was run again on a fresh test invoice, and the database was queried again. The stored figures now matched exactly what the correct calculation said they should be, on every line. Not “looks right on screen.” Matches, at the row level, what the numbers were supposed to be.
The invoice-locking bug got this treatment too, from the other direction. One screenshot: the invoice status reading Unpaid, before conversion. A second screenshot, after the fix: status flipped to Invoiced and stayed that way. The record finally showed what had actually happened to it. Screen evidence and database evidence, before and after: that’s what backed all four fixes, not just the two described here.
That’s what “done” means on this engagement. Not “I changed the code and it seems fine now.” A claim you can point to twice: what the screen showed, and what the database actually stored, before the fix and after it.
Why the fourth bug didn’t cost what the first one did
The first fix took three days, spread across three-to-four-hour sessions. Most of that time wasn’t spent fixing anything. It was spent building a working map of a system nobody hands you documentation for: which workflow touches which code, where the recalculation happens, what “correct” is even supposed to look like. The evidence standard above got built during those three days too, alongside the fix itself.
The next three took about an hour of investigation each, finished in one combined day. Not because the standard dropped. Because it didn’t have to be reinvented from memory each time. What changed between bug one and bug two was a Claude skill: the reproduce-evidence-fix-reverify sequence, written down as a procedure I could point at a new defect, instead of reconstructing it by hand each time. The fuller, technical account of building that skill is here.
Where this leaves the CRM now
All four fixes are live in the client’s production system. What gets built next stands on numbers that are actually correct, not assumed to be.
What this means for you
Before you agree that something is “done,” pin down what that word means with whoever’s fixing it. “I changed it and it seems fine” is one claim. “Here’s what was wrong, here’s proof from two places, before and after the fix” is a different, stronger one. That difference is exactly where a lot of engagements quietly go soft.
I work with small and medium businesses that have a system, a process, or a function that isn’t working the way it should, and need someone who can prove it’s fixed, not just say so. Proving it, not just asserting it, is the standard I hold as an AI Consultant + Builder on every engagement. The engagement behind this piece is documented phase by phase, as it happens.
If that’s the kind of standard you’re looking for, reach out to me at ranga.sampath@gmail.com