Technical audit & project takeover

Area: Maintenance, Support & Continuous Development · Usual shape: audit first, takeover optional · The first output: a written report

The worst moment in a product’s life is when nobody left understands it. We start with an audit that says plainly what you have: what was built well, what is a risk, and whether continuing on it is cheaper than replacing it. We give that answer even when it means less work for us — because a flattering report helps nobody.

Talk to us about your project See the whole area

Opens WhatsApp. Nothing is sent until you press send there.

What this solves

The developer is unreachable and nobody dares change anything.
The system works and nobody knows how.
The build only runs on one machine.
You are about to buy into a product and need to know what it is.

What we build

A review of code, architecture, dependencies and readability.
A risk assessment ordered by priority rather than by severity alone.
A build-and-deploy check: does it run anywhere but one machine?
Documentation of what was found, readable by people who are not engineers.
A list of the access required — transferred by you, never requested as credentials.
A stabilisation plan for the first weeks.
An explicit recommendation: continue, partially rebuild, or replace.

Where it is used

The developer is unavailable and nobody dares change anything.
A system that works and nobody knows how.
A build that only runs on one machine.
A technical review before buying into or investing in a product.

What this does not include

It is not penetration testing, a certified security audit or a security certificate.
It is not a legal audit or a regulatory compliance assessment.
We do not enter code-ownership disputes or negotiate with the previous developer.
We do not ask for passwords or sign in to your accounts — we state what access is needed and you grant it yourselves.
Neither side is committed to continuing after the audit.
Mobile applications have their own continuation service, with different handover realities.

How the work goes

We agree what the audit covers and what it costs before it starts, so it cannot become the project.
We look at the build and deployment first — a system only one laptop can produce is the most urgent finding there is.
We write the report for a decision-maker, not for an engineer.
We recommend plainly, including when the recommendation is less work for us.

Ongoing maintenance & support
once the audit shows it is worth keeping.
Continuous development
when the product is sound and needs to move forward.
Spreadsheet & legacy system replacement
when the honest recommendation is to replace it.
Existing app continuation & modernisation
when the product in question is a mobile app.

Questions about this service

How long does the audit take?

Short, and bounded — we agree its scope and cost before starting so it cannot quietly become the project. What you get is a written assessment and a clear recommendation.

What do we receive at the end?

A written report of what was found, a prioritised risk list, a stabilisation plan, and an explicit recommendation. It is written to be read by whoever makes the decision, not only by engineers.

What if the recommendation is to rebuild?

We say so, with the reasoning. You are free to take that recommendation to anyone, including someone other than us — the audit is useful either way.

What access do you need?

We list exactly what is required and you grant it yourselves. We never ask for passwords and we do not sign in to your accounts on your behalf.

Do you take the product on afterwards?

If both sides agree. Commissioning the audit commits you to nothing, and we do not commit to maintaining something before we have seen it.

Tell us what you have, and who is looking after it.

Talk to us on WhatsApp Or send the details through the form