CASE 01
Odoo ERP
Second developer on a corporate ERP: custom modules, integrations, access control and the reliability of the server it all runs on.
Problem
The security plan was half done: access was locked down, backups were not. For a month the only copies of the production database — payroll, contracts, 36 users — were two manual dumps on the same disk. There was no monitoring at all, so problems arrived from people rather than from the system.
What I owned
I own infrastructure reliability, the access model and the inbound lead flow. I work alongside a second developer and make the infrastructure calls myself. Development is AI-assisted: I set the task and accept the result, and every release goes out after the tests have run against a copy of the production database.
System
- 01Off-site encrypted backups every 4 hours with a different provider, restore tested
- 02Monitoring built from nothing: collection, alert rules, messenger notifications
- 03A status page in two places — inside the ERP and standalone in nginx, alive when the ERP is not
- 04Production moved to multi-worker mode by script, with checks and a one-command rollback
- 05A role catalogue in place of per-user assignments: 116 → 55, nobody's rights changed
- 06Inbound leads from four channels merged into one CRM pipeline
- 07Secret scanning in the delivery pipeline, before the push and again in CI
- 08The deploy fails if a module upgrade silently did not apply
Result
The defining episode: for eight days one of the Odoo processes was crash-looping — around 1,150 restarts a minute, 80% of a core — and nobody could see it, because the login page answered 200 the entire time. Chat and live notifications were dead. I traced it to how the process was being launched, fixed it and put a watchdog on that port: CPU fell from ~80% to ~6%, with zero crashes since. The lesson I now apply everywhere: checking the front page is not a health check — every process a user depends on needs its own watchdog.