Would you buy a house because it looks nice, without having a professional take a closer look at it? Unlikely. You should use the same skepticism when having software developed. You shouldn’t only be verifying that the features you want are actually there, but also the craftsmanship of those features and quality of the components. The standard could vary depending on the software, whether it’s a consumer app or a healthtech digital product, but one thing remains true - you need to make sure you are doing technical audits to help ensure your digital product has a future.
What are the consequences of skipping a technical audit?
There are three major consequences you could face if you do not request a technical audit for your digital product:
- The only person or team that can maintain the product is the current one. If they write all the code in a way only they can understand, it means you’ll be stuck with that vendor. (developers call this kind of code “read only” because no one else can understand it, and therefore cannot modify it later)
- Your developers used software that you don’t have the rights to use. They may have copied source code from other sources or used open source code that is licensed to use in your context. It works and probably saves developer time, but you need to find and pay the copyright holder for a license before you get sued.
- Security issues leading to theft of confidential data or funds. For example, healthcare records becoming publicly available or a Fintech company having bank accounts accessed and money stolen.
Technical audits of business software go beyond functional requirements
Technical audits can include code reviews, library reviews, and security scans. The benefit of running a technical audit is simply avoiding the consequences mentioned above. The success and longevity of your business depend on having a user-friendly product that can be scaled, is licensed, and secure.
Code reviews would be looking for a variety of different issues including if the code is:
- written in an obscure language or one that might not be supported in the future. Maybe each developer on the project chose their own favorite development language, or one developer chose a different coding style or libraries for each component they worked on. Yikes!
- written so that no one else can understand (and efficiently use) it - “spaghetti code” thrown on the wall whenever a new developer touched it.
- overly complex design - every small change will affect many pieces of code could triple future maintenance costs and possibly rule-out future refactoring.
- Looking at the code review daily practices of the team. Are there code reviews performed for every commit of new code?
Library reviews ensure that you have licenses for your software and that the licensing is up-to-date. Reviewing libraries is important because developers often use open-source software (you cannot use these libraries for proprietary projects).
Security scans including penetration testing, which can be automated or manual. This is used to determine where the weak points may be in your software and allow you to catch these deficiencies early on, to prevent a breach that could kill your business.
When should you carry out a technical audit?
Carrying out a technical audit is important, but it’s equally important to understand when you should be carrying them out. When you hire developers and see that the features work, whether it’s for mobile or other software solutions, you tend to trust them. But not looking at what’s under the hood could greatly impact your business.
Scenario #1: “Before signing off on your software developer’s work”
Do a technical audit before you accept the work from a vendor, either during user-acceptance testing of a third-party or before you release it to the market. You can (and should) ask about the technical audit from the very start. It should be transparently defined during the design phase and should be included in the estimation of the development of your digital product.
Scenario #2: “Audit prior to digital product/feature launch”
Alternatively, you can do a technical audit before you go live, auditing features as they are rolled out, before pushing them to the market. Yes, you can request technical audits for each feature or group of features before they are released. If you’re working in Agile, this could be every 2 weeks or even every day.
Scenario #3: “When acquiring a software company”
If you are purchasing a company whose core product involves building digital products which demand complex development, we highly recommend getting their software audited to make sure you can actually maintain the product. This should be part of your due diligence during an acquisition.
Finally, during early design phases, when you are developing your first modules, why not check-in and make sure everything is starting off on the right foot? You can request a technical audit after the first 2 modules or once you see some code that isn’t throwaway.
Technical audits give your digital product a future
Your code, and its environment, are the skeleton of your digital product. It’s crucial to your business that you are able to maintain and scale your product with relative ease, which is why technical audits are so vital. You need to ensure that your products code won’t tie you to one developer or development team, while also making sure that you actually legally own the software that you’ve paid for. Security is an obvious concern, and technical audits can also help to pinpoint potential areas of concern. Securing the future of your product can heavily rely on the discoveries that come from performing technical audits.
- It’s not just about how your software products work, but that what’s behind them is up to standard
- Technical audits can include code reviews, library reviews, and security scans
- For the long-term health and maintenance of your product, you should be requesting technical audits
- You should make sure that technical audits are a part of your agreement and that they are clearly outlined