In part one of my series on technical diligence, I discussed how companies can effectively prepare for the diligence process, and how it's important to understand the business-specific factors that play into it. In part two, I'm honing in on the technology preparation itself. Here are some technology-specific concepts to keep in mind when preparing for technical diligence:
Could this technology or product survive a storm, competitor, or hack? Is the development team constantly reviewing and looking over various risks and how to manage them? Risk management is a science and an art. Make sure your team is filled with artists.
We once had bad storms which took a bunch of servers down and put my clients in trouble for having features and products that were down for enterprise level clientele. The system administrator never considered weather-related issues and had no backup plan. It was a terrible experience for everyone and showed that, while the technology seemed "fine," there was zero risk management in place which alarmed investors.
Something I see especially in companies that do not have a strong CTO with experience in scaling companies is development budgets that are either astronomically high, filled with development fraud or do not provide any reasonable value in return. I was once asked by a venture capitalist or "VC" to restructure a startup. While going through the bills I noticed about $20,000 a month in "development fraud" aka hours billed for work coded or logged but not actually done. Any excellent CTO should be able to recite and justify the exact costs of everything for technology.
Development Meetings and Reporting
Not all investors care about this topic but I know of several firms who do: especially for startups and technology companies it's important to see how tech works with the other departments and itself. Does the CTO actually share knowledge with other developers? How is development executed and measured? Investors, even if not technical, look at how technology and product departments interact with everything else.
I rarely see this point addressed in technical diligence, but it comes up later after funding and creates huge problems. The issue with development ROI is that the CTO or technical team might have the better idea of what to build based on ROI and forget the reasoning. Later on, the board might have an idea of what is important, which is why logic around development budgets and ROI should be addressed sooner and later. Why build an API before the new platform? Because the API has an ROI of 4x and the platform 2x... these are things to think about while in technical diligence. See 5 Tips for Maximizing Your Development Budget.
Having the Right Development Talent in Place
Sometimes having an outsourced development team is sufficient for gaining the traction needed, and development firms can be a reasonable solution. Other times, especially technology heavy products, you need strong developers with language and coding skills relative to that product. Having a "great coder" is not good enough, you need a "great coder" who has "exact experience" in the product you are wishing to build.
Raising capital is not an easy process yet this journey always creates a stronger startup or company whether or not the funding follows. Surely there will be issues later on like when your investors want one thing and your customers another, or when your VCs don't get things the way you do, but early preparations of diligence can mean big dollars later on when the company needs them most.
About the Author
Ellie Cachette is General Partner at CCM Capital Management, a fund-of-funds specializing in venture capital investments. CCM invests into venture capital firms who then invest into startups. For more information on Ellie or her firm visit www.cachettecapital.com.