Rigor Is a Budget
In one week this month I did two things that look like they belong to two different engineers. On my own website I pushed straight to main: no branch, no review, no second look. On a Medicare reimbursement engine I ran QA round 57. Not a typo. Fifty-seven rounds of trying to break the same product. People assume one of those is the real me and the other is a lapse. They are both the real me. They are the same decision, made twice, at two different prices.
01One operator, two prices
I run systems in healthcare, in web and marketing, in ad tech. Same hands, same editor, same week. But the process behind them could not look more different. My solo repos have zero pull requests. Not a few. Zero. A pull request where the author is also the only reviewer is a form you fill out to feel serious. The code does not get better because I clicked approve on my own work. It just merges slower.
A review with one head in it is not a review. It is latency.
The reimbursement engine gets the opposite treatment. By round 57 the reverse proxy was bound to loopback, so nothing reaches the app except through the front door. Admin pages check permissions on the server, not in the browser, where a curious user can peel them off. Every cron job has an external heartbeat, so if one dies quietly, something outside the box notices before a person has to. Round 57 added no features. It closed doors.
02What failure costs
Here is the question I ask of every system I run: if this breaks at 3 AM and nobody notices for a day, what happens? For my site, someone reads a typo and maybe I lose a visitor. For an ad pipeline, money gets spent wrong for a few hours, which stings but is bounded. For the reimbursement engine, the answer involves Medicare claims, patient data, and a clinic's trust. Three different answers. Three different amounts of care.
That is all rigor is: a budget. You have a finite amount of care to spend, and every hour of ceremony on a low-stakes repo is an hour you did not spend hardening the thing that can actually hurt someone.
Key insight
Price your process by what happens when the system fails, not by convention. If your process looks the same on every project, you are overpaying on the landing page and underpaying on the system that touches money or patients.
03What the budget buys
The same logic runs my denial-assessment engine, the system that recommends what to do with a denied medical claim. Nothing ships there until it scores at least 90 percent against a golden set of real denial cases. Getting there took a week of eval-driven tuning. Action accuracy started at 36.7 percent. Four runs later it was 76.7 percent, and it kept climbing until the gate opened. The gate costs real days. On a marketing site I would never pay it. On a system telling a biller what to do with a denied claim, I would never skip it.
And the late rounds are not theater. They are where the quiet bugs live, the ones that pass every test on my machine and fail in the one place a real person touches.
What broke
A late QA round caught the patient activation QR code building its link from the console's own address. A real patient scanning it would have landed on a corporate login wall instead of their app. It worked fine on my machine, which is exactly why the round existed.
The budget pays off on the other side too. When the gate finally opens, you know exactly what you are shipping.
The result
The denial engine's ship gate now reads 92.0% on classification and 90.7% on action against the golden set, above the 90% bar, with zero errors across the last four runs.
04The tell
The tell that someone is not pricing rigor is uniformity. The same ceremony on every repo. The same checklist. The same two approvals whether the code serves a demo or a claims pipeline. That is not discipline. That is a decision someone stopped making. Convention feels safe because nobody gets blamed for following it. But it overcharges the toys and undercharges the systems that matter.
Prices move, too. The day my site takes its first payment, it gets a new budget. The day a prototype grows a database of real people, round one begins. Repricing is not overhead. It is the job.
- 1Price every system by what happens if it fails silently for a day.
- 2Drop any ceremony that has no second party. Reviewing your own pull request is theater.
- 3Spend what you save on the systems that touch money or patients.
- 4Reprice when the stakes change. A toy holding real user data is not a toy.
- 5Write the price down, so skipping review reads as a decision, not a lapse.
The landing page is allowed to break. The reimbursement engine is not. Most of engineering judgment is knowing which one you are holding, and having the nerve to treat them differently. If you run systems on both ends of that scale, I would like to hear what your prices are. The operators who think this way need to find each other.