About

Most of my work is for manufacturers and engineering companies — organisations where software is not the product but the thing the product depends on. That shapes how I build. A line does not stop because a deployment went badly, and a system that needs the network to be up is a system that will fail on the day it matters.

I work in two ecosystems. Ruby on Rails, for the applications people use all day and that have to keep evolving for years. And .NET, for the services that sit against the equipment, where devices fail independently and constantly and each one needs to fail on its own.

A lot of the work starts as a replacement. Access databases that grew into departmental systems, mod_perl and VB6 applications maintained by one person, tools built around a file format someone chose in 1999 — software that still works, which is precisely what makes it awkward to replace. I've spent enough time reading proprietary and legacy stores to be relaxed about it: PDM and CAD databases, ERP tables, project files, mail archives. Getting the data out intact is usually the whole job.

Working in both is unusual, and it's deliberate. When one platform spans a factory floor and a reporting dashboard, being fluent at both ends means each layer can use the runtime that actually suits it, instead of the one I happen to know.

PostgreSQL, by default

Almost everything I build stores its data in PostgreSQL, and not out of habit. Nearly every project on this site leans on something it does that a generic SQL store doesn't: JSONB holding survey configuration and computed scores as the source of truth, PostGIS answering whether a vessel is inside a zone as real geometry rather than a bounding-box guess, full-text search across an asset register, and time-series extensions under plant telemetry.

The practical benefit is fewer moving parts. A second datastore is another thing to deploy, back up, monitor and keep consistent, and in my experience reaching for one is usually a sign the first was never fully understood.

Down to the equipment

I also work below the application layer, on the automation itself — mainly Siemens PLCs and Fanuc robots. That started with end-of-line measurement systems in automotive, where the software has to keep pace with a moving line, and it has stayed useful ever since.

It matters more than it sounds. Most integration problems between a plant and its software are not really software problems: they are disagreements about what the equipment can actually provide, how often, and with what guarantees. Having written the PLC side as well as the application side, I can usually tell which half of that conversation is wrong — and I can propose a change on the controls side rather than working around it forever in the application.

The same goes for connected products rather than plant equipment. I've worked on electronics in the field reporting back to a service — EV charging equipment among them — where the constraints are different again: no engineer on site, intermittent connectivity, and a device that has to behave sensibly on its own for long stretches.

I take projects end to end — architecture, implementation, and the deployment pipeline that puts them in production. I'd rather own the whole path than hand a repository over a wall. This site runs the way my clients' systems do: containerised, deployed with Kamal, on a server I maintain.

Open source

resource_form is a Rails form builder that detects which CSS framework an application uses and renders the matching partials, so forms stay declarative instead of accumulating framework-specific markup.

ostsearch gives full-text and semantic search over Outlook mailbox files. An offline pass indexes the mailbox into SQLite; a local, read-only server then answers queries from any MCP client. Nothing leaves the machine.

DynDaCo BV

DynDaCo is short for Dynamic Data Consulting. I picked the name in 1998, and it has turned out to describe the work better than most names manage: nearly every project on this site is some version of getting data out of a place it was stuck — a PLC, a proprietary database, a mailbox, a drawing archive — and putting it somewhere it can be used.

It is a Belgian limited company, incorporated that same year. Contracts, invoicing and liability sit with it; the work is mine.