How to prepare to a Quick Technical Due Dilligence session

We are going to start!

So you’ve booked—or you’re planning to book—a QTDDC. Let’s get you ready for it. Good preparation saves us time and gives you the best possible chance of a high score.

This article is meant to help teams prepare for a Quick Tech Due Diligence Call with me. This is the shorter version, intended to keep this first session as efficient as possible. I keep the main part of the call to 45 minutes, so the set of questions and topics is narrower than a full Technical Due Diligence, which is deeper and broader in scope.

There are two primary goals for this call:

Confirm you have a working product in a live environment.
Even though this is a "tech" meeting, I need to see your product complete at least one core end-to-end user scenario live, without any showstoppers. Confirm you have real dev processes behind the product.
Ideally, your CTO, senior developer, or architect prepares the tech demo the same way each time. A consistent walkthrough significantly reduces the time needed for exploration.

Tech DD Topics

What we actually check.

If you have a complex architectural solution and CI/CD, please prepare a short presentation describing it.

1. Development

Be ready to show (not share) your Git repositories. There's usually no need to look at the codebase itself — I won't be checking whether you use CamelCase or indentation. Coding style is something that we can discuss later.

What I do need to check is your commit history, branching strategy, and code review approach, along with the toolset behind development: languages, frameworks, and dev practices.

If your product includes hardware, please also prepare chip schematics and blueprints.

List of common tools here:

• GitHub
• GitLab
• TortoiseSVN
• Perforce

2. Delivery

This covers how you ship code, features, and bugfixes to your environments. Here we’re going to check the pipelines and linting. There are usually three common approaches:

1. Manual deployment. Direct upload to the server.
2. Third-party auto-deployment. You are using any third-party tool for deployment without handling the details.
3. Dedicated build server. Standalone I'll take a look at your pipelines and stages there too.

I'll check how you connect to a production environment and upload your code — security and access restrictions are essential here.

List of common tools here:

• Netlify
• Vercel
• AWS Amplify
• CircleCI
• Jenkins
• Travis CI

3. Testing and Monitoring

This is usually the most exposed part of any young product — there's rarely enough time or resources for it. Still, I need to understand your testing strategy during development and before customers see a release.

Manual or automated, functional or non-functional — you probably don't have time to cover every level of testing, but you should have at least a smoke or regression test set.

The other half of this topic is monitoring: how you observe system health, logs, and real-time status, and how you debug issues as they come up. Nice to have: a bug tracking system.

List of common tools here:

• Sentry.io
• DataDog
• Grafana
• Prometheus

4. Management

Last but not least: how you organise the teamwork — the tools and processes you use to plan, track, and control the product lifecycle.

Keeping business goals and development in sync matters. A kanban board that reflects current progress is far better than nothing.

• Jira
• Trello
• ClickUp
• Slack
• MS Teams

How to Prepare for the Call

Here's a short checklist of what to have ready:

• A working application in a production environment. If you're still in the testing stage, a dev environment is fine.
• Updated technical documentation. At minimum, some high-level diagrams and charts describing your architecture.
• Your CTO or senior developer on the call. Key technical team members should be available in case we need clarifications.
• Accessible dev tools and environments. We need to be able to check things quickly.
• Testing and monitoring tools on hand. A list of your manual test cases for smoke, regression, and functional testing — Postman collections, Swagger UI, or similar tools work well for APIs.
• Management tools and their integration with your dev toolset. A short overview of your dev process, plus your board and backlog.

Ideally, you come with a Tech DD pitch deck covering your dev processes. You lead me through it, and we simply confirm the tools as we go.

What Would Be a Red Flag During the Tech DD?

Make sure these are fixed before the meeting. Common reasons for a low score or a failed meeting:

• The primary scenario can't be completed live, and no clear workaround exists.
• You're using an obsolete or "zoo" of mismatched tools.
• You can't explain why you use specific tools or practices.
• Your tech team can't communicate in English fluently enough to answer questions clearly.

You can schedule the call with me on the pelikhovskyi.tech/contact page.

What’s next? Of course, there are ways to continue our journey, depending on your needs and the results of our Tech DD call!