I turn research into working systems: prototype quickly, prove it with tests and data, then ship it carefully. Every claim below links to the write-up behind it.
Start with a proof of concept, measure it against the real problem, and keep only what earns its place.
Evidence: A browser test suite and a report builder both began as proofs of concept in March and became tools I rely on.
Read the test suite note →Study the system before changing it: seam maps, dated decisions, a risk register, and an honest statement of what is out of scope.
Evidence: A written plan for upgrading a large application that had almost no automated tests.
Read the plan →When the logic is a table, generate the code from the table, then spend the saved time reviewing the table.
Evidence: More than two thousand role checks generated from one permissions matrix, alongside a few hundred hand-written workflow tests.
Read how →If the evidence you need does not exist, build the thing that produces it.
Evidence: A resumable exporter with an audit log and progress report, and a read-only CRM backup with a browsable app on top.
Read the backup note →A tool that explains itself gets used. A system that reports where time goes gets fixed.
Evidence: A debug panel showing the exact payload and SQL, and dashboards splitting timeouts by request type.
Read the report builder note →Done means proven. A read-only check of what landed beats a hopeful log.
Evidence: After a very large file migration, a scan counted rows by category and status, and found real files the local log had missed.
Read the migration →I use AI coding assistants to read unfamiliar code, draft plans and run QA checklists, and I treat what they write the way I would treat a pull request from a new teammate: reviewed, tested, and owned by me. The same habits that make a plan trustworthy make an assistant's output trustworthy.