Diese Seite ist auf Englisch. Eine Übersetzung gibt es noch nicht; kanonisch ist die englische URL. Englische Seite öffnen

Technical and architecture audits that produce a decision

I run technical audits and architecture reviews for companies that need an independent reading of a software system before they fund a rewrite, a vendor, a fundraising narrative, or an AI programme. The output is a decision: what to do in what order, what not to do, and what evidence that recommendation rests on. I read the repository, the deploy path, the incidents, and the workflow. I do not produce a 200-item lint dump. You can commission this as a fixed-scope review or as the first phase of an implementation engagement.

Who this is for

Founders and CTOs before a major spend (rewrite, vendor, AI, acquisition integration).
Engineering leaders who need an external voice in a stuck architectural argument.
Operators doing technical due diligence on a product company — with the caveat that I am one senior engineer, not a Big Four team.

When an audit is the right artefact

Two internal factions have already chosen stacks; you need a third view grounded in the code.
A vendor proposal is sitting on the table and nobody can falsify it.
You suspect the bottleneck is not 'more developers'.
AI adoption is a board topic and a production topic at the same time.

Scope I will take

Architecture and code review of a product or platform.
Delivery and operability: CI, environments, observability, incident shape.
Legacy and CMS estate: what can be strangled vs what is actually fine.
AI / LLM readiness: data, contracts, cost, and whether the use case exists.
A written brief for executives that does not insult the engineering team.

How the audit runs

Access, a short kickoff to name the decision you need, then a time-boxed reading of the system. I will tell you on day one if the access is insufficient to support a strong recommendation. Findings are ordered by the decision, not by CVSS theatre. You get a readout and a document. Implementation is a separate agreement if you want it — I will not smuggle a build contract into an audit.

Audit dimensions

I use the same dimensions I would use if I had to take the pager afterwards.

Fit to constraint

Does the system shape match the actual bottleneck, or last year's fashion?

Correctness under failure

Idempotency, validation, jobs, and what happens when a dependency dies.

Change cost

How expensive is a typical feature, a schema change, a new engineer?

Security and data

Authn/z, secrets, tenancy, and — for AI — what leaves the boundary.

Operability

Logs, traces, deploys, rollbacks, ownership. A system nobody can debug is already down.

Evidence quality

What I could verify in the timebox versus what remains a hypothesis. I will label both.

What I will not do

Fake scoring that implies a scientific precision we do not have.
A tool-only SAST dump passed off as architecture work.
A report designed to scare a buyer into a rewrite I then sell.

Deliverables

A decision memo: context, findings, options, recommendation, risks.
A technical appendix the engineering team can argue with.
A suggested 30/90-day sequence if action is warranted.

Ausgewählte Arbeit

Genie Platforms — KI-Verkaufscopiloten, die Outbound, Nurture und RevOps zusammenführen — ohne die bestehende Instrumentierung aufzugeben.
TIVA — Sprach- und Textsuche im Hintergrund, dort wo Teams bereits arbeiten — kein weiteres isoliertes Suchfenster.

Fragen, die gestellt werden

Is this technical due diligence for an acquisition?

I can contribute an engineering reading. I am not a financial or legal diligence team, and I will not sign a report that pretends otherwise. For a full buy-side process you still need the rest of the table.