Technical and architecture audits that produce a decision

For founders and CTOs before a rewrite, a vendor or an AI programme.

An independent reading of the system you have – aimed at a decision, not a severity-coloured spreadsheet.

You leave with

Decision memo

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.

See it done

Genie Platforms · AI SDRConversational AI running as production services Mindshine · TIVAVoice and text retrieval across any data source

See more details

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.

Serviços relacionados

Notas relacionadas

Perguntas que me fazem

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.

Commission a review against a named decision

Say what you are trying to decide. An audit without a decision is a document nobody will use.