Section 1 - Assessment
During the first part, we try to understand:
- How the product has been built until TODAY
- If it will work TOMORROW when success brings trouble - no trouble, no success ;-)
We don’t expect everything to be perfect. Rather, we try to understand where your product is today, how you’ve built it and what kind of compromises you chose.
2.a Has all the software been coded in-house?
- (3p) YES. Except for Opensource, APIs...
- (1p) NO. Non-core parts were outsourced
- (-1p) NO. Some core parts outsourced
- (-10p) NO. Everything outsourced
Our opinion: We expect that the main components of the software have been developed in-house. That said, we also understand that some areas might be outsourced. For example, marketing/landing sites of SaaS companies.
Third party APIs and open source libraries are a topic of further examination later.
When important parts of the product have been outsourced, the bar is higher in the other areas of the due diligence (team, market, traction, etc.).
2.b Is the person who wrote the initial version still the main developer?
- (+0p) Yes
- (-5p) No
Our opinion: Developers don't like to inherit code at this stage when apps tend to be big monoliths. It's common that if they do it, they re-factor (or re-build) big chunks of the software.
2.c Did you build a similar product in the past?
- (+2p) Yes
- (0p) No
Our opinion: That can bring extra development speed and reliability.
2.d Are there any parts in the system that are understood by only one person?
- (+0p) YES. Me!
- (-1p) Yes, developer WITH equity
- (-2p) YES, developer WITHOUT equity
- (+2p) NO
Our opinion: Unfortunately, a lot of early stage teams don’t survive for long time together. The level pressure and commitment required can be overwhelming for some of the founders.
That also includes founder-CTOs who feel the extra pressure to ship the product.
Ideally, there should be some degree of redundancy in the team about the knowledge on how the key aspects of the product are built.
3.a What do you optimize for?
- (0p) Speed of development
- (0p) Reliability of the system
- (-2p) Speed AND Reliability
Our opinion (Controversy ahead): There's no right answer choosing between those two (Reliability and Speed). It depends on your business - e.g. if it's a payments company, better to focus on reliability.
By focusing on speed OR reliability, your team will be aligned and they will know what to do without extra processes and management.
We think that, with the limited resources available in an early stage startup, you can't focus successfully on both at the same time. In our opinion, it's a trade-off and you have to choose.
3.b How many major releases have you had in the last year?
- (-5p) 1
- (-3p) 5
- (0p) 12
- (+5p) I don’t know, we release continuously
Our opinion: Try to iterate as many times and as fast as possible. The more often you ship your product to your customers, the easier it becomes to build what they need based on their feedback.
3.c How do you choose build vs buy?
- (0p) BUY is first choice
- (-5p) BUILD is first choice
- (-1p) We look at engineering hours to BUILD vs buy
- (+2p) We look at engineering hours to BUILD & MAINTAIN vs buy
Our opinion: Plenty of times, at that early stage, the answer is to buy to focus your limited resources on the core product.
But if you understand the full cost of building AND maintaining (which usually is hidden), then it’s even better if you choose.
3.d Which payment system do you use?
- (0p) 3rd Party (braintree, paypal, stripe, adyen...)
- (0p) NO payment system in place
- (-10p) Custom solution. Built in-house
Our opinion: Unless you’re a payment provider, please DO NOT build your own payment gateway :) It’s a critical piece of your software and it will take a lot of effort to build and maintain.
3.e Are some clients paying outside of the payment system?
- (-2p) Yes
- (0p) No
Our opinion: Every exception adds complexity that you can't probably afford at the early stage.
If you have customers who are outside of your payment system, that means it will be harder to build a process around them. It will also make it hard to gather business metrics and understand your business.
If you have them, hopefully they pay more than the average customer, so the extra effort is justified.
3.f Which invoicing system do you use?
- (0p) 3rd Party
- (0p) NO payment system in place
- (-5p) Custom solution. Built in-house
Our opinion: Unless you’re an invoicing system company, please DO NOT build your own :)
For similar reasons to the payment system, it’s a critical piece of your software and it will take a lot of effort to build and maintain it.
It will also reduce your speed of iteration because very early on, you will have a legacy system/tech debt in place.
4. Monitoring
4.a What are you monitoring?
- (+1p) Application performance
- (+1p) Application security
- (+1p) Infrastructure performance
- (+1p) Website monitoring
- (+1p) Exception monitoring
- (+1p) Other
Our opinion: Please set up monitoring early. It will help you debug problems when you have them :)
You might not need all those tools so early, but at least make sure you get decent coverage.
4.b Do you have internally developed monitoring solutions?
- (-2p) Yes
- (0p) No
Our opinion: DO NOT build your own systems so early.
Even if it’s a cool project, it’s a divert of your limited resources. Also, the cost of maintenance in terms of engineering hours will be bigger than you think.
4.c Did you measure the current max capacity of the system? Do you know how much it can support?
- (+2p) Yes
- (0p) No
Our opinion: Good to load test the system to learn about potential problems in dev env.
4.c How often do you SSH machines for debugging?
- (-5p) Always
- (-3p) Often
- (0p) Almost never
- (+2p) Never. Devs can't SSH machines
Our opinion: If devs can’t access machines, then they will set up monitoring properly.
If they have access to the logs, then they will probably monitor some metrics but with the confidence that they can pull logs when needed. If every time that there’s a new problem they go into the machine to collect more data, your monitoring system will not serve its purpose.
5. Compliance and Security
5.a Are you using any 3rd party data?
- (0p) yes, we have a license for it
- (-1p) yes, we crawl it - but it’s not critical
- (-2p) yes, we crawl it and it’s critical
- (0p) no
Our opinion: Crawling comes with responsibility ;-)
5.b Are you monitoring the licenses of 3rd party software?
- (0p) yes, only desktop and server;
- (+1p) yes, including libraries and opensource packages
- (-2p) NO
Our opinion: be aware of your potential liabilities there. Specially important might be the usage of OS licenses that might disturb an M&A process.
5.c Is your Version Control system backed up?
- (+2p) Yes, in third party storage
- (0p) No, including local copies of git
Our opinion: Your laptops can be stolen, cloud can fail ... and you’re gone. Worth investing a bit of money on having a further layer of redundancy here.
5.d If the Database Server exploded, how much client data would be unrecoverable?
- (-10p) 100%
- (-5p) 50%
- (5p) 0%
Our opinion: Please backup customer’s data with enough redundancy.
At least, the most critical information.
5.e Do you have a Disaster Recovery plan?
- (+1p) yes
- (0p) no
Our opinion: Nice to have (or to think about it, at least) at an early stage