Our process

A due diligence may take from four to eight days or more to complete, depending on the selected service and availability of key people.

• Meet with you to learn about you, your goals, and the company in which you intend to invest.
• Establish contact with the company’s CTO or equivalent and explain the process.
• Prepare a detailed and tailored preliminary questionnaire, to be completed by the CTO, so we are prepared for the site visits.
• Site visit day one - explore roles and responsibilities, product demos, CTO presentation, the product building process.
• Site visit day two - risk management, individual interviews.
• Site visit day three (Kilimanjaro service and higher) - project manager(s) interview, architecture review, source code exploration, team review, ad-hoc interviews with other team members.
• Site visit day X (Everest service) - bespoke offering.
• Compile report.
• Present you with the report and recommendations.

Our unique methods

We’re actual software developers and know who to talk to and what questions to ask. Here are a few examples that you don’t encounter in a typical due diligence:

• Approach the quiter developers at random and ask them questions and to perform certain tasks.
• Create a development environment from scratch.
• Find out if there have been any breaches. If so, do a deepdive into how it happened. How are reoccurences prevented?
• Click through the monitoring dashboard.
• Log into services in a private browser. Was the user prompted to do a second authentication via a mobile device?
• Look at activity on issue tracking and project management systems, eg. Jira.
• Inspect webserver logs for discrepancies with eg. Google Analytics.
• Compare production and QA environments. Are they close enough?
• Read a few code reviews.
• Log into a server. Did the person use a password or a public key?
• Open a session on a live database and look for clear text password fields and banking details.
• Look at the automated testing framework, eg Jenkins or Travis, and trigger a build.
• Browse the installed software on workstations. If not open source then are the licenses in order?

Finally, things you never encounter in a due diligence:

• Do an actual production deploy.
• Deliberately check in broken code. Are there safeguards in place?
• Do an impromptu failover test on a production system by restarting a server.