Current Solutions Audit
An audit turns a vague sense that something is wrong into a ranked list you can act on: what is actually risky, what is merely untidy, and what will break first as you grow.
What an audit is actually for
Most companies do not commission an audit because everything is fine. They commission one because something has become noticeable: deployments that used to take an hour now take a day, a bill that grew faster than usage, an outage nobody could explain, or a supplier relationship ending and no clear picture of what is being handed over.
The purpose is to replace impressions with measurements. Not a general opinion that the system is dated, but a list: this query takes eleven seconds under load, this dependency has a known vulnerability, this job's runtime grows linearly with your order table, this backup has never been restored. Findings in that form can be argued with, priced and scheduled. General opinions cannot.
Static review finds what is visible without traffic
The first pass is reading. Repository layout, dependency versions, infrastructure definitions, the deployment pipeline, configuration across environments.
This catches a specific class of problem: packages years behind with published vulnerabilities, credentials committed where they should not be, staging and production configurations that have quietly diverged so that testing in staging proves less than anyone assumes, and manual steps in a deployment process that only one person knows how to perform. None of it requires load to find. All of it tends to matter at the worst possible moment.
Runtime review corrects the assumptions
Reading code tells you what should be slow. Measuring tells you what is.
These disagree more often than not. Teams optimise the function they wrote most recently and miss the ORM call that quietly runs once per row. We look at query plans, request traces, error rates and resource use under real traffic, and where the picture is incomplete we generate load to find the ceiling deliberately rather than waiting for a launch to find it accidentally.
The output is a number instead of an adjective. "The system supports roughly this concurrency before response times pass your threshold, and the constraint is the database connection pool" is something you can plan around. "It might not scale" is not.
Failure modes are where the serious findings are
The single most common serious finding in an audit is not performance. It is a recovery path nobody has tested.
Backups that run successfully but have never been restored. A failover that was configured two years ago and would not work now because the secondary is running a different version. A rollback procedure that exists in a document but has never been rehearsed, so the first attempt happens during an incident. A third-party dependency with no timeout, so when it hangs, your application hangs with it.
We work through these explicitly, because they are cheap to check and expensive to discover live.
There is a related category worth naming: the things only one person knows. A deployment step that lives in someone's shell history, a component nobody else has ever modified, a vendor account registered to an individual's email. These are not technical faults and they will not show up in any monitoring dashboard, but they behave exactly like single points of failure and they leave with the person.
What you do with the report
The report is ordered by impact against effort, and it deliberately separates three categories: what is dangerous, what is expensive, and what is simply irritating to work with.
That separation matters, because the third category is what teams naturally want to fix first. Tidying code is satisfying and visible. It is also frequently the least urgent thing on the list. An audit is most useful when it gives you permission to leave some ugly code alone and spend the same week making sure you can restore a database.
Some findings will be things your team already flagged. That is fine, and often the point. An outside measurement is what gets internally known problems taken seriously enough to fund.
What you get
Prioritised findings list
Every finding scored by impact and by effort to fix, so the report ends with an order of work rather than a hundred equally urgent bullet points. The distinction between 'this will cause an outage' and 'this is ugly' is made explicitly.
Performance and bottleneck analysis
Where response time actually goes: slow queries, missing indexes, N+1 patterns, synchronous calls to third parties, cold starts. Measured against real traffic rather than assumed from reading the code.
Scalability limits with the numbers
The point at which the current setup stops coping: connection pool exhaustion, a single instance that cannot be duplicated, a nightly job whose runtime grows with your data. We name the ceiling instead of saying it 'may not scale'.
Security and stability assessment
Dependency versions and known vulnerabilities, secrets handling, access control, exposed endpoints, and whether the backups can actually be restored. That last one is checked, not assumed.
Cost review
Over-provisioned instances, storage nobody reads, duplicated SaaS licences, and traffic patterns you are paying premium rates for. Often the fastest part of the report to act on.
Remediation plan
The findings turned into a sequence of concrete changes, each with a rough effort band and a note on whether it can be done incrementally or needs a planned window.
How we work
- 01
Access and interviews
Read-only access to code, infrastructure and monitoring, plus conversations with the people who maintain it. The team usually knows where the bodies are buried; the audit's job is to confirm it and rank it.
- 02
Static review
Repository structure, dependency tree, infrastructure definitions, deployment pipeline, test coverage and configuration. This finds the risks that are visible without traffic. Outdated packages, secrets in the wrong place, environments that have drifted apart.
- 03
Runtime review
Metrics, logs, error rates and database query plans under real load. This is where assumptions about performance usually get corrected, because the slowest thing is rarely the thing people suspect.
- 04
Failure probing
We work through what happens when specific pieces fail: a restore from backup, a dependency timing out, a queue backing up, a deploy that needs rolling back. Untested recovery is the most common serious finding.
- 05
Report and walkthrough
You get the written findings and a session to go through them with your team, so the reasoning transfers rather than sitting in a document. Disagreement in that session is welcome and often improves the priorities.
Tools and technology
Where a solid open-source tool exists, we choose it over a closed one. No lock-in to a single vendor, and costs you can actually predict.
- Grafana
- Prometheus
- OpenTelemetry
- k6
- Lighthouse
- OWASP ZAP
- Trivy
- PostgreSQL
- Docker
- OpenTofu
- Terraform
- Sentry
Frequently asked questions
More services in this category
Technology Strategy
Technology strategy is a short list of decisions that are cheap to make once and expensive to revisit. We help you make them deliberately, with the tradeoffs written down.
Decision Support Before Implementation
The cheapest hour in any project is the one spent before it starts. We check the assumptions, compare the offers on equal terms and cut the scope down to what actually has to exist first.
System Modernization and Scaling
Systems rarely fail outright. They get slow to change, expensive to run and fragile to deploy. The fix is a planned sequence of small replacements, not a rewrite.
Read testimonials from companies that trusted us
Delivered well ahead of the deadline.
ZanReal's individual approach is impressive.
Knowledge and business intuition make them a valuable partner.
Quick solutions that reduced costs by 99%.
Not sure what will break first in your system?
Message usTell us what has become slow, expensive or hard to explain, and we will outline what an audit of your setup would cover and where it should start.
Can't keep up with changes in AI world?
Let us do the heavy lifting. Every week we distill the most important AI developments into a focused 5-minute briefing — so you stay ahead without the noise.
Find out more