How I work

Four steps, in this order. Each one produces something you keep, even if we stop there.

  1. The discovery call

    30 minutes · free

    You describe your system, your constraints and your deadline. I ask questions, and before the call ends I tell you whether I am the right person. Sometimes the answer is no, and it is better heard straight away. No sales pitch.

    • What you are trying to achieve, and by when
    • What already exists: hardware, code, measurements
    • What is blocking you today
    • Who decides, and on what grounds
  2. The instrumented feasibility study

    3–5 weeks · fixed price

    I take your problem apart and hand you an architecture, a risk analysis and a feasibility verdict backed by a demonstrator, presented in a second meeting. The deliverable is yours: you can have it built by your own team, by another contractor, or by me.

    • System architecture and hardware / software partitioning
    • Technology choices, argued, with their alternatives
    • Risk analysis: what could derail the project
    • An argued feasibility verdict, and the demonstrator that proves it
    • Build order, milestones and effort estimates

    The study in detail

  3. The build

    iterative · fixed price or day rate

    I write the code. Firmware, machine control, real time, GPU computing, business software, web interfaces, AI agents, whatever the project calls for. Each iteration ends with a demonstration on the real hardware when it is available, on a model when it is not.

    • Short deliveries, each one verifiable on its own
    • Code in your repository from day one
    • One progress review per iteration, in plain language
    • What is not working is said before it gets expensive
  4. The handover

    included

    A project nobody knows what to do with has not been delivered. You leave with the sources, the build and commissioning procedures, the documentation, and a handover session with your team.

    • Sources, build and deployment scripts
    • Architecture and commissioning documentation
    • Handover session with your team
    • No dependency on me to run what you paid for

Four principles

I know how to say no

A badly scoped engagement costs more than a declined one. If your need belongs to another trade, or the budget cannot carry it through, I say so on the first call.

The hardware decides

Machine control and firmware are not validated in meetings. I work on the real machine as early as possible, and on a model that reproduces it when it is unavailable.

Nothing that locks you in

No proprietary formats, no licence to renew, no dependency on my calendar. The code lives with you, and it builds with you.

Confidential by default

Your process data, your settings and your product specifics never leave the project. A reference appears on this site only with your written consent.

AI in my work, and where it stops

I use generative AI every day: writing and reviewing code, exploring variants, working through test data. It changes how much ground one person can cover in a given time. It changes nothing about who answers for what you are handed.

  • On your sensitive data I work with self-hosted models, on my own machine: nothing goes to a provider.
  • None of your files, settings or code is used to train a model.
  • You can require this when quoting: it is then written into the contract, like confidentiality.
  • Whatever a model produces is read, tried and checked before it reaches you. The mistake stays mine.

The AI process audit & integration

The result can be open

When part of the result can be released as open source or open hardware, it becomes a building block I reuse for other clients, and the price drops accordingly. It is an explicit trade, discussed when quoting, never imposed. Whatever gives you your edge stays closed, of course.

See the open-source discount

Book a call

Thirty minutes, free, no commitment. If I am not the right person, I tell you before the call ends.

Book a call