Software developer · Lomé & remote
Service 03 — Audit & technical advice
An outside opinion before you commit the budget
Taking over a project left by a provider, choosing between two architectures, understanding why the application slows down, reviewing a quote you can't evaluate: I analyse what exists and hand you a written, costed and actionable opinion.
- 3 to 10 days depending on scope
- Written report & debrief
- No commitment to what follows
- 3-10 d
- the length of an audit, depending on the size of the scope
- 1 page
- of summary for decision-makers, at the top of the report
- 0
- commitment to what follows: the audit is sold and read on its own
They trusted me
Your challenges
You have to decide without the facts
- 01
A project to take over
A provider has left, and nobody knows whether the code they leave behind is usable or fit for a rewrite.
- 02
A quote to evaluate
You have a technical proposal and a price, without the in-house skills to judge whether either holds up.
- 03
An application slowing down
The same screens take three times longer than a year ago, and the servers cost more every month.
- 04
A doubt about security
You handle customer data or payments, and nobody has ever looked at the subject closely.
Scope
The questions I work on
Code & architecture audit
The real state of the codebase: technical debt, coupling, tests, abandoned dependencies. And above all what it costs to carry on rather than rebuild.
Performance audit
Where the application loses its time: cascading queries, missing cache, missing indexes, server sizing. With before-and-after measurements.
Security review
Authentication, permissions, exposure of personal data, plaintext secrets, vulnerable dependencies, backups that can actually be restored.
Second opinion on a proposal
You have a quote or an architecture proposal and don't know whether they are realistic. I read them with you and give you the questions to ask.
How it runs
How an audit works
Day 1
Scoping & access
Exactly what you want to know, and which decision the audit has to serve. Read access to the repository and production, and to the people who know the subject.
Days 2 to 8
Analysis
Reading the code, the architecture and the infrastructure, measuring the hot spots, short interviews with the developers. Every finding is backed by evidence in the code.
Last day
Report & debrief
The report is delivered, then an hour of debrief with your technical teams and a slot for the decision-makers. Questions get answered there, not by email three weeks later.
The deliverable
A report your management can read
A one-page summary
For decision-makers: the three main risks, their concrete impact, and what I recommend.
The technical detail
Ranked by severity, with the evidence in the code and the proposed fix for each point.
A remediation plan
Costed in days and prioritised, separating what is urgent from what is desirable.
A one-hour debrief
With your technical teams, so the report doesn't end up in a drawer.
The audit is sold on its own. If you want the follow-up, it is the subject of a separate proposal — and you are free to hand it to someone else.
Why work with me
Three commitments I keep on every engagement
- 01
You talk to the person writing the code
No salesperson, no middleman, no junior swapped onto your project after signature. Whoever scopes the work is whoever delivers it.
- 02
You stay the owner
Code, infrastructure, accounts, documentation: everything sits with you. You can change provider without starting over.
- 03
I say no when I should
If an off-the-shelf tool or three days of advice solves your problem better than custom development, I'll tell you — even when it costs me the engagement.
Frequently asked
What people ask before we start
What access do you need?
Read access to the repository, the ability to run the application, and an hour with whoever knows the code best. Without access to the code it is no longer an audit, just a conversation.
Do we then have to give you the fixes?
No. The audit stands alone and the remediation plan is written to be executed by any team, including the one that wrote the code.
Is the report readable by a non-developer?
The summary is: it is written for a management team. The technical detail is meant for your developers or your provider.
Do you also audit a provider's work mid-engagement?
Yes, and without prejudice: the point is to give you facts and questions to ask, not to name a culprit.
Tell me what you have to decide
I'll answer within 48 hours with the audit scope I recommend, its length and its price.
Get in touch