Perspectives from the people doing the work

Technology diligence often evaluates systems in isolation. Investors lose money when systems and teams fail at moments that cannot be reversed.

We focus on execution risk at irreversible moments. Ownership change. Integration inflection points. Leadership transitions. Capital raises and recapitalizations. That is where capital is most exposed. That is where Techquity operates.

For many investors, the most dangerous window begins after close, when capital is committed, expectations are high, and execution drift quietly begins. That is where value erodes before it becomes visible in financial results.

Most diligence asks whether the right components exist. We ask whether they will hold under pressure.

Most tech due diligence starts with "Tell us about your architecture. Do you have DevOps? Do you have security policies?" If the answer is yes, the box gets checked and everyone moves on. This approach ensures that the elements of a technology program are present, not that they perform well.

That is why we don't approach technology diligence with a checklist. Instead, we approach it like operators.

Experienced Operators, Not Box-Checkers

In multiple engagements, we have provided second opinions on diligence processes that relied on template-driven validation. In those cases, risks tied to delivery maturity, leadership judgment, and integration fragility were not surfaced in the original party's report because they were outside the template.

The fundamental difference in our approach is that we begin with the investment thesis. Then we ask: "Where does the technology either unblock or unlock that thesis? What would have to be true for this deal to work? What would likely kill it over the next 12 months?"

Anchoring Diligence to the Investment Thesis

By starting with the thesis, we connect the business case to the technology and create context for the artifacts we analyze. We examine architecture, delivery systems, data integrity, and organizational design. We identify gaps such as incomplete diagrams, a lack of metrics, unclear ownership, claims that exceed the evidence presented, or an unrealistic roadmap.

After reviewing the artifacts, we conduct deep-dive sessions with the team. We interview team members, pressure-test assumptions, and lead focused information-gathering sessions in areas that require scrutiny. We independently assess AI and machine learning claims, data quality, governance, and integration complexity.

No Technical Brain Dump

What we deliver to executives, boards, and investors is not a technical brain dump. We translate what we see into CEO- and board-level recommendations in clear language, not technical jargon. We make decisions possible, not just informed.

In every report, we identify near-term priorities for the next six months and outline longer-term initiatives, as well as risks that may not be affecting the business today but will emerge as the company scales. All of these elements tie back to financial outcomes and business-level goals.

Technology Risk Is About Structural Judgment

Technology risk is based on more than clean architecture. A company could have ostensibly flawless architecture that is unfit for what they are trying to achieve, or architecture that is handicapped by other elements of the business and technical structure.

The difference between "can it work" and "will it work" is the difference between theoretical scalability and financial reality.

Many systems can scale. The real question is whether the current team will execute cleanly under 5x growth or collapse into reactive, unstable modes of execution. Understanding this requires depth of experience and judgment across both granular technical details and executive leadership patterns.

Technology Risks Are Investment Risks

Because we begin with the investment thesis, we translate technical risk into investment risk. Rather than saying "the data pipeline is immature," we would say, "The data model continues to evolve without governance, and customer trust will erode under scale." We connect technical facts to business-level impacts.

From Diligence Vendor to Execution Partner

This leads to what we call the Execution Edge — a continuous diligence model. Execution risk does not disappear at close, so our model extends beyond the report. We meet quarterly with the company to evaluate how identified risks are being addressed, assess new risks, and recalibrate priorities as the company scales.

Typical diligence identifies what is broken and stops there. Our operator approach asks where things will break, under what conditions, at what cost, and how the team can prevent it. Real value emerges when judgment is applied continuously, not just at the moment of transaction.

Most technical due diligence uncovers facts. Few engagements deliver judgment.

Buyers rarely lose money because someone failed to identify technical debt. They lose money because no one translated those findings into decisions: Which risks matter? Which can wait? Which ones threaten the investment thesis? Technical due diligence creates value not by producing another report, but by helping investors make better technology decisions before they invest.

This is the technical due diligence checklist we use with private equity firms and investors — not as a form to complete, but as a framework for applying experienced judgment to the technology decisions that determine whether a deal creates or destroys value.

What Technical Due Diligence Actually Covers

“Technical due diligence,” “IT due diligence,” and “technology due diligence” get used almost interchangeably, and for good reason — they describe the same underlying exercise: an independent assessment of a company’s technology, run before a transaction or major investment decision, that answers three questions:

• Does the technology support the value creation plan, or work against it?
• What will it cost — in dollars and in time — to close the gaps that matter?
• Who, on the current team, can actually execute that plan without outside support?

A thorough due diligence tech exercise touches architecture, security, team, spend, and roadmap. Some buyers use the term “digital due diligence” to emphasize the product and customer-experience layer, or “information technology due diligence” to emphasize internal systems and infrastructure — but the scope should be the same either way. A review limited to a codebase audit or a vendor security questionnaire is an input to due diligence, not the answer.

The Judgment Gap in Technical Due Diligence

Generic due diligence companies default to a familiar model: a team of analysts works through a standardized questionnaire, benchmarks the answers against a database of prior deals, and produces a lengthy report with a heat map. It looks rigorous. In our experience, it’s also the fastest way to miss the risk that actually matters.

Three failure modes show up again and again in software due diligence and IT due diligence reports built this way:

• Checklist theater. Every box gets checked, but no one weighs in on which findings are deal-breakers versus footnotes.
• No operating context. A finding like “monolithic architecture” means something very different for a 40-person SaaS company than for a 400-person platform business — a generic report treats them the same.
• No plan attached. The report ends at the finding. It doesn’t say what a remediation plan looks like, what it costs, or who should own it after close.

A due diligence expert who has actually run technology organizations reads the same signals differently — not just “is this a risk,” but “is this a risk I’ve solved before, and what did it take.” That’s the difference between analysis and judgment, and it’s the whole reason technical due diligence exists as its own discipline.

The Technical Due Diligence Checklist

Use this as a working checklist for your next deal — whether you’re running diligence yourself, briefing a technology due diligence consulting partner, or evaluating a due diligence report someone else produced.

Architecture and Scalability

• Does the current architecture support the growth assumptions in the deal model, or will it need to be re-architected within 18–24 months?
• Where is technical debt concentrated — is it isolated to a legacy module, or systemic across the platform?
• How dependent is the platform on a small number of engineers’ undocumented knowledge?

Team and Organization

• Is engineering leadership strong enough to execute the value creation plan without outside support?
• What is the retention risk on key technical staff post-close, and what would it cost to backfill them?
• Are there single points of failure — one person who owns deployment, security, or a critical system?

Security, Compliance, and Data

• What does the actual security posture look like, versus what’s represented in the data room?
• Are there unresolved compliance gaps (SOC 2, HIPAA, GDPR) that create closing risk or post-close liability?
• How is customer data governed, and would it hold up if the roadmap includes new AI features?

Cost and Spend

• What is the real run-rate of cloud and infrastructure spend, and how much of it is inefficiency rather than growth?
• Are vendor and licensing contracts structured in a way that limits or supports the next phase of the business?

Roadmap and Execution Risk

• Is the product roadmap realistic given the current team’s capacity and the architecture’s constraints?
• What would the first 100 days of a technology transformation look like if this deal closes?

Who Should Run Your Diligence

The checklist matters less than who is interpreting it. A technology due diligence consulting engagement staffed by junior analysts can flag risks. It usually can’t tell you whether those risks are survivable, what they’ll cost to fix, or how to sequence the fix against everything else in the value creation plan. That takes someone who has sat on the other side of the table — who has built, scaled, or turned around technology organizations, and knows what a “yellow” finding actually means in practice.

That’s the difference between an IT due diligence report and a diligence deliverable you can act on: straight talk about what matters, not just what was found.

From Diligence to a 100-Day Plan

The best technical due diligence doesn’t end at the findings. It sets up the first 100 days post-close — a plan for closing the gaps that matter most, in the order that protects the most value. If your diligence process can’t produce that plan, it has only done half the job.

Whether you’re evaluating a platform pre–term sheet or preparing a portfolio company for exit, the goal is the same: judgment you can act on, from people who have actually run the technology they’re assessing.

Information Doesn’t Create Better Investments. Judgment Does.

Technical due diligence should do more than identify issues. It should help investors decide what matters, what can wait, and where to invest after the deal closes. The value isn’t in producing another report. It’s in providing experienced judgment that improves investment decisions and protects enterprise value.

Frequently Asked Questions

How long does technical due diligence take?

A pre–term sheet read can often be turned around in days when speed matters — enough to flag deal-breakers before you commit. A full technical due diligence engagement, covering architecture, team, security, and roadmap in depth, typically runs two to four weeks depending on the size and complexity of the platform.

What’s the difference between technical due diligence and a security audit?

A security audit is one input into technical due diligence, not a substitute for it. Security audits test for vulnerabilities and compliance gaps. Technical due diligence is broader — it also evaluates architecture, team strength, spend efficiency, and whether the roadmap is realistic, then translates all of it into what it means for the deal.

Who typically commissions technical due diligence — the buyer or the seller?

Most often the buyer, whether that’s a PE firm evaluating a platform investment or a corporation evaluating an acquisition. Sellers increasingly commission their own due diligence tech review ahead of a sale process, to identify and fix issues before they become negotiating leverage for the buyer.

Can technical due diligence happen before a term sheet is signed?

Yes — and for high-stakes deals, it should. A focused pre–term sheet read can surface deal-breaking issues early, before either side has invested significant time in negotiation. A deeper technical due diligence consulting engagement then follows during the confirmatory diligence period.

"AI will fade away like crypto and Web3. It's just hype."

Gen AI tools hit 800M+ WAU. Peak crypto ownership wasn't even close. AI will be way stickier.

ChatGPT alone has reached massive global adoption in under two years. At crypto's peak, global ownership estimates ranged around 600–700 million holders — impressive, but largely concentrated in investment activity rather than daily utility. The scale and nature of AI adoption make this boom structurally different from the crypto/Web3 cycle.

1. AI usage is habitual; crypto usage was transactional.

Crypto's peak reflected asset speculation more than daily engagement. Many holders owned tokens passively, and wallet counts overrepresented active users. By contrast, AI tools report hundreds of millions of weekly active users who rely on AI for writing, coding, research, design, and workflow automation — embedding it directly into daily professional and personal tasks.

2. AI adoption is horizontal across industries.

Crypto adoption skewed toward trading, DeFi, NFTs, and a relatively narrow technical or speculative audience. Generative AI is used across sectors: education, software engineering, marketing, finance, healthcare, legal services, and enterprise operations. Surveys show nearly half of U.S. knowledge workers have used generative AI tools. That breadth creates an inherent stickiness that crypto never had.

3. Enterprise integration drives durability.

During the crypto boom, enterprise exposure was limited and experimental. AI is being embedded into Microsoft, Google, Salesforce, Adobe, and other core enterprise platforms used by billions. Once AI becomes part of workplace infrastructure, the cost of abandoning it increases dramatically.

4. Utility-based engagement vs. asset-price dependency.

Crypto participation was highly correlated with token prices; user activity fell sharply during bear markets. AI usage, by contrast, is driven by productivity gains. Its value proposition is independent of speculative cycles.

5. Growth velocity signals deeper product-market fit.

ChatGPT reached 100 million users in roughly two months — one of the fastest adoption curves in consumer software history. Crypto took years to reach comparable ownership levels and relied heavily on bull-market momentum.

Conclusion

Both crypto and AI generated massive hype cycles, but the composition of their user bases differs fundamentally. Crypto amassed large numbers of speculative investors, while AI has amassed hundreds of millions of active users. Broad, habitual, utility-driven adoption makes AI meaningfully and structurally more embedded than crypto ever was.

If the key question is durability, the scale and depth of AI's user engagement suggest a very different trajectory.

Tech has the potential to be THE great global leveler. American and Chinese tech currently dominate the world. Big tech gets bigger. Anyone trying to escape this is fighting the gravitational pull of cosmically large entities.

The gravitational pull works like this: America, China, and some other countries (to a lesser extent) produce the largest and most powerful tech companies along with the largest and most productive start-up ecosystems and risk capital. Those companies attract motivated and talented people from across the globe. The flywheel of capital and talent spins faster, and capital and experience become hyper-concentrated.

Growing Wealth Outside the Orbit

One of the ways that smaller nations, companies, and tech ecosystems can be supported in this dynamic is through investment. Economic differences are obvious, measurable, and important, and capital investment is essential to the emerging market.

But the less obvious and more complex imbalance between established markets and emerging ones is expertise. Because the United States and China have more massive businesses and start-up ecosystems than the rest of the world, they naturally have more leaders and operators who are experienced in building and running businesses at this scale. This experience is highly valuable and extremely rare.

It is common to see experienced tech leaders and operators jump between Google, Microsoft, Meta, Amazon, Netflix, Apple, X, Tesla, OpenAI, Oracle, and a handful of other elite names in American tech. However, it is more uncommon for them to work for companies in smaller markets. These companies often do not have the culture, priority, budget, impact, or cutting-edge technology that can attract leaders and operators of the highest caliber. The result is that the experience needed to build the world's best companies remains concentrated in a few select markets.

Spreading Expertise

Part of Techquity's thesis is that the experience we have accumulated from decades in the top tech companies of the world can be invested as a growth lever for scaling companies, no matter where they are from. Just as some investment firms inject capital into emerging markets, Techquity seeks to inject big tech leadership and expertise into the markets and companies where it is needed most.

Because we know that our experience is unique, useful, and highly concentrated in only one or two places in the world.

If you work with companies that could use some of this experience, let's be in touch.

Three words on the minds of AI builders over the last twelve months are Model Context Protocol, abbreviated as MCP. Heralded as the "HTTP of AI", MCP is a public and open set of protocols that can be used to dictate how an AI model interacts with other digital actors — websites, applications, databases, and other AI models.

Protocols are a big deal. HTTP — Hypertext Transfer Protocol — is the core protocol that allows browsers to talk to web servers. The development and deployment of HTTP enabled the web as we know it. Until MCP, there was no core common protocol for AI interchange. Without this, interoperability at scale can't happen.

MCP represents a key inflection point for the ecosystem. Major inflection points are among the most critical periods for determining how much tech debt your organization will carry going forward.

As we rapidly move towards infusing artificial intelligence into every application, progressive boards and CEOs recognize we are now squarely in the middle of one of the most significant inflection points in technology history. The technology choices you make during inflection points can determine the future of your technology capabilities — and possibly the success of your product and company.

Lessons from Previous Inflections: Web and Mobile

During the early days of the internet, building a website was expensive. There were far fewer reusable components. Developers had to build now-common capabilities like payments and log-ins from scratch. Today there are many tools that make building a compelling and sophisticated website possible for non-tech people. Something similar is now happening with AI.

After the internet came smartphones. Many organizations had to dramatically alter their websites, streamline code, and design for a mobile form factor. Then, native mobile applications gathered momentum. Organizations effectively had to build three different applications. For most enterprises, this was unsustainable — costly, cumbersome, and a security nightmare. How well teams solved the three-headed monster problem often had a significant impact on their future.

AI's Emerging Tech Debt Challenge

With AI, businesses face a similar risk. There is a huge variety of AI tool chains and AI components. We are still too early in AI to have real confidence in what tools, practices, and protocols will likely prevail. This is precisely why risks of technology debt accumulation are always greatest around inflection points.

Build too much, too fast, and in the wrong way, and you will be paying for it for a very long time.

Hidden Tech Debt: Data Governance and Compliance

AI's hunger for data is insatiable, and with it comes a hidden tech debt few leaders spot early enough. Neglecting data governance isn't just a compliance risk — it's a fast track to buried liabilities that will haunt your infrastructure, your brand, and your bottom line.

Building AI responsibly means baking privacy, rights, and auditability into every layer from data ingestion to model training and inference. With regulations like GDPR, CCPA, and HIPAA tightening their grip, companies must bake compliance and bias controls into their AI workflows — not bolt them on after the fact.

The People Side of the AI Inflection: Talent and Readiness

Technology inflections test the readiness and adaptability of the people and teams that build and operate systems. CIOs and CTOs should prioritize upskilling engineering, product, and data teams in emerging AI frameworks and model lifecycle management.

Recommendations for CIOs and CTOs

• Decide what to build: Determine whether to build an AI-first or AI-enhanced product before committing to an AI strategy.
• Stand up one clear "front door" for AI: Think of an MCP gateway like the main reception desk — every AI system must check in here.
• Hide AI model brands behind your own switchboard: Connect business software to an internal API you control so you can swap models without costly rewrites.
• Turn rules and guardrails into editable playbooks: Store "who can see what" and "what an AI is allowed to do" in version-controlled files.
• Keep all your AI facts in one, well-lit warehouse: Let teams experiment, but insist that data and search indexes live in a single, governed repository.
• Measure AI health in plain business terms: Dashboards should show both tech metrics (speed, cost) and AI-specific ones (accuracy, trustworthiness).
• Track lifetime operating costs, not just launch budgets: GPU bills and per-token fees can snowball; tie every AI initiative to a simple unit metric.
• Choose options that let you move later: Favor open-source models and containerized deployments so you're not locked into one cloud provider.

Inflection points are times of opportunity and peril. For smart CEOs, CTOs, and CIOs, this inflection will allow them to build distance from competitors, overhaul business practices, and radically reduce operational overhead.

Will you make this inflection point work for you, or against you?

Executive Summary

Effective decision-making is a cornerstone of organizational success. Yet not all decisions carry the same weight or consequence. Amazon’s Jeff Bezos introduced a powerful mental model for categorizing decisions: the One-Way Door / Two-Way Door framework. This white paper explains that framework, illustrates it with real-world examples across industries, and provides actionable guidance for executives, operators, and investors to apply it in their own contexts.

The Core Insight

One-way door decisions are irreversible or very costly to undo. Two-way door decisions are reversible — you can try, learn, and course-correct. The critical error organizations make is treating one-way doors like two-way doors (moving too fast) or treating two-way doors like one-way doors (moving too slowly).

Why the Distinction Matters

The failure mode Bezos identified is not just moving too fast on big decisions — it is also the opposite: organizations that treat every decision as a one-way door create layers of approval, slow their pace of innovation, and ultimately lose competitive ground. The framework creates a two-tier decision system: high governance for irreversible choices, delegated speed for reversible ones.

“If you walk through and don’t like what you see, you can’t return to before. We can call these Type 1 decisions. But most decisions aren’t like that — they are changeable, reversible — they’re two-way doors.” — Jeff Bezos, 2015 Amazon Shareholder Letter

Recognizing a One-Way Door

A decision is likely a one-way door if it exhibits one or more of the following characteristics:

• High switching cost — financial, operational, or reputational
• Irreversible customer or stakeholder expectations once set
• Deep structural impact on organization, technology, or brand
• Long-term lock-in through contracts, regulation, or infrastructure
• External dependency created — partners, developers, or customers rely on the decision

2. Real-World One-Way Door Decisions

1. Amazon Acquires Whole Foods (2017)
$13.7 billion capital commitment with deep brand integration. Physical retail footprint permanently acquired. Selling or reversing would cause massive reputational and financial damage.
Impact: Permanently moved Amazon into physical grocery at scale, reshaping its consumer identity.

2. Amazon Launches AWS
Required massive long-term infrastructure investment. Fundamentally shifted Amazon’s business model. Customers build businesses on top of AWS — backing out is not realistic.
Impact: Transformed Amazon into a global technology infrastructure giant; enterprise customers depend on it.

3. Netflix Transitions from DVDs to Streaming
Abandoned a profitable, established business model. Massive infrastructure investment required. Customer expectations permanently reset around on-demand streaming.
Impact: Netflix became a streaming-first company with no realistic path back to physical media.

4. Apple Removes the Headphone Jack (iPhone 7)
Forced an ecosystem-wide shift to Lightning and wireless audio. Accessory manufacturers and users had to permanently adapt. Reversing would signal deep strategic inconsistency.
Impact: Accelerated wireless audio adoption globally and permanently redefined iPhone hardware expectations.

5. Facebook Acquires Instagram
Deep integration of users, data, and engineering systems. Cultural and product identities merged over years. Unwinding the acquisition would be enormously disruptive.
Impact: Instagram became central to Meta’s growth and advertising strategy — inseparable from the parent company.

6. Google Reorganizes into Alphabet
Structural and governance overhaul across all entities. Investor expectations and reporting permanently reset. Brand identity and corporate structure fundamentally changed.
Impact: Created a holding-company model with subsidiary independence — practically impossible to unwind.

7. Boeing 737 MAX Engineering Decisions
Early architectural choices (including the MCAS system) locked in the certification path. Changes later became extraordinarily costly and time-consuming. Regulatory and reputational consequences compounded over time.
Impact: Demonstrated that early irreversible engineering decisions can have catastrophic downstream consequences.

3. One-Way Doors in Technology Strategy

For technology companies, one-way doors tend to arise from decisions that create deep coupling — between systems, teams, customers, or external ecosystems.

1. Cloud Provider Selection — Deep integration into provider-specific IAM, databases, and serverless services. Migration to another provider is expensive, risky, and disruptive. Locks you into: Tooling ecosystem, pricing model, and long-term vendor relationship.

2. Data Architecture Strategy — Data pipelines, schemas, and analytics tooling built around chosen model. Replatforming is slow, expensive, and carries data integrity risk. Locks you into: How the company generates insights and makes data-driven decisions.

3. Monolith vs Microservices Architecture — Team and organizational structure mirrors the system architecture. Switching requires extensive rework across engineering and product. Locks you into: How teams collaborate, ship software, and scale.

4. Public API Design — External developers build businesses on top of your interface. Breaking changes damage trust and create partner attrition. Locks you into: Long-term backward compatibility obligations and ecosystem governance.

5. Launching a Platform Ecosystem — Third parties build businesses and revenue streams on your platform. Policy changes become politically sensitive with ecosystem participants. Locks you into: Long-term ecosystem stewardship and rules-of-the-road commitments.

6. Adopting AI/ML as a Core Product Layer — Requires dedicated data pipelines, infrastructure, and specialized talent. Removing or downgrading AI later degrades the product experience. Locks you into: Ongoing model costs, retraining cycles, and engineering complexity.

7. Pricing Model Embedded in Product — Billing systems deeply integrated into product and engineering stack. Revenue predictability and growth strategy tied to model chosen. Locks you into: Business model economics and long-term revenue structure.

The Tech One-Way Door Heuristic: In technology, a decision is a one-way door when it creates deep coupling, external dependency, scale inertia, or organizational lock-in. Ask: “If we wanted to undo this in two years, would we need to rebuild everything or break trust?” If yes — it is a one-way door.

4. One-Way Doors in Private Equity

1. ERP / Core Systems Selection — Company-wide integration across finance, operations, and HR. Migration takes years and tens of millions of dollars. Impact: Directly affects scalability narrative and exit readiness for strategic buyers.

2. Buy-and-Build Integration Architecture — Data models and systems become locked in early during acquisitions. Synergy assumptions built into the investment thesis depend on this choice. Impact: Determines whether a roll-up strategy achieves its intended financial benefits.

3. Cloud Migration Strategy — Infrastructure, cost structure, and talent requirements shift fundamentally. EBITDA margin profile changes based on infrastructure model. Impact: Drives the scalability and margin expansion narrative central to exit valuation.

4. Product Modernization vs Legacy Retention — Rebuilding core product requires multi-year investment and execution risk. Buyer diligence increasingly scrutinizes technology debt as a value discount. Impact: Directly determines growth multiple versus value trap outcome.

5. Revenue Quality Architecture (Pricing Model) — Billing systems and customer contracts deeply embedded in operations. Revenue predictability and ARR quality shape exit multiple significantly. Impact: Shapes revenue quality metrics that buyers use to determine enterprise value.

The PE One-Way Door Heuristic: A tech decision is a one-way door if it affects the exit narrative, locks in cost structure, shapes scalability, or creates or limits optionality. Key question: “Will this decision increase or limit our exit options in 3–5 years — and can we realistically undo it before exit?”

5. Practical Decision Checklist

Use this checklist to assess whether a decision is a one-way door. If three or more criteria apply, treat the decision with significantly more deliberation, senior involvement, and analytical rigor before committing.

Scoring: 0–2 signals → likely a two-way door (delegate and move fast). 3–5 signals → borderline; apply more deliberation. 6+ signals → definitively a one-way door (require senior sign-off, extended analysis, and contingency planning).

6. Key Takeaways

01 — Not all decisions deserve equal deliberation. Treating reversible decisions like irreversible ones creates bureaucratic drag. Treating irreversible decisions like reversible ones creates catastrophic risk. Correctly categorizing the decision is the most important first step.

02 — One-way doors are defined by their consequences, not their size. A small technical decision (e.g., choosing a database) can be a one-way door. A large investment (e.g., entering a new market) can be a two-way door if it is structured with exit optionality.

03 — Speed is a strategic advantage on two-way doors. Organizations that apply one-way-door governance to two-way-door decisions are slower, less experimental, and less innovative than peers who delegate and empower teams to move fast.

04 — The cost of getting a one-way door wrong is asymmetric. Unlike two-way door mistakes — which are recoverable — one-way door errors compound over time. They limit options, destroy trust, consume capital, and often cannot be fully repaired.

05 — For technology leaders, the highest-risk one-way doors are architecture, platform, and ecosystem decisions. These shape how companies build, scale, and operate for years — and create dependencies that are expensive and painful to unwind.

06 — For private equity investors, technology one-way doors affect exit optionality directly. Decisions made in the first 12–18 months of a hold period — around ERP, cloud, pricing model, and integration architecture — often determine whether an exit story is compelling or constrained.

07 — The framework scales from startups to governments. Whether choosing a startup business model, a corporate M&A target, or a national policy, the same questions apply: Is this reversible? What does it lock us into? What are the downstream consequences of being wrong?

7. Conclusions

The One-Way Door framework is one of the most practically useful mental models available to business leaders, technology executives, and investors. At its core, it is not a complex theory — it is a simple question asked consistently: “If we are wrong, can we recover?”

Organizations that internalize this framework tend to exhibit two complementary traits. First, they move faster on the majority of decisions — because most decisions are two-way doors, and over-governing them is a competitive liability. Second, they move more carefully on the minority that are one-way doors — bringing more data, more senior judgment, and more contingency thinking to the decisions where mistakes compound rather than self-correct.

Most decisions are two-way doors. Move fast, empower teams, and iterate. For the decisions that are genuinely irreversible — slow down, think harder, and get them right the first time.

Wielding AI is like acquiring superpowers. First attempts to use those superpowers are awkward and painful. Think of Spider-Man webslinging into a wall. Tony Stark flying into the ceiling. Heroes don’t master newfound abilities without a few bumps.

Like heroes with new powers, consulting houses are working through the ways to wield AI effectively, and it’s not always pretty. With AI stakes so high, enterprises leveraging consultancies have been frustrated and underwhelmed, with a sense that they are paying for their consultant’s education. The Wall Street Journal made that point in an article titled: How the AI Boom is Leaving Consultants Behind.

We’ve Been Here Before

This scenario isn’t new. In the mid-90s, massively disruptive web technology emerged and evolved at breakneck pace. The traditional consultancies struggled initially, taking time to get their footing.

That gap created opportunities for new consulting startups exclusively focused on web platforms. The most prominent of those were known as the Fast Five and included Viant, Scient, and Razorfish. (Full disclosure, I spent 5 years at Viant.) The Fast Five helped enterprises harness the web’s potential through fixed-cost and fixed-time projects that quickly created value.

AI’s Rapid Evolution Creates New Opportunities

Today’s AI landscape is evolving at comparable speed to the mid-90’s boom. Concepts around agentic architectures like MCPs, context management, agent-to-agent communication, and agent payments are advancing at a blistering pace. This rapid evolution demands partners with “hands in the dirt” — those who have gone beyond merely absorbing AI news, and are immersed in the technology with experience-based understanding of AI applications, agents, and context engineering.

Like the mid-90’s, specialized consultancies are emerging. The Information just highlighted the momentum of Distyl AI, an AI-specific consultancy founded by former Palantir executives that raised $175 million at a $1.8 billion valuation. OpenAI is getting into the consulting game. Other new AI consultancies are following suit.

Defining “Hands in the Dirt” (HITD)

So, how does one assess whether a partner truly has their “hands in the dirt” and is capable of deploying cutting-edge AI solutions?

A key tell is around their familiarity with Agent Experience or “AX.” For the last 50 years, system design has been dominated by a focus on user experience, or “UX.” With AI, we are transitioning to a focus on how AI and agents interface with systems, tools and data. We are transitioning from UX to AX.

Experienced partners are on the front lines, wrestling with AX considerations. They are partners who are:

1. Navigating the limitations of MCPs and understanding that MCPs are not as simple as “just wrap an API”
2. Recognizing the shortcomings (and absence) of technical documentation, a critical input to agents
3. Rethinking the granularity of tools that agents need exposed
4. Addressing the realities of context engineering like context rot, noise vs signal, context scaling, context leakage and governance
5. Wrestling with agentic architecture and agent hierarchies
6. Working through the infosec considerations that agentic architectures introduce
7. Structuring evals to measure agent reliability and robustness
8. Optimizing the cost and latency associated with LLM usage and agentic solutions

The partners who recognize these things are the ones who truly understand how your business will change in the coming years and are best suited to drive strategic AI technology projects at your company.

What of the Traditional Consultancies?

Of course, traditional consultancies will adapt and internalize the state-of-the-art. Mastery of agentic architecture and AX will become table stakes for them, though it is not yet so today.

Nonetheless, during this time of extreme change, there is an abundance of work, and the traditional consultancies can lean on their strengths around transformation planning, strategic financial analysis, cost harvesting, organizational simplification, and change management, to name a few.

The traditional consultancies can accelerate honing of their expertise in these rapidly evolving technology areas by partnering with vertically-oriented AI platforms that have depth and focus in applying agentic AI. These platforms will soon seek integration partners to scale, much like SAP and Oracle do today.

Recommendations for Enterprise Leaders

If you’re a Fortune 500 executive needing AI expertise (particularly if you’re frustrated paying traditional consultants to “crash into walls”), you have at least two options:

1. Engage emerging AI-focused consulting firms with AI-native expertise
2. Ask traditional consultancies to work with AI-native platform partners

Both can work, but in cases where you’ve identified a vertically-focused AI platform, there’s a transformation sweet spot: leveraging HITD platform specialists on technology while partnering with traditional consulting to support strategic planning, financial mapping, and organizational evolution. Together, they can help enterprises unlock AI’s potential without paying for someone else’s superhero training.

For most enterprise organizations, artificial intelligence has become a familiar topic in the boardroom. Leaders have read the reports, attended the conferences, and nodded along to the forecasts. Many have even launched pilot programs. But according to Techquity, a technology advisory firm working with enterprise and growth-stage companies across industries, familiarity is not the same as readiness — and the gap between the two may be more dangerous than most executives realize.

“We are in a genuinely different moment,” says Techquity Partner Chuck Moore. “Not different in the way that every new technology wave is called transformative. Different in the sense that the speed and depth of this shift requires a fundamentally different response than the typical approach to technology adoption most organizations are wired for.”

Techquity is making a pointed, public case: organizations that treat AI as one initiative among many — something to study, pilot, and gradually absorb — are misreading the moment. The firm is calling on enterprise leaders to move with far more urgency and conviction, while acknowledging that the path there looks different for every organization.

A Different Kind of Wave

Techquity is careful not to be alarmist. But they are direct.

The firm draws a clear distinction between this AI moment and prior technology shifts — the migration to cloud computing, the rise of the internet, the proliferation of desktop software. Each of those transformations reshaped how organizations operated. This one, they argue, is reshaping the nature of the work itself.

“Every major technology wave has moved constraints,” says Techquity Partner Andrew Tahvildary. “The critical question is always where those constraints move, and whether leadership has noticed.”

What makes AI different, in Techquity’s view, is the breadth and pace of that shift. Prior transformations offered a recognizable learning curve. Engineers who migrated workloads to the cloud were still doing something that felt, as Partner Brian Lakamp puts it, “reachably familiar.” Agentic AI — software that can reason, plan, and execute across complex tasks — does not feel familiar to most technology teams. It requires a genuine rethinking of how work gets done, not just an upgrade to existing tools.

“This is the first time that people who have coded one way for 30 years face a true change management moment,” Lakamp says. “That’s something most technology teams have never experienced before.”

What Techquity Is Seeing on the Ground

Across client engagements, the firm describes a consistent pattern: organizations that intellectually understand AI’s importance but are organizationally stuck. Enthusiasm at the leadership level. Hesitation on the ground. Blockers around security, tooling decisions, unclear ownership, and the simple inertia of existing backlogs and processes.

The result is a kind of productive-looking paralysis — teams that are talking about AI, debating AI, perhaps even buying AI tools, but not materially changing how they work.

“We see teams that whipsaw between saying ‘this is going to be amazing’ and then not actually doing anything,” says Partner Peter Zatloukal. “There’s a lot of uncertainty about how to get started, and a tendency to wait for the infrastructure decisions and the policy questions to be resolved before anyone actually picks it up and uses it.”

Techquity’s position is that waiting for perfect conditions is itself a strategic mistake. The firms that will be best positioned in two or three years are the ones building hands-on capability now — not the ones that have the most refined AI governance documentation.

The Recommended Approach: Earn the Conviction First

Rather than mapping clients onto a multi-year adoption roadmap, Techquity advocates for getting organizations to real, hands-on experience quickly. The firm has developed an approach — part workshop, part hackathon — designed to give technology teams direct, low-stakes exposure to agentic tools in an environment deliberately isolated from their production infrastructure, security debates, and existing project pressures.

The goal is not to produce a deliverable. It’s to produce conviction.

“Don’t worry about your tooling decisions,” Zatloukal explains. “Don’t worry about your specific backlog. Take some isolated problems, work through them, and actually see what’s possible. That shared experience is what unlocks the broader conversation about how you start doing this at scale.”

Techquity sees this kind of rapid capability-building as the necessary precursor to the harder organizational work — the process changes, the hiring decisions, the governance frameworks. Without it, those conversations tend to stall in abstraction.

The firm is also deliberate about the level at which this work happens. The goal is not to position itself as a permanent engineering resource for its clients. It is to accelerate the moment at which a client’s own team can carry this forward.

The Harder Question: Where Does AI Actually Create Value?

Techquity is equally clear about the limits of a one-size-fits-all approach. Not every organization should be building software. Not every AI initiative belongs in engineering.

“A lot of companies could genuinely use guidance on where in their business it makes sense to apply AI at all,” says Partner David Howell. “There are organizations spending real energy applying AI to problems that don’t warrant it, while sitting on proprietary data and operational knowledge that could be genuinely valuable — if they asked the right question first.”

Howell’s point reflects a broader caution within the firm: maximalism about AI as a force does not mean maximalism about every AI application. The right starting point, Techquity argues, is often a clear-eyed assessment of where an organization has unique data, unique processes, or unique expertise that AI could meaningfully compound — rather than a reflexive push to automate whatever is most visible.

This nuance matters especially for the kinds of companies Techquity works with: infrastructure firms, energy companies, industrial enterprises, professional services organizations. These are not software companies by identity or by culture. Their path to AI leverage looks different from a product-led technology firm, and the firm acknowledges it is still developing its thinking on how to best serve clients in domains where its own hands-on depth is newer.

“We have real depth in product building and technology development,” Moore says. “We know what the maximalist approach looks like there, and we know the risks. We have to be honest about where we’re still building that same depth in other fields.”

The Risk of Waiting

Techquity’s broader message to enterprise leaders is not that their companies face immediate existential threat. Most of their clients will not experience the disruption of their core business as a sudden crisis. It will feel, for a while, like a gradual drift — a slow erosion of competitive position, a growing gap between what their organizations can do and what newer, more capable competitors can do.

That, the firm argues, is precisely what makes it dangerous.

“Companies won’t feel the urgency from the inside,” says Techquity Founder Anthony Bay. “There’s no alarm that goes off. You just keep doing what you’ve been doing, and the distance grows.”

The Microsoft parallel surfaces often in the firm’s thinking: a dominant company that nearly missed the internet entirely, not out of ignorance, but out of organizational momentum. The lesson, in Techquity’s reading, is not that every company will fail to adapt. It is that the ones that do adapt tend to do so because someone in a position of influence decided to treat the shift as a strategic priority — not a background initiative.

Zatloukal puts it plainly: “The companies that don’t make bold bets on this are at competitive risk. That’s not a provocative claim. That’s just the direction this is going.”

A Friendly Push, Not a Mandate

For all the urgency in their internal thinking, Techquity is deliberate about how it shows up with clients. The firm is not interested in selling fear. It is not pitching wholesale transformation as a prerequisite for engagement. And it has no interest in positioning itself as a permanent replacement for a client’s own capability.

The posture, Bay says, is more like a trusted advisor who happens to have strong views — and is willing to say them out loud.

“We’re going to tell you where we think you are,” Bay says. “We’re going to tell you what we think the gap is. And then we’re going to help you close it in a way that’s real and durable — not a report that sits on a shelf.”

That combination — honest assessment, practical urgency, and genuine respect for where a client is starting from — is how Techquity believes the best version of this work gets done.

The window, they believe, is still open. But it is not indefinitely so.