Zurich, Switzerland · On-site or remote

AI automation and embedded engineering.

Two practices, one engineer. I automate the slow, manual steps in how your team works, and I design and debug the hardware and firmware your products run on.

How I work

Understand first, then build.

  1. Understand the problem

    On site or on a call: how the work gets done today, or what the device has to do.

  2. Propose and scope

    A concrete plan and a fixed quote: what to automate first, or a written spec for the build.

  3. Build and test

    The automation, board or firmware, verified against your real data and hardware.

  4. Handoff and support

    Source, files and documentation your team owns, with follow-up support after launch.

Services

Two practices, equal weight.

Most teams need one of them. Some need both: automation that has to run on real hardware.

AI automation

Automation built around how your team already works, not a standard product.

Starts with a Workflow Audit

AI Workflow Automation

I find where AI and scripting remove real effort in your workflows, reports and test runs, then build it.

  • Workflow and reporting automation
  • Test and verification pipelines
  • AI tooling: where it fits, and where it does not

2 hours or half-day · On-site or remote

AI Automation Workshops

A live session for your team, not a slide deck: hands-on in a prepared lab, then a prototype built live on a problem your team names.

Within 48 hours you get 2–3 written recommendations. The fee is credited toward follow-on work booked within 30 days.

Embedded engineering

Hardware and firmware for a specific job, from the first spec to a working prototype.

Starts with a paid scoping

Custom Development

Microcontroller boards and the firmware that runs on them, built for one application: schematic, layout, firmware, bring-up and test.

  • KiCad schematic and PCB layout
  • Firmware in C/C++, bare metal or RTOS
  • Release files and source you own

Scoping ends in a written spec and a fixed quote; its fee is credited toward the build.

Fixed price · Written report

Hardware & PCB Review

A second pair of eyes before the money is spent, or a structured root-cause analysis when a board misbehaves.

  • Schematic and layout review
  • Board bring-up support
  • EMC-relevant design factors

Examples

What this looks like day to day.

Typical situations, not client case studies.

The Friday report nobody wants to write

Today
Logs are exported, pasted into a spreadsheet, and rebuilt by hand every week.
After
A scripted step produces the report. Nobody loses an afternoon to it.

Test runs that only happen when someone remembers

Today
The suite runs manually, days after the change, if at all.
After
It runs on every change, so a regression points to the commit that caused it.

Knowledge that lives in one inbox

Today
Decisions and their reasoning sit in chat threads and personal folders.
After
Searchable documentation is written as the work happens and survives handovers.

A module that almost fits

Today
An off-the-shelf board is close, and the workarounds cost more with every batch.
After
A small custom board and firmware made for the one job, with release files you own.

A board that fails one test in ten

Today
Intermittent resets. Everyone has a theory, nobody has measurements.
After
A structured root-cause analysis: measurements, a written cause, a layout or firmware fix.

A layout about to go to fab

Today
The review is skipped to save a week, and the respin costs a month.
After
Schematic and layout checked before the money is spent, findings ranked by severity.

Get in touch

Tell me what you are working on.

A workflow to automate or a device to build: a short form, then a free initial call to see whether there is a fit. No commitment.