Red Flags That Can Change an Investment Outcome

What it does, more often than most investors expect, is quietly reshape the terms. It changes valuation. It changes what leadership the business actually needs post-close. It changes how much capital will be required to execute the thesis, and by when. And by the time those things become clear, the deal is already done.

Modern cloud infrastructure, a polished product, and an engineering team with good credentials tell you very little about whether the platform can support the next stage of growth. The issues that matter are usually structural, and they only show up when you look across software architecture, engineering execution, security, operational maturity, and product scalability together because those disciplines don’t fail independently, but as a system.

Throughout my career, I've found that technology diligence isn't about deciding whether a company has good engineers or modern architecture. It's about understanding whether the technology organization can support the investment thesis with an acceptable level of execution risk. Every finding in this paper ultimately points to the same question: What needs to happen after closing to create enterprise value?

These are ten findings that consistently cause me to slow down during diligence. None of them automatically changes the investment decision. Every one of them changes the conversation.

1. Critical Operational Knowledge Lives in Tribal Memory 

The first thing I try to understand isn't the architecture. It's whether the business actually knows how its platform stays healthy.

One pattern I've seen repeatedly is that a production system quietly depends on one engineer doing something manually every few days. It might be cleaning up a database table, adjusting a configuration parameter, restarting a background process, or running a maintenance script that nobody has documented because "it's only needed once in a while."

The platform appears stable. Dashboards look healthy. Customers are happy.

Then the company is acquired.

People leave. Teams are reorganized. Responsibilities change. Six months later the system starts behaving unpredictably and nobody understands why. The person who knew the answer is gone, and there is no documentation explaining what they were doing or why they were doing it.

By then, you're no longer solving a technical problem. You're trying to rediscover how your own platform actually operates.

I've learned that these situations rarely show up during a product demonstration. They surface during conversations with engineers, support teams, and operations staff.

The question I usually ask is simple:

"If this engineer took a two-month vacation tomorrow, what operational knowledge would leave with them?"

Management teams often pause before answering. That pause usually tells me the operational maturity of the organization is lower than the architecture diagrams suggest. 

2. Delivery depends on heroics

The pattern looks like this: releases are consistently late, there are regular deployments over the weekend, production hotfixes are a normal part of life, and engineers are working nights and weekends to hit commitments. Leadership usually describes this as "we have a really dedicated team." That may be true. It's also unsustainable.

Heroics don't scale. When customer growth accelerates, the team that was already stretched becomes genuinely overwhelmed; delivery becomes less predictable, defect rates increase,and the engineers who've been carrying the load start leaving. The business often can't see this coming because the short-term output looks fine.

Ask how predictable releases have been over the last 12 months, and how often deadlines moved. Then ask what percentage of engineering effort goes to maintenance versus new product. The ratio usually tells you more than the answer does.

3. The architecture was built for a different business

This finding requires technical depth to evaluate, but its business implications are straightforward. A monolithic architecture that made sense when the company had 20 customers becomes an EBITDA problem when you're trying to scale to 200. Shared databases, tightly coupled services, and manual scaling processes all create ceilings that the business keeps running into without fully understanding why growth is getting harder.

The questions that surface this: What breaks first if customers double? Which components can't scale independently? Are there technical constraints that sales already works around when closing deals? That last one is important; if sales has learned to avoid certain conversations about platform capabilities, someone in engineering usually knows why.

One of the questions I ask is what actually happens when the customer base grows from twenty to two hundred. Does infrastructure cost scale linearly? Does support require twice as many people? Are new customer implementations largely automated, or does each one require engineering involvement? Problems often surface in places management doesn't initially consider: licensing models, manual operational processes, fragile deployment pipelines, or support organizations that don't scale with the business. 

These findings don't necessarily change whether I'd invest. They change the post-close roadmap. The architecture may be perfectly capable of supporting the current business while still requiring targeted modernization before pursuing the next phase of growth. 

4. Security is policy without practice

Every company has security documentation. The ones with mature security practices can show you what happened the last time a critical vulnerability was identified and how fast it was remediated. They run regular penetration tests and can tell you what the findings were. They have an incident response process they've actually used, not just written down.

The gap between security policy and security practice is where most of the real risk lives. Security incidents create operational disruption, customer churn, and regulatory exposure, and the first sign is often a customer conversation that turns uncomfortable fast.

When I'm evaluating this, I'm not looking for perfection. I'm looking for evidence that security is operationally real rather than a compliance artifact.

One artifact I like to review early is the audit log. Not because I'm searching for malicious activity, but because it reveals how the platform is actually operated. Frequent manual database updates, bypassed business rules, emergency overrides, or privileged administrative actions often tell a very different story than the documented operating procedures. 

5. Engineering metrics don't exist

If technology leadership can't readily tell you deployment frequency, lead time from commit to production, change failure rate, or mean time to recovery, the organization is managing engineering on feel. That's not unusual at a certain stage. It becomes a problem when you're trying to make investment decisions about the platform's capacity to execute.

I don't expect a dashboard that looks like a DORA benchmark. I do expect that leadership has enough operational visibility to have a grounded view of where they're strong, where they're fragile, and what it would cost to close the gap. When that visibility doesn't exist, execution risk goes up, not because the team is bad, but because there's no reliable signal when things start to drift.

Another thing I look for is accountability throughout the software delivery lifecycle. Can a production issue be traced back to the developer who wrote the code, the automated tests that validated it, the reviewer who approved it, and the deployment that introduced it? Too many organizations allow developers to throw code over the wall. Once it's merged, ownership effectively disappears. Mature engineering organizations don't just measure velocity. They measure accountability. 

6. "AI-enabled" doesn't mean anything yet

Almost every software company going through diligence right now describes itself as AI-enabled. That statement, by itself, tells me very little.

The first question I ask is surprisingly simple:

If every employee lost access to ChatGPT, GitHub Copilot, Claude, Cursor, and Gemini tomorrow, what AI capabilities would remain?

If the answer is "not much," then the company's AI strategy is really an employee productivity strategy, not a product strategy or a competitive advantage.

There is nothing wrong with using Copilot or ChatGPT. Every engineering organization should be improving developer productivity with those tools. But investors shouldn't confuse adopting widely available tools with building differentiated intellectual property.

What I'm trying to understand is whether AI has become part of the company's operating model.

For example:

• Is AI embedded in the product in a way customers value and are willing to pay for?
• Has AI materially reduced customer support costs?
• Has it shortened implementation times?
• Does it improve fraud detection, underwriting, recommendations, or other domain-specific outcomes?
• Are there proprietary models, workflows, data assets, or evaluation frameworks that competitors cannot easily replicate?

Then I look at governance.

Who owns AI? How are models evaluated? How is hallucination risk managed? How are prompts, retrieval pipelines, and model changes tested before reaching production?

Companies creating real value through AI can answer those questions with evidence.

Companies that are still experimenting usually describe the tools they are using. Companies that have moved beyond experimentation describe what has changed: faster decisions, redesigned workflows, lower costs, better products, or new capabilities. The difference is not adoption. It is operational impact.

One pattern I've started seeing is organizations claiming AI maturity because developers use GitHub Copilot and employees use ChatGPT. Those are useful productivity tools, but they are available to every competitor. The diligence question isn't whether employees use AI. It's whether the business has created capabilities that competitors cannot easily buy for $20 per month. 

7. Every customer is a special case

Customer-specific code is one of the more insidious issues to uncover because it looks like success from the outside. The company wins deals. Customers are happy. Renewal rates are strong. But under the hood, every implementation is slightly different: unique integrations, deployment variations and customer-specific modules that cannot be maintained efficiently at scale.

The margin erosion is gradual and easy to miss. The product development slowdown is real but gets attributed to other things. When you try to accelerate growth, the constraint isn't sales, it's the operational complexity of supporting a portfolio of highly customized implementations. 

This finding doesn't simply identify risk. It often defines the first major value creation initiative. Standardizing customer implementations reduces operating costs, accelerates onboarding, simplifies support, and increases the organization's ability to scale without adding headcount at the same rate as revenue. 

8. Technical debt has no owner

Every platform carries technical debt. That's not the issue. The issue is when technical debt has no business prioritization, when engineers talk about it constantly, there's no quantified impact attached to it, and the proposed solution is some version of "we need to rewrite the whole thing." That last phrase, in my experience, almost always signals that nobody has done the work of understanding what the debt actually costs and what it would specifically take to address it.

The organizations that manage technical debt well treat it like any other investment decision: here's what it costs us to carry, here's what it would cost to fix, here's the business case for doing it now versus later. The ones that don't manage it well just have a growing list of things engineers are unhappy about.

9. Product and engineering aren't pulling in the same direction

Misalignment between product strategy and engineering execution is one of the more reliable sources of execution risk post-acquisition, and it often gets misdiagnosed as an engineering problem when it's actually an organizational one. Features get built without clear outcome metrics. Product priorities change frequently, creating churn in the engineering roadmap. Sales commitments drive the development queue in ways that engineering can't predictably plan around.

The question isn’t whether they’re in conflict, that is normal. It's whether product and engineering leadership have a shared way of making prioritization decisions when they disagree. If they don't, execution risk scales with the ambition of the value creation plan.

10. Technology leadership manages problems, not outcomes

The most useful thing I can do in a technical leadership conversation is watch what the CTO or VP of Engineering talks about when they're not answering my specific questions. If the conversation naturally drifts to outages, staffing, and release schedules, those are operational topics. They matter. But a technology leader who only lives in that space isn't connecting engineering decisions to enterprise value.

Strong technology organizations tie their decisions directly to business outcomes: customer value, operating leverage, investment priorities. The difference isn't a matter of sophistication, it's a matter of orientation. And it matters a lot when you're planning what you need from leadership to execute through the holding period.

One question I like to ask engineering leaders is how they measure productivity. Many proudly point to story points completed or sprint velocity. When I ask which customer outcomes improved or which business objectives those releases achieved, the conversation often becomes much less certain. Delivery metrics tell me how busy the team is. Business metrics tell me whether they're creating value. 

From Findings to Value Creation

None of these findings automatically changes an investment decision.

What they do change is the post-acquisition roadmap.

They influence where capital should be invested, which leadership capabilities are required, how quickly value creation initiatives can begin, and which risks deserve immediate attention during the first 100 days.

Technology diligence shouldn't produce a list of problems. It should produce a practical roadmap for increasing enterprise value.

After more than two decades leading engineering organizations and technology transformations, I've become convinced that successful technology diligence isn't about finding perfect software, but about determining whether the technology is fit for the business, the investment thesis, and the value creation plan.