Ask three engineers how healthy your codebase is and you will get three answers. Each one is shaped by how the last release went. That is a hard place to plan from. You may be deciding whether to hire, whether to rebuild, or whether the product can carry the customer you just signed. All you have to go on is a feeling.
A technical audit replaces the feeling with findings. It covers seven areas of an existing product: security, architecture, code quality, performance, test coverage, database and backend, and scalability.
This post walks through what gets checked in each area and what the common failure looks like. The failures are mostly ordinary. Your own team can answer most of the questions below without outside help.
Three checks will tell you a lot this week. Restore one backup and time it. Search the repository and its history for credentials. Ask who can deploy when the usual person is away. Then rank whatever you find by severity before anyone starts fixing it.
| Area | Points | What usually fails |
|---|---|---|
| Security | 20 | Password-only access, no security review |
| Architecture | 16 | Logic in the interface, credentials in the code |
| Code quality | 14 | Review only when someone has time |
| Performance | 14 | A customer tells you it is slow |
| Test coverage | 12 | Old tests nobody trusts |
| Database and backend | 12 | A backup nobody has restored |
| Scalability | 12 | Untested load, one person who can deploy |
Points show how our 14-question self-check weights each area, out of 100.
1. Security: who can get in, and who last looked
What gets checked. How people log in, how permissions are enforced, and when the application last had a security review.
Password-only access, or multi-factor that is offered and never enforced. Optional multi-factor protects the users who opt in and nobody else. Permissions are the other half of the problem. Role checks end up scattered through the code, so a rule enforced on one screen can be missing from the endpoint behind another. Access granted for a one-off task stays in place because nobody is scheduled to remove it.
Reviews fail differently. An application that has never been reviewed collects known vulnerabilities in its dependencies even if nobody touches the code. Automated scanning catches the published ones cheaply. It will not find a logic flaw in your own code, so a periodic manual review still has a job to do.
2. Architecture: whether a change stays where you put it
What gets checked. Whether the application has boundaries a change can respect, and how third-party services are wired in. In a healthy structure, someone can tell you where a business rule lives and what breaks if it changes.
Business logic living in the interface layer is the most common structural problem we see. Picture a discount rule written inside the checkout screen. Testing it means clicking through the screen, and the mobile app needs its own copy. Copies drift until two parts of the product disagree about the total. This is fixable in stages and rarely justifies a rewrite.
Integrations fail in two ways. Credentials written into the code are readable by everyone with repository access, former contractors included. Moving them out is a same-day fix and should be treated as urgent. Deleting a key from the current file leaves it in the history, so change the key too. The second failure is a call with no timeout. A slow provider holds your requests open until your own product stalls. Its outage should have cost you one feature.
3. Code quality: what happens before production
What gets checked. This area cares less about style than about process: what has to happen before code reaches production, and how much of the team’s time goes to unplanned fixes.
Review that happens when someone has time. Deadlines are exactly when nobody has time, so the riskiest changes get the least attention. Making review required and letting automated checks block a merge takes the judgment call away.
The more revealing signal is how the week gets spent. When most of a team’s capacity goes to unplanned fixes, the roadmap stops being real. Leaders tend to read that as a people problem. It usually traces back to missing tests and unclear boundaries. Log the unplanned work for a few weeks and you will normally see a small number of repeat causes.
4. Performance: how you find out it is slow
What gets checked. How you learn the product is slow for users, and whether anyone knows where the time actually goes.
Hearing it from a customer. By then the problem has cost goodwill before it costs any engineering time. Internal use catches the severe cases and misses gradual slowdown. Your team sits on fast machines and good connections. Uptime checks have a similar blind spot. They can report a healthy site while a customer on a phone waits.
The second failure is tuning by instinct. Teams optimize the code that feels slow while the time goes somewhere else. One profiling pass usually shows a small number of queries accounting for most of the wait. The classic case is a list page running one query per row. It looks fine with fifty rows in development and crawls with fifty thousand in production.
5. Test coverage: whether anyone trusts a release
What gets checked. What automated tests exist, and how confident the team is that a release will not break something unrelated. That second answer often says more than a coverage figure.
A handful of tests written early and never maintained. Once a suite stops being trusted people skip it, and a skipped suite protects nothing. Pruning back to a maintained core usually beats adding more.
Manual testing sets its own trap. It makes releases slow, so they get less frequent, so each one carries more change and more risk. Testing only the areas you think are affected works until a change has an effect you did not predict. Start with automated tests on core business logic. Full coverage is the wrong first target.
6. Database and backend: whether you can get the data back
What gets checked. How schema changes reach the database, and what your backup and recovery position really is.
Changes applied by hand, directly against the database. Environments drift apart and nobody has a reliable record of what changed or when. Versioned migrations solve both. Even then, a migration that ran in seconds on a small staging copy can lock a large table in production. Test against realistic data volumes.
Backups are where belief and fact sit furthest apart. Plenty of teams have automated backups and have never restored one. An untested backup is an assumption. You do not know whether it is complete or how long recovery takes until you run it. One restore, once, is the most valuable hour of work on this whole list. Time it and the business gets a recovery figure it can plan around.
The restore you have never run is the one you will be running for the first time during an outage.
7. Scalability: what happens on your best day
What gets checked. What the application does under a sudden increase in load, and how it gets deployed. Deployment belongs here because added capacity is only useful if you can ship it safely.
Not knowing. Load problems surface at the worst moment. That is usually the launch or campaign that was supposed to go well. A team that has already fallen over knows a ceiling exists and still does not know where it is. A basic load test gives you a number to plan against.
Deployment fails when it depends on one person. Manual deployment by whoever knows how is an availability risk and a hiring risk. Document it first so anyone on the team can follow it, then automate it. Staged rollout comes after that. It limits a bad release to a fraction of your users.
Seven questions to put to your team this week
Count an answer of “I think so” as a finding.
Why severity matters more than the score
A score tells you roughly where you stand. Deciding what to do on Monday takes a ranking. The list mixes problems of very different urgency. Credentials in source code are urgent and can be gone by tonight. Business logic in the interface layer is a slower job, handled module by module alongside planned work. An audit with no severities hands you a long list and leaves the hard part to you.
Frequently asked questions
How long does a technical audit take?
Ours takes 1 to 5 days and ends in a written findings report. The self-check on the same page is 14 multiple-choice questions.
What is the difference between the self-check and the full audit?
The self-check scores what you tell it, so it cannot surface a problem nobody on your team knows about. The full audit is a scored review of the software itself. Its output is a written report with prioritized recommendations and severity classifications.
Is the technical audit actually free?
Yes, both cost nothing. The self-check does ask for your contact details first. The audit is one way a Software Development engagement with Touch Support starts. That is why we offer it.
Do we need a rewrite if we score badly?
Usually not. A low score tells you where to start. Most of the failures above can be fixed in stages alongside planned work. A rewrite brings risks of its own.
Which technical problems should we fix first?
Start with anything that exposes credentials or customer data, then anything that could lose data you cannot recover. After that, work on whatever costs the team the most unplanned time.
Is a technical audit the same as a penetration test or a SOC 2 report?
No. A penetration test actively tries to break into a running system. A SOC 2 report comes from an independent CPA firm. A technical audit is a broader review of how the software is built and run. It certifies nothing.
If you want it scored
The free technical audit page has a 14-question self-check, two questions for each of the seven areas, scored out of 100. It asks for your contact details before it shows the full result. That result breaks the score down by area, adds a prioritized action plan and can be downloaded as a PDF.
A self-check only knows what you tell it. The full audit from our Software Development team is a scored review of the software across the same seven areas. It takes 1 to 5 days and costs nothing. You get a written findings report with prioritized recommendations and severity classifications.
Start with the free 14-question self-check, or book a call to talk through the full audit.
The seven areas, their weights and the failure patterns come from the Touch Support Free Technical Audit. The discount rule and the list page are illustrations, not client findings.
