DEGet in touch

Where the manual ends, I start.

From the PCB to the cap table.

Engineering since 2006. Head of Engineering at wywy through its sale to TVSquared. Co-founder and CTO of SMAHO, a connected-home platform, since 2019.

Where this usually starts

A deal waits on a technical answer

Investors, angels, acquirers, CTOs before a deal

Due diligence

Architecture review

Situation

Only the people who built it have checked the design, and they check what they meant to build.

Result

Findings ranked by risk, each with its fix.

Scope

I read your system with your team and write down what to change, in which order. Not a pentest and not a certification. If you need either, the review says so.

Terms
  • Software · Security and identity · IoT and fleet · Infrastructure
  • Three to five working days, delivered within two weeks.
  • Fixed price, set in the written scope.
A sample findings page. Each risk comes with its fix and its effort.

How it runs

  1. 1A 30-minute call about why now and which focus fits.
  2. 2Within a day, you get a written scope with a delivery date.
  3. 3Your tech lead walks me through the system as it really runs.
  4. 4I read the code, config and incident notes, and talk to your engineers.
  5. 5We go through the findings with your team, and you decide the order of fixes.
  6. 6On an agreed date, we check together which fixes are done.

What I need from you

  • Read-only access to code, cloud console and monitoring.
  • Your diagrams and incident notes.
  • Two hours with your tech lead.
  • For a device review, one unit on my desk.
Ask about this
Due diligence

Technical due diligence

Situation

A risk found after signing is yours to pay for. Found before, it goes into the terms.

Result

A one-page verdict. Every risk graded.

Scope

An independent read of the technology before money depends on it. I work for you and say so to the target. A company I review cannot hire me for 12 months afterwards. Nor do I review a company I have worked for, invested in, or that competes with SMAHO.

Terms
  • Red-flag review: 2 days · Standard: 4–6 · Sell-side readiness: 5–8
  • If the target has devices, I also review firmware, over-the-air updates, device certificates, factory provisioning and fleet management.
  • Fixed price, set in the written scope.
A sample verdict page. Every risk carries its grade and its evidence.

How it runs

  1. 1A 30-minute call about the deal, the deadline and your questions.
  2. 2Within a day, you get a written scope with a delivery date.
  3. 3I read the code and trace how it reaches production.
  4. 4I interview the CTO and the engineers who build and run the system.
  5. 5In a standard review, you hear the first findings halfway through.
  6. 6We go through the findings together, then you get the written verdict.

What I need from you

  • The target's consent to be reviewed.
  • Read-only access to code and cloud console, set up by the target.
  • An hour with each person named in the scope.
  • Each day access is late moves delivery back by a day.
Ask about this

An idea, money, no one technical

Founders before the first code

Product

MVP scoping

Situation

Every agency quote looks complete. What it leaves out shows up on the invoice.

Result

A one-page brief builders can quote against.

Scope

Before you spend money on code. You do the work between sessions; I make sure it is the right work. Go-to-market, fundraising and contracts stay out.

Terms
  • Two to four sessions over a month.
  • Fixed price, set in the written scope.
A sample founder brief. You send it, not me.

How it runs

  1. 1We start with your customer's problem, not your app.
  2. 2Before we meet again, you talk to five potential customers.
  3. 3We fit the first version to the time and money you will spend to test the idea.
  4. 4For each part, we decide whether to build, buy or hire.
  5. 5We read the quotes together.
  6. 6I sit in on your first interviews with engineers or agencies.

What I need from you

  • What exists: deck, notes, sketches, any quotes.
  • Your budget ceiling and the date that matters.
  • Who else decides with you.
Ask about this

A project stalls, or nobody finds the fault

VPs of Engineering, platform leads, device makers

Hands-on

Hands-on engagement

Situation

Your team keeps everything else running, so the hardest project gets the time that is left.

Result

Shipped and handed over, or a written stop.

Scope

I join your team and own one project until it ships, anywhere in the platform and software stack. My focus is API, backend, platform and infrastructure.

Terms
  • Three months or longer · Two to three days a week
  • Billed at a day rate.
A sample day-10 note. By day 10 you know what blocks the project.

How it runs

  1. 1Before I start, we write down the one result that counts.
  2. 2We also agree on what would tell us to stop.
  3. 3On day 10, I send you a note on what blocks the project and my plan.
  4. 4I measure first, then change things in small steps that can be rolled back.
  5. 5Every week, you get a short written status.
  6. 6Before I leave, your engineer runs it while I watch.

What I need from you

  • Access on day one and one person available that day.
  • A sponsor who clears blockers.
  • One engineer who owns the result after me.
Ask about this
Hands-on

Root cause analysis

Situation

It never shows in staging, and each guess so far has cost a release.

Result

The fault's mechanism, and a test for the fix.

Scope

A fault that staging never shows, hunted where it happens: in production, read-only at first and always with one of your engineers. On working days, answers come within hours, at the latest the next working day; there is no on-call.

Terms
  • Two to four weeks · Two to three days a week
  • Billed at a day rate.
A sample hypothesis log. Dead ends stay in it, so nobody tests them twice.

How it runs

  1. 1An intake call about what fails, since when, and where it does not.
  2. 2Your engineer walks me along the path the fault takes.
  3. 3I gather the missing data before I guess at causes.
  4. 4You get the hypothesis log, updated every day.
  5. 5The smallest case that shows the fault becomes the test for the fix.
  6. 6At the end, you get a write-up of the cause and what to change next.
  7. 7If the cause is not found in the agreed time, you get a written stop.

What I need from you

  • Access set up before day one.
  • One engineer beside me.
  • The times of recent occurrences, if you have them.
Ask about this

Agents are in, results are uneven

Engineering leads

AI agents

Agentic kickstart

Situation

Everyone runs agents their own way, and nobody has written down which decisions an agent may make alone.

Result

Agent work with rules, gates and a record.

Scope

Most teams already have an instruction file for their agents. The Kickstart goes further: who decides, what runs alone, what a person signs, and how mistakes become rules. Remote by default; the workshop on site if you want it.

Terms
  • A workshop, then weekly check-ins that fade out.
  • Fixed price, set in the written scope.
A sample rules ledger. Every rule here came from an incident in my own work.

How it runs

  1. 1I read your repositories and follow how work moves through the team.
  2. 2You get a written note on where you stand and what the workshop covers.
  3. 3In the workshop, we write down who decides and what agents may decide alone.
  4. 4Together with your team, we set up shared rules, reusable agent skills, one coordinating agent and sign-off gates.
  5. 5Every engineer runs one real task under the new rules.
  6. 6Weekly check-ins fade out as your team turns repeat mistakes into rules.

What I need from you

  • Read access to your main repositories.
  • The agent tools your team uses, and any rules you have.
  • What data may leave the company.
Ask about this

No CTO, or no one to pressure-test a decision

CEOs, founders, sole CTOs

Leadership

Interim CTO

Situation

A permanent CTO takes months to find. Until then every technical decision waits on you, or gets made by whoever is loudest.

Result

An owner for every decision, and a handover on a set date.

Scope

I lead your engineering team two to three days a week, remote by default. The end date is agreed before I start. Which decisions are mine is agreed in writing; for yours, I lay out the consequences first.

Terms
  • Three to nine months · Two to three days a week
  • Billed at a day rate.
A sample day-30 plan. Every item has an owner and a date.

How it runs

  1. 1Before I start, we agree in writing which decisions I make and which stay with you.
  2. 2You tell your team what my role is and when I leave.
  3. 3In the first two weeks, I talk to your engineers and ship a small change myself.
  4. 4On day 10, you get a short note on what I see.
  5. 5By day 30, you get a diagnosis and a plan.
  6. 6If the day-30 plan shows you no longer need me, you can end the engagement there.
  7. 7Otherwise, I lead the team and send you a written update every week.
  8. 8Your next technical lead works alongside me first, then takes over on the agreed date.

What I need from you

  • Access on day one and one person available that day.
  • An org chart, the last board deck, the budget and the incident history.
  • One hour a week with you.
Ask about this
Leadership

CTO advisory

Situation

The people who could challenge your decision report to you. A decision you cannot undo gets no second look.

Result

Decisions on record: reason, owner, review date.

Scope

A second opinion from someone who has made these decisions. I ask until the decision is clear, then recommend. You decide.

Terms
  • Single days, or a monthly retainer for at least three months.
  • I answer email questions in between within one working day.
  • Billed at a day rate, or monthly in half-days.
A sample decision record. The real ones stay in your tools, not mine.

How it runs

  1. 1Two days before we meet, you send me one page on the decision.
  2. 2I reply with the questions I need answered before we meet.
  3. 3We start by checking whether the decision can be undone.
  4. 4Then we go through the options and what each one costs.
  5. 5I give my recommendation, and you decide.

What I need from you

  • The one-page pre-read, on time.
  • Read access to your architecture notes.
  • Honesty about what is going wrong.
Ask about this

Track record: things I can talk about

Listed here: what I am free to name.

  • A company sale, from due diligence to integration

    sold to TVSquared · delivery kept stable through the integration

    I prepared wywy for the sale and for the buyer's technical due diligence. Afterwards I merged our infrastructure into the acquirer's platform and brought two engineering cultures together. The review decides the deal; the year after decides whether it was worth doing.

  • Built the engineering organisation, then joined it to the buyer's

    15+ engineers across Munich and Edinburgh · strategic planning and budget with the CEO and COO

    I built the platform team and later also led the product team. After the sale I flew to Edinburgh regularly for management meetings and worked on making the wywy team and TVSquared one team across both sites. An organisation counts as built when it runs the same in the weeks I am away.

  • Strategy and roadmap through a broken supply chain

    component lead times from under 10 days to over 50 weeks · manufacturing moved outside the embargo

    As CTO I plan the app, the platform, the infrastructure and the hardware as one roadmap, component sourcing included. I take that roadmap to shareholders, investors, customers, vendors and integrators myself. When a container ship blocked the Suez Canal, our component lead times went from days to almost a year, and a US embargo on CPUs later cut off our manufacturer in China. We bought stock ahead and moved production to a manufacturer outside the embargo. On a hardware product, the supply chain sets the roadmap as often as the customer does.

  • An angel who stays in the room

    product discovery · interim CTO · the first engineering hires · launched on Product Hunt, October 2026

    In from the start: product discovery, then interim CTO work, stepping up to help wherever the build needed technical leadership. Later I interviewed and hired the first engineers, stayed available as a peer, and handed them the role. Shareholder since day one.

  • Routine work handed to agents, across the whole team

    app releases run by agents · natural-language control live in the app

    Agents draft routine work and support answers, and scheduled agents write a weekly report on the organisation. Reversible changes they make alone. Anything irreversible goes to a person as a written decision record, which is where I would draw the line at any company.

  • Built with AI agents, end to end

    quest app · website · operations dashboard · city-scoring model · content pipeline with 30 workflows

    A written city adventure played out on real streets. One person, end to end: product, platform, app. The content pipeline runs on LangGraph, and nothing ships without a human reading it first. The project where I build the way I advise others to.

  • Our own hardware, from a partner's board to a factory line

    thousands of devices in the field · updated and diagnosed remotely

    We took a design partner's board to a factory line, and the app into both app stores. Firmware and provisioning stayed in-house, and so did device security. A company that sells a device should own what runs on it.

  • No key-person risk in the infrastructure

    rebuildable from git alone · every change reviewed before it ships

    Nothing in it depends on what is in my head. An investor should ask every CTO about this, and the answer should be boring.

  • Login and permissions replaced under live customers

    thousands of devices and users · no downtime

    The new system ran alongside the in-house legacy one until both gave the same answers, then took over. Running both costs time, and it buys a switch customers never notice.

  • Ten to twenty times the work from each server

    per-server ceiling on live feeds removed

    The engine recognised TV commercials the way Shazam recognises songs. I led the team that rewrote it in Go. Over the Python original the gain was ten to twenty times, depending on transponder size and algorithm. A rewrite earns its cost only when it removes a ceiling.

  • Four datacenters run as one, with no maintenance windows

    Munich · New York · Oakland · Tel Aviv

    Our own private cloud. New servers joined on demand and set themselves up from their hardware profile. Capacity that sets itself up is capacity nobody has to schedule.

  • Hundreds of live TV feeds on a fraction of the hardware

    several racks → a few rack units

    With R&D in-house, our own servers replaced the proprietary receivers, and channel capacity could grow. Owning the hard part kept growth in our own hands.

  • A page meant a real fault

    on-call for a platform with no maintenance windows

    A satellite signal lost to bad weather recovers on its own. Monitoring learned to tell that from a real fault and stopped paging anyone for it. People answer a pager that is rarely wrong.

Principles, and the trade-off I accept.

Shift left

Checks fail a bad change at review, before it ships.

Trade-off I accept: Work lands early, before anything looks broken.

Boring by design

No downtime: the new system runs alongside until both agree.

Trade-off I accept: Running both adds weeks.

Agents with a human sign-off

Agents do the mechanical work; irreversible changes go to a person. I design what an agent may do as carefully as what it can do.

Trade-off I accept: Each sign-off slows the work, on purpose.

The seams are the work

Components are cheap now; agents write them. The decisions that matter sit where pieces meet: what context exists, where state lives, who owns the outcome. That is where I spend my time.

Trade-off I accept: Visible progress starts later.

The simplest thing that holds

As few parts as the job needs: less to run, less to fail.

Trade-off I accept: I give up the elegant design.

Calibration

First call: what I have done, and what would be new.

Trade-off I accept: Some engagements go to someone who promised more.

Discretion

Your name stays off this site unless you agree.

Trade-off I accept: No client logos here.

Inside the team

I sit in the repo, the standup and the incident channel.

Trade-off I accept: It caps how many engagements run at once.

What you can count on

Every open risk gets an owner and a date.
Your team runs what I build after I leave.
If something is not working, you hear it from me first.
Portrait of Max Köhler

Where the range comes from.

The work I want
The problem you have already escalated twice.
SMAHO
Co-founder and CTO since 2019, strategic decisions shared with my co-founder. Technology and product, from the first commit to production, hardware included.
The range
The label for this keeps changing. The work stays the same: I move between domains and make the call where the pieces meet.
Engagements
Independent since 2019, never competing with SMAHO or a running engagement.

Tell me what is going on.

A short email: what is stuck, by when, who decides.

SMAHO is my main role, so I take few engagements, and at most one of two to three days a week. I usually start within weeks, once contracts, NDAs and onboarding are done. If access is ready, I can start within three days, for a surcharge.