Technical audit
Fragile software: 15 signs you urgently need a technical audit
Recurring incidents, unpredictable releases, drifting cloud costs: fifteen signals showing when to audit an application, and what an audit should deliver.
The short answer
A technical audit becomes urgent when problems keep recurring with no clear cause, every release is risky or only one person understands the system. It should produce verifiable findings and priorities before you commit to fixes or a redesign.
- Look at five areas: production, delivery, architecture, the team and costs.
- A useful audit produces a prioritised report and a findings meeting; fixes are priced afterwards.
- At CUB3, auditing one application and one repository costs €2,000 to €4,000 excluding VAT, with the budget confirmed after scoping.
- UnderstandCode, access and journeys
- SecureBackups and version control
- RelaunchUseful features and tests
Establish the facts before fixing
An application can keep working while becoming fragile. Incidents are resolved one by one, releases take longer, costs rise, but nobody can say why. At this stage, adding a developer or launching a redesign often amounts to deciding without a diagnosis.
A technical audit establishes findings on the code, architecture, dependencies, security and operations, then ranks them by priority. The fifteen signs below, grouped into five areas, indicate when this review becomes urgent. Several signs in the same area deserve a closer look.
In production: incidents keep recurring
These signs show that the application is not observable. Without usable logs, error tracking or rollback, every incident is handled blind. The audit checks what is measured, what is backed up and what can be restored.
- The same incidents return after every fix.
- Nobody is alerted until users report a problem.
- Rolling back to the previous version is impossible or has never been tested.
In delivery: every release is a risk
When a team hesitates to release, the problem rarely lies in its motivation. Manual deployments, a lack of tests and environments that differ from production make every change uncertain. The audit identifies what makes releases risky and what should be made reliable first.
- Timelines become unpredictable, even for small changes.
- Production releases are done by hand, often outside working hours.
- The list of pending fixes grows faster than it shrinks.
In the architecture: one change breaks another
Code can be old without being fragile. The useful signal is the effect of changes: if a local fix breaks features far removed from it, the boundaries between parts of the system are blurred. Outdated dependencies add a security risk and complicate every update.
- A local change causes regressions elsewhere in the application.
- Some dependencies are no longer maintained or have not been updated for a long time.
- Nobody can confirm that the code in production matches the repository.
In the team: knowledge rests with one person
The most underestimated risk is human. When only one person knows how to deploy or understands the business rules, their departure can halt further development. At Macq, on the TRADEMEX project, CUB3 brought in a specialist who already knew the product, to ensure continuity after a key departure and pass that knowledge on to the teams.
- Only one person knows how to deploy or understands a critical part.
- Technical contacts change often and context gets lost.
- There is neither up-to-date documentation nor centralised access management.
In costs and risks: the system weighs on the business
Technical signals eventually affect revenue or compliance. A cloud bill that rises without an increase in usage, a customer request that cannot be met or an unanswered security question deserves a review before the next commitment.
- The hosting bill rises without a comparable increase in usage.
- Commercial commitments are blocked by technical limitations.
- A security or compliance question remains without a clear answer.
JustWC: audit first, then fix with evidence
JustWC connects itinerant professionals, such as delivery drivers or field technicians, with toilets and water points through a ticket-based WebApp. The product was in production, but technical contacts changed often and requests progressed slowly. The CUB3 audit covered the code, dependencies, security and AWS sizing.
It revealed oversized machines and security issues to fix. The work was then sequenced by impact and budget: fixing the security issues, refactoring the priority parts, then resizing the infrastructure and describing it with Terraform. The infrastructure cost fell from €75 to €18 per month, 76% less. This result concerns this product and its usage; it is not a guaranteed saving.
What an audit should give you
A useful audit ends with possible decisions, not merely a list of defects. At CUB3, the audit covers one application and one repository: review of the code and architecture, examination of dependencies, targeted security and performance checks, then a prioritised report and findings meeting. The indicative budget is €2,000 to €4,000 excluding VAT, confirmed after scoping.
What the audit does not do matters just as much: it does not fix the problems, it is not a penetration test and it does not amount to certification. Fixes are then priced according to the selected priorities, as a recovery, a DevOps setup or maintenance.
- Findings refer to verifiable elements of the code or infrastructure.
- Each recommendation has a priority and a rationale.
- Immediate risks are separated from desirable improvements.
- The findings meeting lets you choose what comes next: fix, recover or rebuild.
In the field
A real project
An audit of the code, security and AWS, then sequenced fixes: infrastructure costs cut from €75 to €18 per month.
The JustWC recovery