A technical audit that ends with a plan, not a pile of notes.
We review a website or application in depth, covering code, architecture, speed, security, search visibility, accessibility and deployment. You receive a ranked list of findings with evidence, effort and a named owner for each, so the report leads to action instead of sitting in a folder.
What is a technical audit and what do you get from it?
A technical audit is a structured review of how a website or application is built and run. It examines code, architecture, speed, security, search visibility, accessibility and deployment, then ranks every finding by risk and effort. The deliverable is a written report with evidence, a recommended order of work and a named owner for each item, so decisions can be made without guessing.
An audit that ends in a spreadsheet changes nothing by itself. The value comes from the ranking, the owners and the follow-up. Reports are written in plain language first, with technical detail in a separate section, so owners and developers each read what they need. Nothing in the report is meant to blame the people who built the system.
Seven areas an audit can cover.
You can ask for all seven or choose the ones that match your worry. Each area is examined with tools and by hand.
Code quality
Structure, naming, duplication, dead code, test coverage and how easy it is for a new developer to make a safe change.
Architecture
Boundaries between parts, data flow, coupling, scaling limits and the decisions that make change slow or risky. This replaces our former architecture review page.
Performance
Server response, largest elements, script cost, database queries and caching, measured on real devices and field data.
Security
Access control, dependencies, configuration, exposed files and known weaknesses, reported with a severity for each.
Search visibility
Crawling, indexing, redirects, canonical tags, structured data and internal links that affect how pages are found.
Accessibility
Keyboard use, labels, contrast, focus order and screen reader behaviour on the most important journeys.
Deployment and operations
How code reaches production, what is backed up, how errors are noticed and how long recovery would take.
Inventory and ownership
A list of plugins, packages, services, accounts and who controls each one, often the most surprising part of the report.
Evidence first, opinions second.
Every finding in our reports can be traced to something we saw, measured or tested. That makes the report fair to the people who built the system.
What happens during the review
- Read-only access. We ask for the least access needed: a repository, a staging copy, analytics and logs. Nothing is changed during the audit.
- Automated scans. Dependency checkers, speed tools, crawlers and security scanners produce a wide first pass, and we separate real issues from noise.
- Manual review. We read the code that matters most, follow real user journeys and test unusual cases that tools miss.
- Interviews. A short talk with the people who run the system reveals workarounds and history that no scan can find.
If the audit is aimed at search problems, our technical SEO service goes deeper on crawling and indexing.
What the report contains.
The report is written for two readers: the person who decides and the developer who fixes. Both should be able to use it the same day.
What you can rely on
- Executive summary. One page in plain language: what is healthy, what is risky and what we suggest doing first.
- Ranked findings. Each issue has a severity, evidence, the exact file or setting involved and a short explanation of the risk.
- Effort and dependencies. Rough effort bands and what must happen before what, so planning is realistic.
- Owner and next step. A named owner and a first action for every item, which is how a report becomes work.
We can fix what we find. Routine upkeep is covered by website maintenance.
How we decide what to fix first.
A long list is not a plan. We sort every finding by how much harm it can do, how likely it is and how much work it takes.
How findings are ranked
- Fix now. Active risks such as exposed data, missing backups, known vulnerable software or broken checkout paths. These are scheduled immediately.
- Fix soon. Problems that cost money or search visibility every week, such as slow templates or redirect chains, but do not threaten the business today.
- Plan. Structural work such as upgrading a framework, adding tests or splitting a tangled module, scheduled across a few months.
- Watch. Items that are fine now but could become problems with growth. They get a monitoring note rather than a task.
The owner of each item is agreed with you in the walk-through, so priorities match your budget.
From scoping call to agreed plan.
The timeline moves with system size, but the sequence does not change.
- 01
Scope
We agree the systems, the areas to review, the questions you most want answered and any off-limit parts.
- 02
Access
Read-only accounts are set up and a backup is confirmed, so the review cannot harm anything.
- 03
Review
Tools and manual checks run in parallel. We note findings as they arise and ask quick questions to confirm facts.
- 04
Draft report
You receive a draft, and we walk through it together so errors are caught and priorities adjusted to your business.
- 05
Final plan
The final report and ranked plan are delivered, with owners proposed for each item.
- 06
Follow-up
A check-in after the first fixes confirms that the problems are really gone and nothing new appeared.
Moments when an audit is worth the time.
An audit is cheapest before a big decision. These are the moments when it tends to save the most.
Good times to audit
- Before a redesign or rebuild. It shows what is worth keeping and what is truly broken, so you do not rebuild problems along with the pages.
- After inheriting a site. You find hidden edits, missing backups and forgotten accounts before they become your problem.
- When speed or rankings drop. Causes are traced to specific changes, plugins or settings, not guessed.
- Before a sale or investment. A neutral review of the technology reduces surprises for buyers and gives you time to fix the obvious problems.
Planning a staged upgrade afterwards? See legacy modernization. The audit is complete only when each finding has a decision attached, even if that decision is to leave it alone for now and write down why.
Quick review, standard audit or deep dive?
Size depends on how much you need to know and how large the system is. Here is how the options usually differ.
| Criteria | Quick review | Standard audit | Deep dive |
|---|---|---|---|
| Best for | A first opinion on a small site | Most business sites and apps | Large or high-risk systems |
| Method | Tools and a short manual pass | Tools, code reading and interviews | Plus load tests and threat modelling |
| Output | Short list of main issues | Full ranked report | Report, roadmap and workshop |
| Typical questions | Is anything urgent? | What should we fix first? | Can this system carry the next stage of growth? |
Technical audits, answered.
Answers below cover what clients ask before they give us access to a system, including scope, access, timing and what happens next.
What is included in a technical audit?
Depending on scope, we review code, architecture, speed, security, search visibility, accessibility and deployment. You can choose all areas or only the ones that worry you. Each finding is ranked and backed by evidence.
How long does an audit take?
Small sites can be reviewed in days. Larger applications take longer, depending on code size, number of integrations, access speed and how many areas you include. We give a range after the scoping call.
Do you need access to my code and servers?
We ask for the least access that lets us do the work, usually read-only. For some areas, such as speed or search, public tools and analytics access are enough. We never change anything during an audit.
Will the audit tell me to rebuild everything?
Only when evidence supports it. Many systems can be improved in stages. A rebuild is recommended when the platform is unsupported or the structure blocks change, and the report shows why.
Can you fix the problems you find?
Yes, if you wish. You can also give the report to your own developers or another agency. The report is written so any competent team can act on it.
How is an architecture review different from a code audit?
A code audit looks at how well the code is written. An architecture review looks at how the parts fit together, where data flows and what limits growth. Many projects need both, and we combine them when useful.
What affects the price of an audit?
The size of the system, the number of areas reviewed, the quality of existing documentation, the access we get and how deep you want to go. We quote after a short look at what you run.
Know what is wrong, and what to fix first.
Tell us what you run and what worries you about it. You will get a clear scope for the audit, the access we need and the range of effort involved. An audit is a fixed piece of work with a clear end date, so you know what you receive and when.