Ask five people what technical due diligence means, and you’ll get seven different answers. You’ll hear people talk about code quality, fancy frameworks, a few hundred checkboxes, and maybe a dashboard that hasn’t been updated since England won the World Cup. Despite good intentions, many technical due diligence efforts remain surface-level. They zoom in on the codebase or infrastructure, but miss the context that gives it meaning: the humans, the processes, and the product itself.

At madewithlove, we’ve run technical due diligence audits across well over 100 seed and Series A startups and scale-ups. We've seen promising ventures with strong engineering teams fall apart because of poor documentation or an invisible roadmap. We’ve seen codebases that look fine on the surface but hide brittle deployments and non-existent testing underneath. And we’ve seen teams doing incredible work, but lacking the organisational scaffolding to keep it up at scale.

So yes, traditional technical due diligence is broken. Not because people don’t care, but because most of the industry is still looking in the wrong places. It’s time we changed this.

The failure of checklist thinking

Most technical due diligence still works like a compliance ritual. Code quality? Tick. Monitoring? Check. Testing? Double check. But this approach assumes that risk lives only in tech, not in team dynamics, decision-making habits, or scaling constraints. That’s never the case.

Our experience shows otherwise. The biggest risks to your investment are rarely buried in code complexity. They’re hiding in plain sight: inside weak delivery pipelines, vague roadmaps, bottlenecked knowledge, or a lack of feedback.

That’s why we evaluate five interconnected pillars during our technical due diligence:

  1. Team & leadership
  2. Process
  3. Documentation
  4. Engineering & tooling
  5. Product alignment

Let’s explore the most common risks we’ve uncovered over the past couple of years, and what they reveal about a Seed or Series A’s future.

Technical due diligence on the team: heroes and hazards

In early-stage companies, it’s common for a few engineers to carry the weight of the system. But if those people are the only ones who know how key features work, you've got a knowledge silo, not a team.

We also encounter feedback deserts: environments where junior devs never get coached, retrospectives are rare, and learning is accidental. There might be goodwill and hustle, but without scalable practices, failure is just around the corner.

Technical due diligence often reveals:

  • No scalable onboarding process
  • Feedback and mentorship are ad hoc or missing entirely
  • Pair programming is minimal
  • No structured learning or career growth paths

When your moat is your team, this is where you should be looking first.

Due diligence on process: behind the rituals

A company says it deploys continuously. In practice, their senior dev runs a script once a week when they feel brave. Migrations are done manually. Incidents are handled in Slack, based on memory and goodwill.

Great process isn't about following Scrum. It's about reliability, clarity, and continuous improvement. During technical due diligence, we often find process is treated as an afterthought.

Common findings:

  • Manual and brittle deployments
  • No formal incident response or rollback strategy
  • Code reviews done by one person (or none)
  • Support is reactive and informal

Bad processes are not only inefficient. They’re future blockers.

Documentation, if it exists at all

Documentation isn't sexy, but it's your organisation’s collective memory. During technical due diligence, we look for operational clarity, technical transparency, and alignment on how things actually work.

Instead, we often find:

  • Documentation split across languages, tools, and formats
  • API docs last updated during the crypto boom
  • No user-facing technical content
  • Internal wikis that start strong, then die quietly

Lack of documentation slows onboarding, increases bugs, and turns simple changes into archaeology. Good technical due diligence asks not just what’s written down, but how findable, current, and useful it is.

Engineering due diligence: signs of stress below the surface

Engineering is where shortcuts accumulate quietly. Unlike process or product issues, technical flaws are often tolerated for the sake of velocity, until one deployment turns into a dangerous firefight.

When we assess engineering health during technical due diligence, we're not chasing elegance. We're looking for signs the system can absorb change, survive failure, and support a growing team without imploding.

What we often find:

  • Code duplication that bloats every estimate
  • Dependencies that haven’t been updated since the last major framework release
  • Credentials left exposed in the codebase, waiting to be discovered by the wrong person
  • No exception logging or crash tracking in place: if the app breaks, no one knows
  • Tests that are missing, unreliable, or actively ignored
  • Monitoring that either doesn’t exist or pings the wrong person at 3am
  • Git histories cluttered with stale branches and ancient merge requests
  • Backup systems that exist in theory, but have never been tested in practice

Writing beautiful code is not the same as good engineering. It’s about building systems that don’t fall apart under pressure. During technical due diligence we’ll find cracks and dents in the code, but more importantly, we’re checking whether anyone’s patching them.

Technical due diligence on product: metrics, vision, and prioritisation

Every founder says they have a roadmap. During technical due diligence, we ask to see it. Often it’s in someone’s head. Prioritisation is done by gut feeling, or based on who shouts the loudest. Metrics? Maybe a monthly MRR (monthly recurring revenue) chart. That’s it.

But real product alignment matters. It tells us whether this team will scale its efforts in the right direction, or just build faster in circles.

We often uncover:

  • No documented product vision
  • Metrics exist but don’t guide decisions
  • The backlog is too large to be useful
  • Little or no structured user research
  • A team who don’t know where to find a roadmap

If product strategy isn’t informing technical decisions, you’re building on assumptions.

What better technical due diligence looks like

Done well, technical due diligence connects the dots. We don’t need more checkboxes, but we need need better questions. We don’t need more dashboards, but honest stories about how a company works today and how it might break tomorrow. Technical due diligence explains how weak testing leads to delayed releases. How lack of documentation slows onboarding. How team silos create knowledge risk. Tech dd doesn’t only list the problems, it should map the impact as well.

At madewithlove, we bring together senior staff engineers and fractional CTOs who’ve helped dozens of SaaS companies scale. Our approach to technical due diligence is not only the code review. It’s a full-body scan of the organisation, with empathy and clarity built in. We don’t expect perfection. We care about clarity. About surfacing the invisible risks before they turn into real problems. About understanding not just what was built, but how, by whom, and with what trade-offs.

That’s what technical due diligence should be. And that’s what we do.

In our report, we are fearlessly honest. We speak the truth, even when it's hard to hear. Our audit reports bridge the gap between technical and non-technical people.

If you’re preparing for an investment round or assessing one, technical due diligence can reveal what pitch decks don’t: how resilient the business is once the buzz fades and the real work begins.