How to prepare to startup Technical Due Diligence
So, you sign up for the accelerator program and book a Tech DD call. Let's get you prepared for it. This will save us time and help you to have the highest rank possible.
I'm writing this article to help teams prepare for tech due diligence calls. We are limited with time, so the set of questions and topics is slightly reduced. Original Technical Due Diligence is much deeper and wider.
Two primary goals that we need to achieve:
Confirm you have a working product using a live environment.
Despite the fact this meeting is a Tech, the interviewer need to see your product conducts at least one main end-to-end user scenario without any showstoppers.
Confirm you have dev processes behind the product.
In a perfect world your CTO/Senior dev/Architect should prepare the tech demo in a similar manner. And it will significantly reduce the time needed for the exploration.
Tech DD topics
Topic one: Development
Be ready to show (not share) your Git repositories. Usually, there is no need to take a look into the codebase. We will not score the quality of your CamelCase or indentation/tabulation.
All we need to check is your commit history, branching strategy, and code review approach.
Here we will also check the toolset you're using for development. Languages, frameworks, dev practices, etc.
If you have the hardware part - please prepare the chip schematics/blueprints.
Topic two: Delivery
Here we need to examine how you deliver the code, features or bugfixes to your environments. There are three common ways to do it.
Manual deployment - direct upload used. We need to check the way how you connect to server and upload the code. Security and access restrictions are essential.
Third-party auto-deployment - we gonna check the pipelines for stages. Netlify, Vercel or AWS CodeDeploy are the right tools here.
Separate Build Server with CircleCI, Jenkins or Travis CI - same here. Pipelines, stages,
Topic three: Testing and Monitoring
This is the most embarrassing part of any young product, and there is usually no time and resources for these activities. Anyway, we need to check which Testing Strategy you are using during development and before the customer experiences it.
Manual or autotests. Functional or non-functional. I believe you haven't time to cover all levels of testing. But still, you should have some smoke/regression set of tests.
And the Monitoring. How do you observe the system health, logs and real-time status, debug issues, etc.?
Topic four: Management
Last but not less important is how your team organizes the work. Basically, it's a set of tools and processes to plan, track and control a product lifecycle.
Synchronization between your business goals and development is essential. Having at least the board that represents the current progress status is better than nothing.
How to prepare for SWG Technical Due Diligence call
- Working application in a prod env. Yes, we can check it on dev environment in case you are still in the testing stage.
- Updated technical documentation. Make sure you have at least some high-level diagrams and charts which describe your architecture.
- Your CTO or Senior dev must attend the call. All the tech key team members should be available during the call. In case we will need some clarifications.
- Dev tools and environments should be accessible. We need to check everything quickly.
- Testing and monitoring tools. Prepare the list of your manual test cases used for Smoke, Regression, and Functional testing. There could be Postman Collections, SwaggerUI for API testing, or similar tools.
- Management tools and integrations with your dev toolset. Short overview of your dev process. Check the board and backlog.
Ideally, you prepare the Tech DD pitch deck with slides containing all the info about your dev processes. You are leading me through it. Then we just need to confirm the tools I ask for.
What would be a red flag during the Tech DD?
Some significant reasons to fail the meeting or get a low score:
- We cannot complete the main(primary) scenario during live and workarounds are not obvious.
- You're using the obsolete or zoo-like toolset.
- You cannot explain the reason for using specific tools or practices.
- Your tech team cannot communicate English fluently.