Technical due diligence: vetting your vendor before you sign
Technical due diligence is a structured review of a vendor's technical capability before a major commitment. Beyond references and case studies, it means asking to see work samples, development processes, and security practices. For larger deals, an external reviewer can provide an independent second opinion, while smaller projects can get by with a lighter, scaled-down format.
References and polished case studies tell you something, but they’re curated – the vendor shows its best side. Before a large, long-term commitment, you want to know more than that things went well before. Technical due diligence is the structured review of the capability behind the results: how the vendor builds, tests, and protects what it delivers. Here’s what you can ask for, when an external reviewer pays off, and how to scale it right for smaller projects.
What you can ask to see
A serious vendor is used to being reviewed and answers openly. Three things are reasonable to ask for, beyond references:
- Work samples. Code examples or a walkthrough of a previous system show how they actually build – structure, readability, quality. Much of it will be confidential, but a vendor that can’t show anything at all is a warning sign.
- Development processes. How is the work planned, built, and quality-assured? How is it tested, and how are discovered bugs handled? A well-thought-out process is what makes quality repeatable instead of random.
- Security practices. How is sensitive data, access, and vulnerabilities handled? How do they stay current as new threats emerge? The more sensitive your system, the more important the answers become.
Also ask to meet the people who will actually work on your project, not just the salesperson. The company’s overall track record says little about what your team can do.
A second opinion from an external reviewer
Sometimes the commitment is so large, or the technology so hard to judge, that you need help reviewing it. Then an independent technical reviewer can be brought in for a second opinion.
A reviewer like that can assess things a buyer without a technical background struggles to judge alone: does the code quality hold up, are the architecture choices sound, are there hidden risks in how the system is built? For an investment of several million kronor in a system the business will lean on for years, the cost of an external review is small compared to what it can catch. A risky choice discovered before signing is infinitely cheaper than one discovered after launch.
The external reviewer thus fills the role of an independent assessor between you and the vendor – someone whose only job is to look critically at what you’re about to buy.
A scaled-down format for smaller projects
Full due diligence is the wrong tool for a small assignment. A heavy review process around a project worth a few hundred thousand kronor would cost more in time than it protects. But you shouldn’t buy completely unchecked either – the solution is a scaled-down format:
- Ask for a couple of code examples and look at structure and tidiness.
- Ask a few targeted questions: how do you ensure quality, how do you test, how do you handle bugs after launch?
- Consider a small, well-defined trial delivery before the major commitment – a discovery phase or a first module.
That gives you much of the confidence of a full review at a fraction of the effort, proportional to the size of the project. The point of due diligence is matching the scope of the review to what’s at stake.
A concrete scenario
An organization was about to commission a business-critical system worth several million kronor. Two vendors remained, with comparable case studies and good references. On paper, they were hard to tell apart.
At the due diligence step, they asked both vendors for code examples, a process description, and a meeting with the proposed team. One showed carefully crafted code, a clear test strategy, and a well-coordinated team. The other was evasive about work samples and couldn’t concretely describe how quality got ensured. The references had looked identical – the review didn’t. The choice became easy, and it rested on capability rather than sales pitch.
Review at the right scale
Technical due diligence isn’t about mistrust – it’s about making a major decision on better grounds than a brochure. Match the depth to the stakes: a scaled-down format for the small project, a thorough review – ideally with outside help – for the large and critical one.
At Weapp, we’re used to being reviewed, and we also carry out technical assessments of systems and vendors ourselves as part of our services. Facing an important vendor choice? Get in touch, and we’ll talk through what a right-sized review could look like for your project.
Frequently asked questions
What's the difference between due diligence and checking references?
References tell you how previous projects went, often from satisfied customers' perspective. Technical due diligence looks under the hood at how the vendor actually works – code quality, processes, security. References say something about the outcome, due diligence about the ability to repeat it. They complement each other; neither replaces the other.
What can you reasonably ask to see?
Work samples or code examples, a description of the development process and how quality gets ensured, and security practices. You can also ask to meet the people who will actually work on the project, not just the salesperson. A serious vendor is used to these questions and answers openly, within what confidentiality allows.
When is an external reviewer worth the money?
When the commitment is large and technically hard to judge yourself. If you're investing several million kronor in a system you'll depend on, an independent technical reviewer can provide a second opinion that easily pays for itself by catching risks early. For smaller projects, the cost of a full-scale review is usually not justified.
How do you do due diligence on a small project?
With a scaled-down format. Ask for a couple of code examples, ask a few targeted questions about how they ensure quality and test, and consider a small, well-defined trial delivery. That gives you much of the confidence of a full review at a fraction of the effort, without becoming a heavy process out of proportion to a small assignment.
What warning signs should you watch for?
Reluctance to show work samples or reveal the team behind the salesperson, vague answers about how quality and security get handled, and promises that everything is easy. A vendor that can't describe its own process, or never seems to have hit a problem, either has little experience or is hiding something. Both are reasons to dig further.