← Back to home  ·  Practice / Audits, due diligence & executive advisory

The truth,
in writing.

Codebase audits, organizational diagnostics and confidential reports for the people who have to decide — written by a senior who reads the entire code personally and can defend every line of the findings in front of your engineers.

/ 01 — The problem

Status reports say green.
Reality disagrees.

Somewhere between the codebase and the boardroom, information changes shape. Delivery problems become "minor delays." Architectural debt becomes "technical considerations." A provider's interests quietly become indistinguishable from yours. And decisions worth millions get made on filtered information.

The fix is old-fashioned: an independent senior who reads the actual code, interviews the actual people, and writes down what is actually true — in language engineering can't dismiss and the board can't misread.

/ 02 — What I do

Read the code.
Read the organization.

Four instruments, often combined in one engagement. The findings hold up because I still build and ship systems myself — this is an engineer reading your code, not a slide deck. The signature pattern — a codebase audit followed by an organizational diagnostic — produced findings a Fortune 500 client valued at ~€2M in new contracts.

/ 01

Codebase & architecture audits

I personally study the codebase — not a sampled checklist, the code — and report on architecture, quality, risk and maintainability. Shippable to investors, steering committees and courts of hard questions.

Done for Fortune 500 strategic applications where recurring delivery problems had no visible cause.

/ 02

Organizational diagnostics

When the code alone doesn't explain the problem: structured interviews with directors and engineering teams, process mapping, and a confidential report on what is actually happening between people, teams and incentives.

Includes full DevOps investigations — environments, promotion lifecycles, runbooks, tooling — across entire product portfolios.

/ 03

Client-side provider oversight

Hired by clients to keep their providers honest: reviewing deliverables at code level, discovering risk early, running verification phases, and distinguishing the provider's interests from yours before they diverge expensively.

22 years on both sides of the SOW make the games easy to recognize.

/ 04

Due diligence, pre-sales & SOW

Technical due diligence on software assets and teams. Strategy engagements — platform selection, ERP recommendation, data monetization. And for consultancies: proposal architecture and SOW authorship by someone who has personally signed every SOW of a 25-engineer division.

Every clause carries technical consequences; I write and read them accordingly.

/ 03 — Engagement shapes

Weeks of work.
Years of clarity.

Fixed scope, agreed up front, 100% remote in English or Spanish. Confidentiality is the default — most of this work is never publicly attributable.

/ Shape · 01

Focused audit

One codebase, one architecture or one database estate. Findings, risk and recommendations in weeks — the standard first engagement.

/ Shape · 02

Full diagnostic

Code plus organization: the dual-report pattern for situations where delivery keeps failing and nobody agrees on why.

/ Shape · 03

Oversight retainer

Standing client-side review of a provider or critical program: deliverable review, milestone verification, and early warning when reality drifts from the plan.

/ Shape · 04

Executive technical advisor

Direct, confidential counsel to a CEO, CTO or board — the senior second opinion for decisions that are too expensive to get wrong.

/ 04 — Proof

Reports that
moved money.

A selection from the full project history — the most sensitive engagements in this practice are NDA-bound and absent by design.

/ 06 — FAQ

Asked before
trusting anyone.

Independence questions deserve straight answers — here are mine.

How is your independence guaranteed?

I'm paid by you and only you. I don't resell software, I don't take referral fees from vendors, and I don't bid on the implementation my own audit recommends unless you explicitly ask me to. The report's only loyalty is to what the code and the organization actually show.

What does the deliverable look like?

A written report with two audiences in one document: findings and evidence at engineering depth, conclusions and options at board level. Direct language — what is true, what is risk, what to do — defensible enough to forward to investors or a steering committee.

How long does an audit take?

Typically weeks, with scope fixed up front. A focused codebase or architecture audit is faster; a combined technical-plus-organizational diagnostic — reading the code and interviewing directors and teams — takes longer but answers the deeper question.

Can you audit a provider we suspect is underdelivering?

Yes — client-side provider oversight is a recurring engagement: code-level review of deliverables, risk discovery, verification phases, and separating their interests from yours before the divergence gets expensive. Done professionally and factually; the goal is a working relationship, not a war.

Need to know
what's actually true?

Describe the decision you're facing and what you suspect. The scope, the timeline and the price of finding out are all fixed before we start.