Skip to content

Approach

How the work actually runs

Consulting goes wrong in predictable ways: recommendations written without reading the code, long silences followed by a big reveal, and a handover that leaves the team unable to maintain what was built. These are the commitments that prevent that.

  1. 01

    Understand before changing

    Every engagement starts by reading the code, the pipeline, and the bug tracker. Recommendations come after evidence, not from a template. You get a written summary of what I found — including the parts that are already working well.

  2. 02

    Ship in small, visible increments

    Work lands in reviewable pull requests against a backlog you can see. No months-long silence followed by a big reveal. You can stop, redirect, or reprioritise at any point without losing what has already been delivered.

  3. 03

    Leave it maintainable

    The goal is a codebase your team owns, not a dependency on me. That means documentation, conventions that match your existing stack, and a handover where your engineers can walk through the work and change it confidently.

What an engagement looks like

  1. Intro call

    Thirty minutes. You describe the symptom, I ask questions, and we work out whether this is something I can genuinely help with. If it isn't, I'll say so and point you somewhere better.

  2. Scoping

    A short written proposal: what I'd do, in what order, what you receive, and what it costs. No open-ended retainers dressed up as projects.

  3. Delivery

    Work lands in reviewable pull requests with a demo at regular intervals. You see progress continuously and can redirect at any point.

  4. Handover

    Documentation, a walkthrough with your engineers, and a written summary of what changed and what I'd do next. The work outlives the engagement.

Principles I hold to

  • Tests that fail for a reason — no blanket retries to hide flake
  • Conventions that match your existing codebase, not my preferences
  • Plain-language written updates, not status theatre
  • An honest 'this isn't worth doing' when that's the right answer
  • No lock-in: no proprietary frameworks, no dependency on me

Let's talk about what you're building

A short conversation is usually enough to work out whether I can help, and what the first useful step would be. No pitch deck, no obligation.