Work

Context. The critical database of a multinational group: 1 TB, heavy nightly batches, and growing costs on its current tier.

Constraints. A production system with tight windows: batch times could not get worse, and every step needed a way back.

Decision. I validated the tier change with benchmarks on the real production batches, run together with the Data & Analytics team, before touching production. Every phase had its own rollback plan, and after the cutover a nightly watchdog kept an eye on the batches through the first weeks.

Outcome. The migration reached production without incidents, and the savings run to five figures a year.

Context. A growing multi-tenant estate, where each new tenant's infrastructure risked being born as its own project.

Constraints. Standards had to hold across every tenant without blocking ongoing projects, and a mistake in a shared module reaches everyone who uses it.

Decision. I built an internal library of reusable Terraform modules, with semantic versioning, changelogs and canary releases. On top of it I put an onboarding template, so a new tenant starts from a known configuration. Pipelines cover validation, deployment and drift audits, and a check flags deprecated modules still in use.

Outcome. Onboarding a tenant became a repeatable procedure. Drift is found by the scheduled audit.

Context. An estate that grew alongside the platform, with approaches that were the standard of their day: legacy access policies on various objects, admin credentials where managed identities are used today, database access still on SQL logins.

Constraints. Everything in production: no downtime was acceptable, and every change had to be reversible.

Decision. I worked in modernisation campaigns, always with the same method: inventory, changes generated as reviewable scripts, rollback ready. Access policies moved to RBAC, credentials to managed identities; for the SQL logins an explicit cycle: inventory, disable, thirty days of observation, then the drop.

Outcome. Dozens of resources moved to the current standard with no downtime, and every step could be undone at zero cost.

Context. A training firm with its courses in a management system and its catalogue on a WordPress site: two systems kept aligned by hand.

Constraints. The management system stays the source of the data and the site must expose nothing: no public endpoints, no tokens in the browser. All of it inside the firm's WordPress and Elementor ecosystem.

Decision. I wrote a plugin that syncs the courses from the management system's API, with scheduling, a lock, backoff on errors and guard windows; it detects changes via hashes and groups sessions by course. Enrolments travel server-to-server, and development runs on local fixtures.

Outcome. The catalogue updates on its own and enrolments reach the management system with no exposed surface. The firm publishes courses without touching the site.

Context. The management system for my personal finances. Born as a backend for agents with MCP as its interface, grown into a full product: a Fastify and TypeScript backend on PostgreSQL, a React frontend, multiple ledgers, budgets, a financial month with a configurable cut day.

Constraints. It is real financial data: agents get scoped permissions, and destructive operations are born dry-run.

Decision. Banks come in via PSD2: the sync stages transactions, categorises them with deterministic rules and reconciles them; whatever stays ambiguous lands in a review queue, and transfers between ledgers are recognised as such. Agents remain a first-class interface via MCP.

Outcome. In production in my homelab, in daily use.