7 signs you need a code audit

Most people who commission software have no direct way to check what they actually received. You can open the app, click through the screens, and see that it does roughly what it was supposed to do. What you cannot see is how it was put together underneath, whether anyone other than the original team could work on it, or what happens the first time it comes under real load. The people best placed to answer those questions are usually the same people who built it, which becomes awkward the moment you start to doubt them.

That doubt is what starts most of these conversations. A founder described it to us recently in almost exactly those terms: the app seems to work, but the team that built it will not communicate clearly about what is inside it, so how does he know that what he paid for is genuinely there. It is a fair question, and one that a surprising number of people are quietly sitting on.

You do not need a technical background to notice that something is off. The seven signs below are the ones that come up most often, and all of them are visible from the buyer’s side of the relationship without reading a single line of code. If two or three of them sound familiar, that is usually reason enough to have someone independent take a look.

1. You cannot see what you are paying for

Progress arrives as percentages, status colours, and summaries that are hard to argue with. The feature is nearly done, the tricky part is handled, there is just some polishing left. Weeks pass and the same items stay at eighty percent. When you ask for something concrete you can look at, the answer involves an environment that is not quite ready or a build that would take time to prepare.

This is the most common starting point, and it does not always mean anything is being hidden from you. Plenty of competent teams are simply poor at reporting to non-technical clients, and they assume you would rather not hear the details. The problem is that a team with something to hide behaves identically, and from where you are sitting the two are impossible to tell apart. Any healthy project can show you working software at short notice, on a schedule you set rather than one you are given.

2. There is no documentation, and nobody treats that as a problem

Ask for a written description of how the system fits together, instructions for setting it up on a new machine, or a record of why certain decisions were made, and you get one of a few standard answers. The code is self-documenting. It is all in people’s heads. Documentation goes stale anyway, so writing it would be wasted effort.

Documentation does go stale, and no project has perfect documentation. What matters is the attitude behind the answer. A team that considers written knowledge optional is a team that has made itself difficult to replace, whether or not that was the intention. The full cost of that choice lands later, on whoever inherits the project, and by then it is expressed in months of ramp-up time that you pay for a second time. If nobody on the project can hand you a document explaining how a new developer would get started, you are more dependent on the current team than you probably realise.

3. Nobody has ever explained how security is handled

Consider whether you have ever been told how vulnerabilities get discovered on your project, how quickly they get patched once found, when the third-party libraries in your application were last updated, where your users’ data physically sits, and who currently has access to the live system. For most projects, the honest answer is that none of this has ever come up, because it rarely comes up unless the client asks.

Silence here should not be read as a sign that everything is under control. Applications are built on top of dozens or hundreds of open source libraries, security flaws are found in those libraries constantly, and keeping up with them is ongoing work that has to be scheduled and paid for like anything else. In projects that have never been reviewed, it is normal to find dependencies that have not been updated in two or three years, along with known vulnerabilities that were published and fixed long ago. If you serve customers in the EU there is a second layer to this, since where personal data is stored and who can reach it are questions you are legally answerable for, regardless of who wrote the code.

4. Problems you already paid to fix keep coming back

A bug is reported, fixed, and confirmed. A month later, after work on a completely unrelated part of the application, it appears again. Sometimes it is a bug you remember from six months earlier that everyone had forgotten about.

There is usually one cause for this, which is that the project has no automated tests. Without them, nothing checks whether today’s change broke something that worked yesterday, so the only mechanism for catching regressions is your users noticing and complaining. Teams under delivery pressure skip tests early on because they slow down the first few months, and the cost of that decision shows up gradually as a project where every change carries a risk that nobody can quantify. When you find yourself paying twice for the same fix, this is almost always what sits behind it.

5. Small changes cost more than they should

Changing the wording on a screen turns into a two-day task. A feature that sounds simple when you describe it out loud comes back quoted as if it were a small rebuild. Estimates seem disconnected from the size of what you asked for, and the explanations for why are technical enough that you have no way to evaluate them.

This is what accumulated shortcuts feel like from the outside, well before anyone in the room says the words technical debt. Code that was copied and pasted rather than structured means one change has to be made in nine places. Logic that was written directly into the screens rather than kept separate means a small adjustment ripples through the whole application. None of this is unusual, and it does not mean the original team was incompetent, since most of it comes from delivery pressure rather than lack of skill. It does mean that the price of every future change has already been set higher than it needed to be, and that continues indefinitely until someone deals with it.

6. The project depends entirely on one team

Test this with a few questions you can answer yourself. Do you know where the source code is stored, and is it in an account that belongs to your company. Do you know whose credit card the hosting is on. Could you give another developer everything they would need to start work tomorrow morning, without asking the current team’s permission. If the relationship ended badly next week, what exactly would you be left holding.

Very often the answers are vague, and any conversation about bringing in another developer comes with warnings about how long it would take someone new to understand the system. That warning is sometimes accurate and sometimes a way to close the conversation down. Either way, a project where the knowledge, the accounts, and the access all sit with one supplier is a commercial risk that has nothing to do with the quality of the code. Ownership is easy to verify and worth verifying while the relationship is still good.

7. Asking for an outside opinion causes friction

You mention the idea of having someone else look at the project, and the mood changes. The response is that an outsider would not understand the context, that a review would waste time better spent on delivery, or that this suggests you do not trust the team.

A team that is confident about its work usually welcomes a second pair of eyes, because a review that finds nothing is free reassurance for everyone and a review that finds something gives them a case for the maintenance time they have probably been asking for anyway. Discomfort with the idea is worth paying attention to, and it happens to be the one signal on this list that you can read with no technical knowledge at all. The founder mentioned at the top of this article reached the same conclusion by himself, which is what led him to look for someone independent.

What an audit actually gives you

A code audit produces a written picture of what exists, described in language you can act on. It tells you what has been built, what was claimed but is missing or incomplete, where the security and data handling risks sit, how much of the system is covered by tests, and what condition the project is in for someone else to take over. Alongside that you get a sense of which problems need attention soon and which ones you can reasonably live with, together with rough costs for dealing with them.

The point is to give you the same view of your own project that your development team has. Most of the awkwardness in these relationships comes from one side knowing something the other cannot check, and that goes away once you have an independent description of what you own.

Getting a first look

If several of these sound like your project, the useful next step is small. Send us read access to your repository and a short description of what the application is supposed to do, and we will come back with an initial written summary of what we find. There is no obligation attached to it, and you get the written summary either way.