If you work in venture investing, you know that every piece of funding you commit represents a calculated risk. Every startup believes that their idea has the potential to be massively successful, but according to the Small Business Administration, only about half of all new businesses survive five years or longer, and survival rates for venture-backed startups are even lower. While there are many factors that impact a startup’s ability to scale and be profitable, one critical aspect that we at SmartLogic are equipped to help assess is the state of the codebase — how well it is written, how maintainable and scalable it is, and how healthy the devops infrastructure and overall application architecture is.
A tech audit for a codebase is a lot like a home inspection. When you buy a house, you know that there are critical aspects of the house that you as a buyer are not equipped to assess — things like structural integrity, plumbing and electrical systems, and the state of the roof. This is why we get home inspections; we bring in trusted experts to assess and inform our purchasing decisions so that when we move into our new home we know what to expect — for instance if the roof will need replacing soon, or the pipes need work before the deal can be closed.
Similarly, if you’re thinking about funding a tech startup, it’s in your best interest to bring in an outside expert to help you assess the state of the codebase you’ll be backing. In the best case scenario there will be no skeletons in the virtual closet, but regardless it’s worth finding out whether there are, and what you may need to do to manage them going forward.
Due to the nature of our work, we have a lot of experience evaluating codebases; here is a brief overview of some of the considerations we take a look at when conducting a technical audit.
Ramp-up Time
The first thing we look at when assessing a codebase is how long we think it will take for someone who is new to the project to get up to speed. Slow ramp-up time has short-term implications but also contributes to cumulative costs over the life of a project.
- Documentation: Is there documentation? How robust is it? Is it easy to find and up to date, or scattershot and stale?
- Diagrams: Are there diagrams of the codebase? Are they informative, comprehensive, and up to date?
- Tests: Does the codebase have tests? If so, how complete is the coverage? Are the tests modular and reusable?
- Setup Scripts: Are setup scripts available to help get new developers up and running quickly, or will developers need to manually configure the codebase locally before they can begin work?
Code Quality
Our code quality review is the meat of the tech audit. We look at the codebase to see how it is structured, how easy it is to understand, and what setup work has been done to catch and prevent bugs.
- Clarity: Is the code written clearly, such that someone who has not previously worked on the codebase can easily understand what a given piece of code does?
- Variable names: Are variable names descriptive and informative, or are they abstract and arbitrary?
- Function documentation: Are functions documented in the codebase, or does their behavior need to be reverse engineered in order to be understood?
- Test Coverage: How complete is the test coverage? Incomplete or scattershot testing can leave holes that allow bugs into production.
- Test Suite Speed: How quickly do the tests run? Inefficient tests can slow down testing and development; no one wants to pay their highly skilled engineering team to sit and wait for a slow test suite to run.
DevOps and Deployment Environments
The DevOps configuration is the behind-the-scenes underpinning of your codebase. Solid deployment strategies mean that your app is easy to update, has good fallbacks, and is well documented. Fragile deployment strategies can cause lost time, make deployments risky, and lead to application down time.
- Deployment procedures: How are updates deployed? Are they automated or do they need to be run manually? Are deployment procedures documented?
- Environments: Does the application have isolated development, testing, and production environments? Do those environments have realistic seed data?
- Backups: Is there a backup system in place, and how robust is it?
- What happens when something breaks: Is there error reporting? Are there fallback options? Can the codebase be easily rolled back to a previous state?
- Documentation: Is the DevOps configuration documented? Codified in code, or in another fashion?
- Who has the keys: Particularly with mobile apps, who controls the keys to the App Store accounts, and how will they be transferred when needed?
Scale, scope, and how to prepare for a tech audit
With a tech audit, depending on the focus of the audit and the size of the codebase, we typically expect to spend somewhere between 10-40 billable hours over a week or two. A big factor in the timeline is how quickly we can get access to the various components of the codebase, including keys and environment access.
At its simplest, a tech audit can tell you if a codebase is reasonably maintainable and is in a good state to be iterated and developed on. On the more complex end of the spectrum, given more time if the project priorities align, we can dig into more intense security concerns and codebase brittleness, which is a big factor in future scalability.
If you are considering backing a tech startup, we highly recommend pursuing a tech audit as a part of your due diligence. It may not change your mind about whether to back the company, but it will help you and the startup to make smart choices about how to tend and grow the technology in a scalable, sensible way. And of course, if you're interested in talking with us about a possible tech audit, reach out, we're always happy to talk about potential projects.
Header photo by Edgar Chaparro on Unsplash
