How to Run Technical Due Diligence on a Dedicated Software Team

When Herre Roelevink was building the operating model that would become Manifera, he was working from the other side of a problem most CTOs only encounter once they are already committed: how do you prove technical rigor to a skeptical European engineering leader who has been burned by an offshore vendor before? His answer was not a sales pitch — it was building the governance and code review discipline first, then letting due diligence hold up under scrutiny. That same discipline is what this article asks you to go looking for before you sign with any dedicated software development team, not just ours.

Most CTOs treat vendor evaluation as a soft process — reference calls, a portfolio review, a gut feeling from the sales conversation. That approach misses what a technical deep-dive can actually surface: concrete, verifiable evidence of engineering maturity that predicts how the partnership will perform under real pressure, six months into a live sprint. This guide walks through five specific artifacts to request, what “good” looks like in each, and what a red flag looks like when you see one.

This matters more for a dedicated software development team specifically than for other outsourcing models, because a dedicated team is meant to function as a long-term extension of your engineering org, not a short-term contractor pool. The quality bar you set during due diligence effectively becomes the quality bar for every sprint over the life of the engagement — there is no natural checkpoint later where you get a second chance to raise the standard without a difficult renegotiation. That asymmetry is exactly why the artifacts requested here need to be concrete evidence, gathered before signature, rather than trust extended on the strength of a confident sales conversation.

Why Technical Due Diligence Belongs Before the Contract, Not After

Once you sign a contract with a dedicated software development team, your leverage to demand process changes drops sharply — you are now managing a live engagement, and every friction point becomes a delivery risk instead of a hypothetical evaluation criterion. The evidence you request during due diligence should be concrete artifacts, not descriptions of process. Anyone can describe a rigorous code review process in a sales call; far fewer vendors can produce an actual pull request thread showing that process in action, with real comments, real revision requests, and a real merge decision.

Structure your due diligence around five categories: codebase quality evidence, CI/CD pipeline maturity, architecture documentation practices, performance benchmark history, and security posture. Each should be requested as a concrete artifact — a redacted pull request, a pipeline configuration file, a system diagram from a past project, a load test report — rather than a verbal assurance.

Auditing the Codebase: What Evidence to Request

Ask for a redacted, representative code review thread from a recent sprint on a comparable project. You are not evaluating whether the code is perfect — you are evaluating whether the review process catches real issues before merge. A healthy thread looks something like this simplified example:

PR #482: Add retry logic to payment webhook handler
Reviewer comment: "This retry loop has no backoff — under a provider
outage this will hammer the endpoint. Suggest exponential backoff
with a max of 5 attempts and a dead-letter queue for failures."
Author: "Good catch, updated with backoff + DLQ, added test case
for the failure path."
Reviewer: "Approved. Nice test coverage on the edge case."

That exchange demonstrates exactly what you want to see: a reviewer catching a real production risk, not just style nitpicks, and the author responding with a substantive fix plus test coverage rather than a defensive dismissal. If a vendor cannot produce anything resembling this — reviews that are purely “LGTM” approvals with no substantive comments — that is a meaningful signal about how much real quality control exists beneath the process description in their sales deck. Also ask for their current test coverage percentage on an active project and how it trends over time; a team that treats coverage as a vanity metric checked once at project kickoff behaves very differently from one that tracks it every sprint.

CI/CD Pipeline Maturity: The Questions That Reveal Real Practice

Ask specifically how many deployments to production the team completes per week on their most active project, and what percentage of those require a manual rollback. A team with mature CI/CD practices — automated testing gates, staged rollouts, feature flags — will have concrete numbers ready, because they track this as an internal engineering metric already. A team without this maturity will answer in generalities (“we deploy regularly”) because they are not actually measuring it.

Request a redacted CI/CD pipeline configuration file if possible. Even a partial view tells you whether automated testing genuinely blocks a broken build from deploying, or whether the pipeline exists mostly as documentation with manual overrides used routinely in practice. This single artifact often reveals more about engineering discipline than an hour of conversation, because a pipeline configuration cannot be talked around the way a verbal answer can.

Also ask specifically about their branching strategy and how hotfixes reach production outside the normal release cadence. A team with a clearly defined process — trunk-based development with short-lived feature branches, or a well-documented Git Flow variant, paired with a defined emergency hotfix path that still runs through automated tests — demonstrates the kind of discipline that prevents a Friday-afternoon production incident from turning into a weekend-long outage. A team that improvises this process on the fly, deciding case by case how a hotfix gets deployed, is telling you that under pressure, their process becomes whatever is fastest rather than what is safest.

Architecture Review: Requesting a Real System Diagram

Ask for an architecture diagram from a past project of comparable complexity, and have your own team review it critically rather than accepting it as a formality. Look specifically for how the diagram handles failure domains — is there a single point of failure clearly called out with a mitigation strategy, or does the diagram only show the happy path? A team with genuine architectural maturity documents failure modes and scaling boundaries as a matter of course; a team producing diagrams purely for sales purposes tends to show only clean, idealized data flow with no discussion of what breaks under load.

This is also where full-stack capability becomes a meaningful evaluation criterion rather than a marketing phrase. A team that can speak credibly across frontend architecture, backend API design, DevOps pipeline structure, and QA strategy in the same conversation demonstrates the kind of end-to-end ownership that full-stack capability is meant to describe — as opposed to a team that hands off between disconnected specialists with no shared architectural view of the system.

Push further by asking the team to walk through a specific architectural tradeoff they made on a past project and why they chose one approach over an alternative — for example, why they chose a message queue over synchronous API calls for a particular integration, or why they selected a relational database over a document store for a given data model. The specificity and confidence of the answer tells you whether the diagram reflects genuine decisions made by the people in front of you, or a template assembled by a different team for presentation purposes.

Performance Benchmarks: The Numbers Worth Asking For

Request p95 and p99 latency figures from a live or recent production system the team built, along with the load-testing methodology used to establish those numbers. Vague claims like “fast and scalable” are not evidence; a specific p95 response time under a specified concurrent load, measured with a named tool such as k6 or JMeter, is evidence. Ask how the team responds when a performance regression is detected in staging — is there an automated alert tied to a performance budget, or does the issue only surface after a user complaint in production?

This is also a natural point to ask about the technology stack directly relevant to your project. A team working across custom software development engagements spanning Laravel, .NET, Node.js, and Python should be able to speak specifically to performance characteristics and tradeoffs of the stack relevant to you, not offer a generic answer that could apply to any technology.

It is also worth asking how the team distinguishes a genuine performance regression from normal variance in test results — a mature team will have a defined threshold and statistical approach, such as comparing p95 latency across a rolling window of builds rather than reacting to a single noisy test run. Teams without this maturity tend to either chase every minor fluctuation as an emergency or, more dangerously, ignore a real regression because it gets lost among frequent false alarms.

Security Posture and Compliance Evidence

Ask for evidence of how the team handles dependency vulnerability scanning, secrets management, and access control on client repositories. A mature team will have automated dependency scanning integrated into their pipeline, flagging known CVEs before they reach production, rather than relying on periodic manual audits. If your project involves EU customer data, confirm the team’s data handling practices align with GDPR requirements specifically, not a generic security policy that predates any EU compliance work. You can review the broader technical capabilities underpinning this kind of evidence on Manifera’s technology page, which documents the stack and tooling used across live engagements.

Finally, ask how the team manages access provisioning and revocation as their roster changes over the life of an engagement — a question that becomes especially relevant for a dedicated team you expect to work with for a year or more. Confirm there is a documented offboarding checklist that revokes repository, cloud console, and third-party service access within a defined window when an engineer rolls off the project, rather than relying on someone remembering to do it manually. This is a small operational detail that rarely comes up in a sales conversation, but it is exactly the kind of gap that surfaces during a SOC 2 audit or, worse, after a security incident.

Building Your Due Diligence Scorecard

Score each of the five categories — code review evidence, CI/CD maturity, architecture documentation, performance benchmarks, and security posture — on a simple scale before comparing vendors, rather than relying on an overall impression after a series of calls. This is precisely the combination of Scrum discipline from the Netherlands with Vietnam’s deep technical talent pool that separates a dedicated software development team built for enterprise-grade delivery from a lower-cost alternative that cannot produce this evidence on request. A vendor confident in their engineering practice will welcome this level of scrutiny, because the artifacts speak for themselves.

Weight the categories according to what actually matters for your specific project rather than treating all five equally by default. A data-intensive fintech platform should weight security posture and performance benchmarks heavily; an early-stage product still finding its market fit might weight architecture flexibility and CI/CD speed more heavily, since the ability to iterate quickly matters more than long-term scaling concerns at that stage. The scorecard is a tool for structured comparison across vendors, not a rigid formula — use it to make an implicit judgment explicit and easier to defend to your own leadership when you present a final recommendation.

Request a custom team proposal within 48 hours and ask us to walk you through exactly this kind of evidence for a team matched to your stack — we would rather earn the engagement through scrutiny than around it.

A Weighted Scoring Rubric for the Five Categories

Score each of the five due diligence categories on a 1-5 scale, then apply weights matched to your project’s actual risk profile rather than splitting evenly. A reasonable default weighting: code review evidence 25%, CI/CD maturity 20%, architecture documentation 20%, performance benchmarks 15%, security posture 20% — adjusted upward on security and performance for regulated or high-traffic products. A vendor scoring below 3 on any single category should trigger a follow-up request for more evidence before you proceed, regardless of how strong the overall weighted average looks, since a single weak category (commonly security posture, in our experience reviewing vendor evidence) tends to be where the real operational risk concentrates.

Set a numeric pass threshold before you start scoring, not after — a weighted average below 3.5 out of 5 across all five categories is a reasonable bar for a dedicated team engagement expected to run 12+ months, since the cost of a mismatch compounds over a long engagement in a way it would not for a short project. Concretely, a team that cannot produce a p95 latency figure with a named tool (CI/CD/performance gap), has only “LGTM” pull request comments (code review gap), or has no documented offboarding checklist (security gap) should each cost roughly one full point off that category’s score, not a fractional deduction — these are binary maturity signals, not matters of degree.

FAQs