Insights on technology, AI, investment, and leadership from executives who have built, scaled, and transformed companies.
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.
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?"
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.
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 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.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
A few months ago, a CTO told me something that would have sounded absurd five years ago: “I’m no longer sure how many production systems we’re actually running.” He wasn’t describing a chaotic startup. He was describing a well-funded, competently led technology organization that had moved fast on internal tooling, automation, and AI-assisted development. They had built a lot. They had just lost track of everything they had built.
That conversation stayed with me. Because it isn’t an isolated case. It’s a preview.
For about twenty years, the central constraint in software was straightforward: could you find enough engineers to build what the business needed? Headcount was the lever. More developers meant more output. That equation shaped how companies hired, how teams were structured, and how engineering was valued.
AI is changing that equation, but most of the commentary gets the implication wrong.
The dominant narrative is something like: AI writes code, therefore fewer developers are needed. That argument feels intuitive, but it also misreads what happens when a production input gets dramatically cheaper: volume explodes.
The pattern has played out before, in adjacent domains, and the outcome of easier production has never been less of it. It has always been more.
Excel didn’t create fewer spreadsheets. It created an explosion of them. Analysis that was previously impractical became routine. WordPress didn’t reduce the number of websites. It opened web publishing to organizations and individuals who were previously locked out by cost and complexity. Smartphones didn’t shrink video production. They created entirely new industries of content that hadn’t existed before.
Each time, the underlying dynamic was the same: when something becomes cheaper and easier to produce, demand doesn’t hold steady at its prior level. It expands, often into territory that wasn’t even considered before, because the cost had made it unthinkable.
This is the part most people miss. Technology rarely removes a constraint. It moves it. The only question that matters is where it went, and whether leadership noticed.
Software scarcity forced prioritization. Software abundance may destroy it.
The historical bottleneck wasn’t that companies lacked ideas for internal tools, workflow automations, integrations, or niche products. It was that building those things cost real engineering time, time that was finite and competed against core product priorities. Dozens of valuable ideas never got built. Leaders made peace with the manual workaround, the shared spreadsheet, the clunky process that everyone tolerated because the alternative required six months of engineering capacity.
AI now collapses that threshold. Problems previously tolerated because building a solution was prohibitively expensive are now in scope. Companies will build more software because building it is suddenly cheap.
But the bottleneck doesn’t disappear. It moves from “can we build it” to something harder.
The bottleneck is now defined by questions like: Can we operate it? Can we trust it? Can we evolve it without the system collapsing under its own complexity? Should we build it at all, given everything else already running underneath it?
And there is a sharper edge to this. Software you have lost track of is not just hard to maintain. It is an attack surface no one is monitoring. Every untracked service, every forgotten integration, every automation with credentials that outlived the person who wrote them is a door left open in a building whose floor plan no longer exists. The breach rarely comes through the system you are watching. It comes through the one you forgot you built.
The work most exposed to AI was already drifting toward industrialized implementation: isolated tickets, repetitive scaffolding, boilerplate assembly detached from system-level understanding. That is precisely the layer large language models compress most effectively. It was always closer to manufacturing than to engineering. The decisions had already been made somewhere upstream. The work was execution against a known pattern: build this endpoint, wire this form, replicate this component. Little of it required judgment about whether the thing should exist or how it would behave once the system around it changed.
That is exactly the layer a model reproduces well, because there was never much judgment encoded in it to begin with.
The engineers who gain leverage are the ones who can turn AI-generated components into systems that remain understandable, governable, and survivable under real operating conditions. People who can see how a quick fix in one place becomes fragility somewhere else, who understand the business trade-offs underneath a technical decision, and who own outcomes instead of tickets.
AI lowers implementation friction while raising governance costs. That gap is where the real exposure lives, and most organizations haven’t priced it in yet.
There’s a second layer that almost no one is talking about clearly.
As software creation gets cheaper, the coordination cost of managing all that software becomes the new tax.
This is already visible in organizations that moved fast on internal tooling. Dozens of internal tools with overlapping functionality and unclear ownership. Automations built by different teams that conflict with each other in production. AI-generated services that no one fully understands, maintained by people who weren’t there when the system was built. Shadow IT expanding faster than any governance structure can absorb. APIs with no documented lifecycle. Features behind flags that were supposed to be temporary and are now three years old.
The problem isn’t that the software is bad. The problem is that it proliferates faster than the organization can develop a clear view of what to keep, what to retire, what to integrate, and what to leave alone.
Cheap software increases the cost of organizational coherence. This is exactly the problem the CTO I spoke to was describing.
So the ability to look at a system and recognize when local optimization is quietly creating systemic fragility — to say this is the wrong shape before the cost of that shape becomes visible in production — becomes more valuable precisely because there is more surface area requiring that kind of scrutiny. Not less valuable. More.
Companies that treat AI as a way to run the same engineering model more cheaply will likely get a short-term gain and a medium-term governance problem. More software accumulated faster, with the same leadership structures that were never designed to manage that kind of proliferation.
Companies that rethink the engineering function toward outcome ownership, systems thinking, and deliberate architecture governance will get the compounding benefit of more software built faster, with enough coherence to actually operate at scale.
For two decades, companies scaled software by adding engineers. They may now discover that software scales faster than the organization’s ability to govern the consequences of building it.
AI did not remove the bottleneck. It shifted its position.
Many organizations are still trying to solve the labor problem. The harder problem is the one the CTO described without naming it: software now accumulates faster than anyone’s ability to track what it does, who owns it, or what breaks when it changes. It no longer scales at the speed of engineering teams. It scales at the speed of how fast an organization loses track of itself.
