Does Your Software Need a Code Audit? A Guide for Business Owners
If you’re wondering whether your software needs a code audit, the short answer is probably yes. A software audit is an in-depth review of your application’s infrastructure, architecture, and codebase to identify risks, inefficiencies, and hidden problems.
When Does Your Software Need a Code Audit?
If you have a project in development and your development team is struggling to meet release deadlines, you may need a code audit.
If your live project is slowing down and slipping in search rankings, you need it very likely.
If your project falls apart, shows incorrect numbers, or freezes for an indefinite time, you are strongly advised to make a code audit.
And let’s make things a little simpler—if you have already started thinking about a code audit, it’s a sign that now is the right time to look inside your project and understand what’s really happening under the hood.
This article is written for business stakeholders rather than software developers. We won’t dive into developer-focused topics such as best practices or tools for auditing a codebase — there are plenty of resources covering those. Instead, we’ll focus on what business owners need to know about code audits, what outcomes to expect from code audit services, and how to act on the results.
What Are the Risks of Missing a Code Audit?
The risk is that existing problems will persist. Probably, their impact will grow.
If the project is slow, it will get slower. If the numbers are off, they will become more and more off until totals are unrecognizable.
If you have fewer visitors and conversions than a few months ago, visitor numbers will continue to decline.
Let’s reverse the question. What are the risks of making a code audit?
There is a high risk that you will find out about fundamental, structural issues in your architecture. That is not the kind of knowledge that makes people happy. It’s scary knowledge.
But once you have it, you will be able to decide what to do.
What Problems Can a Code Audit Expose?
There are multiple places where multiple problems can be found.
Krononsoft’s experts recently audited an e-commerce application with multiple white-label websites. The customer’s complaints included all the symptoms described above: slow speed, incorrect numbers, lack of visitors, etc.
The context provided was that the problems started to appear as the numbers of their websites – and third-party APIs – grew.
Our code audit service covered everything from infrastructure and source code review to detailed roadmap for addressing discovered problems.
Infrastructure Audit
The most visible issue was in the AWS infrastructure. The servers were in an incorrect region.
By incorrect region, we mean a scenario where most of the users are located in, say, Europe while the server is in another place (US).
This issue can be treated as minor, but this is what happens when a user opens the app in a browser.
- The user’s request goes the full path from Europe to the digital center in the US.
- While processing the request, the backend calls a third-party API which is located in Europe. So, the API request goes from the US to Europe.
- The third-party returns a response that goes from Europe to the backend in the US.
- The backend in the US returns a response that goes from the US to Europe.
How fast would this work, what do you think?
In the software development world, we still should take into consideration common real-world realities such as geography.
Local Environment Audit
This one also refers to the infrastructure, but of another kind. We set up a local environment, run migrations, seed the database, and see how everything works.
How easy is it to set up a local environment? Is it fully functional? What tools do developers use?
Returning to the e-commerce project we audited, since it was a multisite application, we were expecting certain tools to emulate a few websites in a local environment.
There were none. The software was not designed to have a local multisite configuration.
On the other hand, we found traces of an external configuration suggesting that the developers used some “test” servers invisible to the customer for development purposes.
It meant that:
- The development pipeline was overcomplicated (hence could allow for mistakes).
- Development on a local machine was not possible.
- Development did not imply automated tests.
From that checkpoint we moved to the codebase.
Software Code Audit
When the code is large, code quality audit is done manually as well as with the help of plugins that measure code standards.
We ran a few code climate plugins. This is what we found:
- The code had no automated tests. If there are no tests, the developers lack confidence that they can change the code without breaking the behavior. So, once written code remains mostly the same no matter how bad it is.
- The code had a very high cognitive complexity – it was very large and did not have proper decomposition into smaller parts. No one could read it and understand due to its size and absence of descriptive tests.
- The code had high cyclomatic complexity – it had too many nested if-else statements, hence too many scenarios could take place.
Apart from that, the code was sloppy, with blank lines and extra spaces, incorrect indentation, long lines, etc.
We could make a note that the developers of the project had been living in a mayhem for a long time.
But let’s give a little bit of credit to software developers. Their life is not always shiny. They can find themselves in mayhem not only because of lack of experience.
Sometimes mayhem appears because the customer demands the developers to hurry – so they run for their lives.
Database Audit
We perform the database audit to understand what core entities form the project, how tables and their relationships are normalized/denormalized, and what the hierarchy of objects in the system is.
Very often, an incorrect normalization leads to various many-to-many relationships which, in their turn, make SQL queries slower.
In the code audit example that we are describing here, the main topic was multitenancy.
An application with multiple white-label websites assumed multiple tenants in the database. What kind of multitenancy would we see?
A Side Note About Multitenancy
There are 2 common approaches for multitenancy:
- A multiple-database approach,
- A single-database approach.
Multiple databases allow the developer to store the same set of tables with different data in each database. From the development perspective, switching among tenants means switching among databases.
The other – single-database – approach allows developers to store all data in the same database. To implement that, all tables (or most of the tables) should have a field called “tenant_id” that is a foreign key leading to a tenants table.
The “tenant_id” field would allow selecting tenant-specific data from every table. This way, the tables in the database would contain data of all tenants together, but it would be possible to query data belonging to a specific tenant.
An Incorrect Multitenancy
In our example, the multitenancy approach was none of the above. Instead, the developers implemented a custom and naive scheme.
Each tenant had its own set of tables. Therefore, adding a new white-label website assumed more than adding a record to the websites table. It required changes in the database structure.
As a consequence, it required developer’s efforts every time a new website was added.
Another consequence was that every copy of the project had a different set of tables. Which led to another problem: if a bug was found in production, it was impossible to reproduce on staging.
It is also worth mentioning that such an approach ruins the purpose of standard database migrations – hence removes consistency among local, staging, and production databases.
Production Server Audit
This way, after a few sessions of the software audit, we knew that the customer had an impressive list of hurtful issues.
However, all the problems above paled in comparison with what we found on the production server.
Production was the last piece of the puzzle. We did not have access to it at the beginning of the audit, so we acted upon the premise that the project was a single-instance multi-tenant application with a single database.
When we got access to the production server, we found more than 50 Docker containers with various running copies of the project.
This way, there were multiple multi-tenant instances of the application, all of which were connected to the same database.
The final nail to the coffin was, every instance was deployed in its unique way through manual copying of selected project files.
The customer had 50 absolutely different versions of the same project running at the same time.
None of these versions could be tracked via Git and considered the source of truth.
With such complicated and untested code and without a defined source of truth, the project was impossible to maintain and had to be re-engineered.
Why Developers Allow Poor Solutions
The question in the heading is not correct. The correct question is how do we move on and make the project better.
But since everyone is interested in reasons leading to a long list of issues, let’s name a few ones.
Some developers do not have sufficient experience, especially when it comes to combining technical aspects such as multi-tenancy, per-website content and style customization, and third-party API integration.
Sometimes, the problems come from the stack of technologies which do not fit in the required architecture.
These issues do not sound good as I do not like talking about my fellow developers in this manner. I prefer to think about them as professionals.
But not everything comes from developers. Here are a couple of other reasons you might want to consider.
Some problems appear because many developers tend to implement customer’s requirements exactly as they were written.
This is an important issue! There are many “yes-people” among software developers, who will prefer to develop exactly what you tell them to instead of warning you about consequences.
If you give them a task that requires them to “write a background job that pulls updates from the third-party every X minutes”, they will. Even if a better solution may not imply a scheduled job at all.
Then imagine that they receive another task. And another one. And they keep implementing them in the same manner.
More and more code gets accumulated. More and more scenarios appear.
This is what gives projects cognitive and cyclomatic complexity.
The answer to this problem (and to many others) is the correct development pipeline that involves refinement and quality assurance. We will talk about it in a separate article.
But My Code Is Developed by AI
No code is developed by AI. All code is written by people.
AI is just a tool that can be helpful in good hands. It does not write code itself. It can only generate code snippets based on requirements provided by a conscious person who envisions the desired result.
The AI-generated code should be thoroughly reviewed and partially rewritten in order to match the architecture.
The amount of rewritten code may vary depending on the task, project stage, and developer’s preferences. Very often, that amount will run up to 100%.
That is perfectly normal.
AI cannot be responsible for providing functional software for your business—people can.
What to Do with the New Knowledge of the Code State
First of all, you need to understand and accept it.
Understanding is key. When I perform a software code audit, I realize that most of my customers are not technical. Therefore, I put an emphasis on explaining pure technical issues to non-technical people.
You did not understand the nature of these issues; now you do.
The project looked decent from the outside, and you did not know what was inside. Now you know it.
This is good. This is an opportunity. Now you can make decisions.
The purpose of a code audit is not to make you scared. Every found issue has very specific consequences.
Every issue can be addressed in its own way.
Then it will be your turn to take action.
Ways to Make the Project Better
After your project is audited, you will get a report. The code audit report will have several deliverables.
- A list of issues, antipatterns, and smells with explanations of what they mean. (Do not take the word “smell” as sarcastic, it is an official term. In the PHP world, there is even a tool called “codesniffer” and it does exactly what its name means – looks for smells.)
- A list of expected consequences of having the mentioned issues, antipatterns, and smells.
- A verbal explanation of the above. At Krononsoft, we believe most customers need it more than a list of references.
- Recommendations. Ways to make the project better. A roadmap.
Let’s take a closer look at point 4.
Building a Roadmap for Improvement
The project has problems, it is sick. It is worth asking, how can you make it healthy? How can you move forward and turn the project into a fully functional tool that is right for the business?
The code auditors should provide you with a good plan or even a few plans.
The plan will have multiple steps put in a specific order. For the multi-tenant e-commerce website our experts suggested three different plans: one that assumed supporting the current codebase, another one with moving away from it, and yet another one with moving away partially.
The first one looked approximately this way:
- Fix the local environment so that a new developer could start the project on a local computer.
- Fix database seeds and factories so that the local environment can work with a fresh database.
- Set up a plugin in the local editor/IDE and use its formatting possibilities. Integrate style linters into the CI.
- Follow the common development pipeline in which the code moves from a local environment to Git and from Git to servers. Treat Git as the source of truth.
- Unify the data model so that all environments and servers can have the same database structure (while they can still have different configurations and content).
- Write automated tests and decompose complex classes and functions into smaller blocks of code. Follow guidelines and use the framework possibilities of having various types of classes with single responsibility.
- Write another implementation for the multi-tenant part in a way so that no tables or classes are duplicated. Move to the new implementation from the old one.
- Change deployment so that the code, runtime environment, JS/CSS assets, and the database structure are deployed consistently (ideally, in a single “git push” or CI pipeline run).
Addressing Code Audit Findings: Time and Effort
A question a customer always asks is, how much time and money do I need for that?
Simple problems can have simple solutions. Changing the region in AWS can be relatively easy and take a few hours.
Changing the database structure is much harder and time-consuming. Sometimes, you will need to build a parallel universe just near your current one, and then make a jump from one universe into the other.
So, that is weeks of work. How much do you pay your developers per month?
The hardest problem is maintaining a codebase that has high cognitive complexity but does not have automated tests.
It means, automated tests should appear. The more code you have, the more tests you will need.
This is something that is hard to measure in weeks or dollars. Writing tests is an ongoing process. Your developer should do it all the time.
With every new feature added, more tests should appear.
If it does not happen naturally, maybe you need to change the developer rather than just “fix” problems and move on.
I am not sure how project owners conceive their projects. For me, a software developer, a project is a living thing that can grow or shrink, that can get sick or become healthy and powerful and jump to the next level.
So be sure that even if your project is not as strong as some others, it may have a second – and better – life.
Sometimes it will require investments. But it is possible.
Engage a professional code audit service provider. Follow the recommendations. Make changes in the code and the database architecture. Take the chances to make the project better.
And you may witness some miracles.
Software Code Audit FAQs
What is a code audit and why is it important?
A code audit is a thorough review of your software’s codebase to identify issues such as high complexity, missing tests, sloppy coding, and structural problems. It helps ensure your software is maintainable, reliable, and scalable, while reducing the risk of errors and downtime.
How do I know if my software needs a code audit?
Signs that you need a code audit include slow performance, incorrect outputs, frequent crashes, difficulty in deploying updates, or a growing gap between your software’s functionality and user expectations. If your development team struggles to release updates on time, a code audit is strongly recommended.
What is an infrastructure audit?
An infrastructure audit reviews the configuration and performance of servers, cloud resources, and network setup. It identifies bottlenecks and misconfigurations that can slow your application and ensures users receive fast and reliable responses.
What does a local environment audit involve?
A local environment audit checks how easily developers can set up and run your software on their machines. It uncovers workflow issues, missing tools, and gaps in the development pipeline that may slow coding, testing, and deployment.
Why is a database audit necessary?
A database audit examines the structure, relationships, and efficiency of your data. It helps detect poor normalization, complex multi-tenant setups, and query bottlenecks that can reduce performance, complicate scaling, and create inconsistencies across environments.
What is a production server audit and what problems can it reveal?
A production server audit inspects the live environment to uncover misconfigurations, inconsistent deployments, multiple application instances, and other hidden risks that can break functionality or make maintenance difficult.
How long does a software audit take?
The time required depends on the project’s complexity, and the code audit company involved. A basic assessment may take a few days, while a comprehensive software audit can take weeks.
Can AI do a code audit?
No. AI can assist developers by generating snippets, but it cannot perform a full audit. Human expertise is essential to review architecture, assess code quality, and make informed decisions about improvements.
What benefits can I expect after a code audit?
A code audit provides a clear understanding of your software’s current state, identifies risks and inefficiencies, and delivers actionable recommendations. Following the audit can improve performance, maintainability, reliability, and help plan future growth.
How do I start improving my software after an audit?
Start by implementing the recommended fixes in order of priority: optimize infrastructure, clean up code, restructure the database, standardize development workflows, and deploy consistent processes. An audit report often includes a roadmap to guide these improvements efficiently.
Vadim Kondratiev, team lead and customer liaison at Krononsoft, specializes in guiding complex software initiatives and aligning technology with business growth.
