Technical Consulting

I work with small local businesses, where there is often no in-house technical role and the technology decision risks being delegated to whichever supplier proposed it, and with SMEs running legacy systems that are still central to the business.

A substantial part of the work is direct engagement with established in-house teams, particularly on the more technical topics: architecture choices, code review, assessing infrastructure before it becomes a constraint. There I don't replace the team — I give them a reasoned second opinion on decisions that are hard to judge from the inside.

Consulting runs either on a day-rate basis or per project, and more rarely as a one-off audit on a defined scope.

The day-rate format works when continuity is needed, for example recurring support during a migration. Per-project makes sense when the objective is bounded and verifiable. The one-off audit is the fastest format but also the most fragile: it produces a document, and its value depends entirely on whoever applies it afterwards.

Which format fits usually becomes clear in the first conversation, and it is not necessarily the one the client arrives with.

Recurring topics are choosing or reviewing the technology stack, assessing accumulated technical debt and which parts are actually worth repaying, reviewing architecture ahead of a significant piece of work, and defining a roadmap the team can sustain with the people it has.

The criterion I apply is simple: a technical recommendation your team cannot maintain over time is not a good recommendation, however correct it looks on paper.