The Technical Due Diligence Nobody Prepares For

During my time as CTO at OneRagtime, I led technical due diligence on startups in the deal flow. The fund screened over 4,000 deals per year, and for the ones that made it past the first filters, someone had to look under the hood. That someone was usually me.

After auditing dozens of companies, patterns emerged. The technical issues that killed deals were rarely what founders expected. And the things that impressed investors were often the most mundane parts of the stack.

Here is what I learned.

What Investors Actually Care About

Investors do not care about your framework choice. They do not care if you use React or Vue, Python or Node, AWS or GCP. Those are implementation details. What they care about is whether your technical foundation can support the business you are trying to build.

The three questions that drive every technical due diligence are simple. Can this team ship fast enough to hit their milestones? Will the technology scale with the business? Are there any hidden risks that could blow up after we invest?

Everything else, the specific tools, the architecture patterns, the coding style, is evaluated through the lens of those three questions.

The Red Flags That Kill Deals

No tests, no CI/CD. This is the most common red flag, and it is almost always a deal-breaker. If a startup has no automated tests and no continuous integration pipeline, it tells me two things: they cannot ship with confidence, and they are accumulating risk with every deployment. I have seen startups with beautiful code but zero tests. It does not matter how clean your code is if you cannot verify it works after every change.

Single point of failure in the team. If one person wrote 90% of the codebase and that person is the founder, what happens when they need to hire? What happens when they get sick? I always ask: "If your lead developer left tomorrow, how long before the team could ship a feature independently?" The answer tells me everything about knowledge distribution and documentation.

No separation of environments. Startups that deploy directly to production without a staging environment are playing with fire. I have seen teams that test in production because "it is faster." It is faster until it is not. One bad deployment to a production database and you are explaining data loss to your users.

The "rewrite" conversation. When founders tell me they need to rewrite their entire codebase, I get nervous. Sometimes a rewrite is genuinely necessary. But more often, it means the team made poor architectural decisions early on and never addressed them incrementally. A team that cannot refactor incrementally is a team that will face the same problem again after the rewrite.

Over-engineering. This one surprises people. I have killed deals because a five-person startup had a microservices architecture with twelve services, a Kubernetes cluster, and a message queue, all serving a few hundred users. This tells me the team optimizes for technical elegance over business impact. It also means their infrastructure costs are probably ten times what they should be.

What Impresses Investors

Clean deployment pipelines. A team that can deploy to production multiple times a day with confidence is a team that can iterate fast. At OneRagtime, the startups that impressed me most had simple, reliable CI/CD pipelines. Not complex ones. Just ones that worked every time.

Monitoring and alerting. When I ask a founder "how do you know when something breaks?" and they show me a dashboard with real metrics and alert thresholds, I know they take reliability seriously. Most early-stage startups have no monitoring at all. They find out about outages when users complain.

Documentation of decisions. Not code documentation, though that helps. I mean records of why the team made the choices they made. ADRs (Architecture Decision Records) or even a simple document explaining "we chose PostgreSQL because X, we will reconsider when Y" shows me a team that thinks deliberately about their technical direction.

Data model quality. The database schema tells me more about a startup's technical maturity than any other artifact. Clean table structures, proper indexing, clear relationships between entities, and no obvious normalization issues. When I see a well-designed data model in an early-stage startup, I know the technical lead understands what matters.

Honest about technical debt. Every startup has technical debt. The ones that impress me are the ones that can point to it and explain the trade-off. "We cut this corner because we needed to ship by Q3. Here is our plan to address it." That is a thousand times better than "our code is perfect" or a founder who does not know where the debt is.

The Patterns Nobody Talks About

Some patterns only become visible after you have seen enough companies.

Team velocity matters more than code quality. A team shipping features weekly with messy code will outperform a team shipping monthly with clean code. Code quality matters, but only insofar as it affects the team's ability to keep shipping. I have invested in startups with ugly codebases that were moving fast and growing revenue. I have passed on startups with beautiful code that were stuck in analysis paralysis.

The founder's technical depth sets the ceiling. Even in startups where the founder is "non-technical," the most successful ones have a co-founder or early hire who genuinely understands system design. When I audit a startup and the technical lead cannot explain their own architecture clearly, it signals a problem that will only get worse as the team grows.

Infrastructure costs reveal priorities. I always ask to see the cloud bill. Not because I care about the exact number, but because it shows me where the team is spending. A startup burning thousands per month on infrastructure while serving hundreds of users has a cost discipline problem. A startup running lean with smart resource allocation shows me they understand that cash is finite.

How to Prepare

If you are a founder preparing for technical due diligence, here is what I would do.

First, make sure you can deploy confidently. Set up CI/CD if you have not already. Write tests for your critical paths. This is not optional. It is the baseline expectation.

Second, know your architecture. Be able to draw it on a whiteboard and explain why each component exists. Know the trade-offs you made and which ones you would make differently today.

Third, have your metrics ready. How many deployments per week? What is your uptime? How long does it take to onboard a new developer? These numbers tell the story of your engineering culture more than any slide deck.

Fourth, be honest about your debt. Every auditor knows you have it. Trying to hide it is worse than having it. Show me you know where it is and that you have a plan.

The Bigger Picture

Technical due diligence is not just about finding problems. It is about understanding whether a team has the engineering culture to succeed. The best startups I audited were not the ones with the fanciest technology. They were the ones where the team shipped consistently, communicated clearly about their trade-offs, and built systems that matched the actual needs of their business.

That is what I look for. And it is what I try to build in every team I lead.