In acceptance testing
Insurance sub-agents manage clients, agreements with insurance companies, policies, due dates and payments across scattered Excel files. Every piece of information lives in a different file, and nobody has the full picture.
A subscription platform where each intermediary has their own space, with data kept separate from everyone else’s. Three areas: one for the intermediary, one for their policyholders and one for whoever runs the platform.
Upgrading takes effect immediately and shows the proration before you confirm. Downgrading happens at the end of the period, so you get full use of what you already paid for. Cancellation is never immediate, and if Stripe sends the same notification twice, the second one is ignored.
After a Livewire upgrade, one type of field had stopped sending its value to the server, with no error on screen. The result was wrong amounts. I tracked it down and fixed it in all 23 places where it appeared.
On the staging server some €650 amounts were being reset to zero, while locally everything ran smoothly. The cause was messy real-world data that didn’t exist in development.
Since then I follow a fixed rule: first I write a test that reproduces the server’s state, then I fix the code. And for data that is already damaged, I write a command that repairs it.
I measured 21 database queries per imported row and brought them down to 10. A test fails if the count goes above 12, so the problem can’t come back. Files are processed in chunks of 250 rows, and the system even recognises Apple Numbers files disguised as .xlsx.
The email sign-in code always responds in the same amount of time, so nobody can find out who has an account. Password recovery works the same way and never reveals which emails exist. And the policyholder app never stores private pages on the device, because a phone can be shared.
An extension to 2050 kept failing for no obvious reason. The column type used for dates doesn’t go past 2038, so I replaced it where needed.