Before you sign, or rebuild everything, you need an opinion that isn't selling you anything.

Code audits and technical second opinions

When a software project goes wrong, it’s rarely down to one thing. More often it’s a pile of postponed decisions, outdated dependencies and knowledge that lives in one person’s head.

I look at the project from the outside and tell you what’s there, what you’re risking and what I’d do in your place, in order of priority. If after the audit you decide to rebuild everything, you decide with the facts in hand.

How I approach it

In recent years a lot of code has been written with AI help, and it shows in the projects I review: files and functions far longer than they need to be, generated code that was never cleaned up, the same logic repeated in several places.

The cost comes twice. The code is harder to read and fix for whoever comes next, and if the team keeps working on it with AI, every change burns more tokens than it should, because the model has to re-read all that code. The audit marks where the code can be shortened and in which order it pays to do it.

When it helps

  • You have software that half works, is slow, or nobody knows how to change any more.
  • A vendor wants to rebuild everything from scratch and you want to know if that's needed.
  • You are taking over a project from an agency or a developer who has left.
  • You are about to invest in a project and want an independent opinion before you sign.

What's included

  • A review of the code and architecture, with an eye on security, performance and maintainability.
  • Checks on dependencies, missing updates and fragile spots.
  • Assessment of third-party quotes and technical proposals.
  • A prioritised roadmap that separates what needs doing now from what can wait.
  • If needed, guided refactoring or a technology migration as a follow-up.

How it works

  1. Access

    You give me read access to the code and explain the context.

  2. Analysis

    I study the code and, where possible, run it in a test environment.

  3. Report

    A document non-technical readers can follow, with the problems found and what they mean.

  4. Discussion

    A call to walk through the report and answer questions, including your team's or your vendor's.

What you get

  • Audit report with issues, risks and priorities.
  • Technical roadmap with rough estimates.
  • On request, a written opinion on third-party proposals.

FAQ

Can non-technical people follow the report?

Yes, it's written for whoever has to decide. Technical details sit in a separate section for developers.

How long does it take?

It depends on the size of the project. After a first look at the code I give you an estimate.

Further reading

Let’s talk

info@giusepperusso-dev.it

Want to know if it fits your case? Send me a couple of lines about the problem: I reply within 24 business hours.

book a callLinkedInGitHub