That is the pattern worth studying, because AI is the next loss class to run through it. Insurers do not absorb a risk they cannot price. They bolted an “absolute pollution exclusion” onto general liability policies once asbestos and environmental claims outgrew their models. They killed “silent cyber” by forcing every policy to state explicitly whether a breach was covered. The mechanism is always the same: first the carve-out, then a buy-back priced on whatever the insured can prove about its controls.

So the question for AI is not whether the exclusion arrives. It is what the buy-back costs you, and that price tracks evidence, not your statement of responsible use. A claims adjuster, a regulator, and a plaintiff’s lawyer want the identical thing: the record of what you knew, what you tested, and what you changed. Intent does not appear in that record. Artifacts do.

The record has to survive a hostile reader

This is where “keep good records” stops being advice and starts being engineering, because the record has to convince someone who assumes you would alter it. A folder of PDFs does not. What underwriters and discovery are both moving toward is tamper-evidence, and it has three concrete parts:

• An append-only log where each entry carries the hash of the entry before it, so editing or deleting a past decision breaks the chain and the break is visible.
• The head of that chain anchored on a schedule to an external timestamp authority (RFC 3161) or a third-party witness, so “this existed by this date” is provable without your say-so.
• The store itself on WORM media under object-lock retention, where the storage layer, not a policy, refuses deletion until the retention clock runs out.

Get those right and backdating is not tempting because it is not concealable. Get them wrong and your timestamps are worth exactly your good word, which in a deposition is worth nothing.

The content is a byproduct, the integrity is the work

What flows into that log already exists if you run the program. Eval runs, change-control approvals, the incident reviews that forced architecture changes : you produce these whether or not you capture them. The discipline is writing each one at the moment of the decision into a store you cannot later rewrite. That is the practical reason governance has to be a residue of the work and not a quarterly performance. A residue is contemporaneous, and contemporaneous is the only property that makes a record hard to dismiss.

The failure mode is rarely malice. It is a model that causes a loss, an inquiry that opens, and a team that meant to stand up the logging last quarter. The most expensive sentence in any post-incident room is “we always meant to.” You cannot retrofit an eval history. You cannot anchor a timestamp to a date that has already passed. The artifact existed when the decision was made, or it did not, and the gap reads as negligence rather than innocence.

Treat the audit trail as load-bearing infrastructure now, while it costs only discipline. After the claim it costs twice: the premium you can no longer buy, and the maturity you cannot prove when the buy-back gets priced.

So make those three answerable in calm, before the next bad week instead of during it. Who is a named owner per production system with an explicit halt path, not a committee that assembles after the damage. How fast is the elapsed time from the first bad signal to the system actually pulled, and that only shrinks if the halt is rehearsed rather than improvised. At what cost is the incident threshold agreed in advance: which incidents reach the room, and what the firm is willing to forgo to pull the cord. Wire that into the cadence you already run, a short standing report and an owner who shows up, and you have governance without bureaucracy . It is the lever a board can actually pull.

The full apparatus has four parts: a named owner per production system, an explicit halt path, a rule for which incidents reach the room, and a failure rate measured the same way every quarter. The first three are easy to recite. The failure rate is genuinely hard, and it is exactly where boards get fooled.

The fooling arrives on a slide: the AI system’s error rate fell from 2.1% to 1.7%. Heads nod, the program looks healthy, the meeting moves on. Both figures are closer to fiction than measurement, and a board that cannot say why has not overseen anything. It has been shown a chart.

Why “the same way every quarter” is the hard part

A non-deterministic system has no error rate to read off a gauge. The same input yields different outputs. The model version changes under you, the traffic mix shifts, and the humans grading “wrong” quietly revise what wrong means. So 1.7% is the product of a dozen choices: which outputs were sampled, how many, against what rubric, judged by whom. A defensible number pins all of them down.

• A frozen definition of failure, written as a rubric a grader applies, with inter-rater agreement tracked so the bar does not drift loose over time.
• A fixed sampling rule: N items drawn fresh from live traffic each quarter, never a static test set. The moment engineers know which prompts are scored, they teach to the test and the rate detaches from reality.
• A confidence interval next to the point estimate. On a few hundred samples, 2.1% to 1.7% sits inside the noise band, and presenting it as progress is the lie the slide tells.
• A re-baseline rule: when the rubric or the sample changes, run old and new on one overlap quarter and report both, so the trend is not an artifact of moving the goalposts.

One trap catches the diligent. A frozen golden set goes stale; as the world drifts it stops resembling live traffic and starts flattering you. The defense is to watch the gap between your scored sample and a fresh live sample, and treat divergence as a signal the metric is lying before the system is. A board does not run this machinery; that is the IC’s standard to meet. The board asks the questions that prove someone did, and refuses a number that cannot answer them.

Which is why the usual oversight advice underwhelms. Get an AI expert on the board, run a literacy seminar, issue a principles memo: none of that tells a director whether 1.7% is real, and none of it shortens the halt. Education is a fine supplement and a dangerous substitute. The failure it breeds is specific, a roomful of directors who can define the risk fluently and still cannot intervene when it walks in.

This is Jevons paradox, and most cost essays stop there: make a resource cheaper and people consume more of it, often enough to raise total spend. True, and the dull half. The sharp half is that the token was never the expensive part of the work, so you are watching the wrong number deflate while the right number multiplies.

Price the task, not the call

A token price is the vendor’s unit. A completed task is yours, and the two barely overlap. Take a contract-redline workflow run by an agent. Tag every span with one task ID and let it propagate through orchestration, retries, and tool calls; most tracing stacks already do this, so you are adding one OpenTelemetry attribute and one join against the review log, not building a cost system. Each model call reports its tokens and cost against that ID, and you sum them. The review queue logs minutes against the same ID, and you multiply by a loaded labor rate. One finished task then reads:

• 11 model calls, 190K tokens, $0.46 of inference
• 7 reviewer minutes at $90/hour loaded, $10.50 of labor

$10.96 a task. Inference is four percent of it. Cut the token price 40 percent and the task drops to $10.78. The line finance celebrated moved eighteen cents. Everything that actually costs money lives in the other 96 percent: the retries, the context reassembled on every call, the human who reads the output before it ships. None of it shows on a per-token dashboard, and all of it scales with usage.

That split, labor dwarfing inference, holds wherever a human still reviews each output. Strip the reviewer (a fully autonomous, high-volume pipeline) and the mix inverts: inference becomes the dominant cost, and a 40 percent token cut is suddenly real money. The rule is not that tokens never matter. It is that you cannot tell which regime you are in until the task, not the token, is the unit you count.

Where the bill actually goes

Cheaper inference does not reduce demand. It removes the brake on it. The moment the task got cheap, the team pointed the agent at three more queues, and monthly volume went from 50,000 tasks to 130,000. Reviewer load scaled right with it, and newly automated work needs more review, not less, because the messy cases are the ones that were too marginal to touch before. Run the arithmetic: 50,000 × $10.96 is $548K a month; 130,000 × $10.78 is $1.40M. The bill rose 156 percent while every line item got cheaper. The token savings were real. They were a rounding error against the consumption they unlocked.

What to instrument

Make cost per completed task the accounting boundary, put one owner on each workflow end to end, then:

• Route by value and risk. Expensive reasoning is scarce inventory, reserved for tasks that justify it; cheap paths take the rest. Multi-model routing is not a discount, it is a governor.
• Cap the loop. A hard ceiling on retries and tool calls per task, because an uncapped loop is an open invoice.
• Price the human in. A workflow that needs a reviewer every time is expensive whatever the tokens cost, and the dashboard should say so out loud.
• Compare on finished work. Rank vendors and routes by cost per finished task , not headline token rates, or you keep buying the cheaper token that triples the call count.

The trap was never that someone lied about the price. It is that the cheapest part of the work got cheaper, loudly, while the parts that actually move the invoice went uncounted.

Start with what the strategy deck stacks up as defensible. Three layers, usually. The model itself, rented, and your competitor can rent the same one. The scaffolding on top of it: prompt library, routing logic, eval harness, all shaped around one vendor’s behavior and all of it breaks the morning you change providers. If the moat disappears when the vendor changes, it was never a moat. It was a dependency. That clears two of the three layers off the slide. Swap the provider in your head; whatever still works the next morning is the only candidate worth the word.

What survives is the third layer, and it is the one boards cannot tell apart from its imitation: data your own operation produces by running. Here is the mechanism, and the exact place it breaks.

Take support automation. The model drafts a resolution; a human approves before it ships. Every rejection or rewrite captures a labeled triple: the input, the output the model produced, the output the human accepted. Not a log line. A graded example of where your model was wrong and what right looked like, on your tickets, in your domain.

Now the load-bearing step, the one most decks wave through. How does that triple make a cheaper model tier handle a class it used to escalate? Two mechanisms, two different bills.

Retrieval, the few-shot route: index the accepted exemplars and inject the nearest ones into the prompt at inference. Cheap to stand up, live the moment you index a correction, but it taxes every call in tokens and latency, and the lift is capped because you are renting the base model’s in-context learning.

Distillation, the fine-tune route: train the small model on the correction set. Latency stays flat, the behavior is baked in, per-call cost drops, but you pay a training-and-eval cycle up front and re-pay it on every base-model upgrade. Which tier absorbs which class is a cost decision, not a model-quality one: retrieval for the long tail, distillation for the high-volume classes once they stop drifting.

Either way, one number tells you which you have: escalation rate on a single request class, quarter over quarter. Falling and sustained while quality holds is the loop compounding. Flat is a warehouse with a dashboard bolted to it. A logging pipeline and a compounding loop look identical in the architecture diagram and behave nothing alike in the P&L.

I cannot hand you a rival’s P&L to prove the good case, and any deck that shows you a clean before-and-after percentage is selling the illustration as the evidence. The honest test is one you run on your own numbers: name the class, name the two quarters it improved, name why a competitor on the same vendor cannot reproduce it. The answer to the last one is never the model. It is the system around it that turns each rejection into an exemplar only you hold.

Then the part the optimistic version omits: this asset depreciates. When the next base model ships, it absorbs your easy classes for free, everyone’s, not only yours, and that compresses the set of failures where your corrections still move the number. Your edge is only ever the residual: corrections illegible outside your context, your product’s quirks, your contractual edge cases, your policy language. The vendor will productize the capture loop; they already sell feedback buttons and fine-tuning APIs. What they cannot aggregate is a residual that means nothing without your business wrapped around it. The loop compounds only while you generate domain-specific corrections faster than a better base model erases the generic ones.

A beautiful demo is not a business model. It only proves the model can look useful before the business pays for edge cases. The bill arrives when the system hits real users, real load, and real failure conditions. At that point AI stops being a model-selection problem and becomes a routing problem , a fallback problem, and a repair problem. Good CTOs do not buy “smart.” They buy systems that stay cheap enough, predictable enough, and reliable enough to survive the week.

Unit economics start with routing

The wrong AI architecture sends every request to the most expensive path. That feels elegant until the invoice arrives. Mature systems route by value and by risk.

A practical routing model usually splits work into classes:

• trivial tasks that should stay cheap and local
• medium-value tasks that deserve a balanced model tier
• high-stakes tasks that justify expensive reasoning and stronger checks

This is not model worship. It is cost discipline.

The hidden cost is rarely the model line item

Teams fixate on tokens because tokens are visible. The real bill sits around the model: retries, context assembly, human correction, support escalation, and the work of proving the output is acceptable.

If a system saves one minute for a customer and creates two minutes of cleanup, it is destroying margin.

A finance-aware CTO should be able to answer these questions without hand-waving:

• what each class of request costs to serve
• where the rework happens
• what failure costs when the model is wrong
• which parts of the workflow justify premium inference

The real decision is not model choice, it is failure cost

“Best model” is usually the wrong conversation. The useful conversation is about failure cost.

A cheaper model that fails gracefully can beat a more expensive model that fails silently. A local fallback that keeps the system alive during a rate-limit event can matter more than a small quality lift in the happy path.

The CTO playbook is simple: optimize the whole system, not the benchmark screenshot.

Measure margin at the workflow level

The right unit of measure is the workflow, not the model call.

Ask:

• how much does this workflow cost end to end?
• how often does it need human repair?
• how long does it take to reach a trustworthy answer?
• what is the revenue or labor value of the result?

That is where the business truth lives. A model that looks slightly less accurate in isolation may create better margin if it is cheaper, faster, and easier to trust.

A practical threshold

If the system does not improve margin, then it needs to improve risk or speed. If it improves neither, it is a demo that escaped the lab.

AI work that survives budget review answers one of four questions:

• does it lower cost per task?
• does it reduce human labor?
• does it increase throughput?
• does it unlock new revenue with acceptable risk?

If not, the demo should stay in the demo lane.

Key Takeaways

• Route cheap work cheaply.
• Model cost is only part of the bill.
• Measure workflow margin, not call cost.
• If it does not improve margin, risk, or speed , it does not belong in production.

1. Workload Facts You Must Have

The vendor’s first move is to define your usage for you. Don’t let them.

• Total request volume per month, broken out by use case A single aggregate number is not enough. Know which workflows drive cost.
• Cost per task class (e.g., generation vs. classification vs. retrieval) If you cannot name your top three cost drivers, you cannot challenge the invoice.
• Latency p50/p95 by workflow, measured from your own instrumentation Vendor SLAs are measured at their edge, not yours.
• Percentage of spend attributable to this vendor vs. total AI budget Concentration creates leverage — for them. Know the number.
• Named owner of the vendor relationship on your side If no one owns it, no one negotiates it.

2. Architecture Leverage Check

Leverage is an architecture property. Answer these before you sit down.

• Is the vendor’s API called directly from product code, or through an abstraction layer ? Direct calls = switching costs measured in months. Abstraction = measured in days.
• How many distinct integration points does this vendor touch? Write the number. Fewer than five is manageable. More than ten is a dependency.
• What is the estimated engineering cost to swap this vendor? Get a real estimate, even a rough one. “Unknown” is not an answer.
• Do you have a secondary provider you have already integrated, even partially? Yes/No. If no, you have no credible threat.
• Does your data pipeline depend on vendor-specific formats or embeddings ? Format lock-in is often more expensive than API lock-in.

3. Evaluation Evidence

Vendors sell on benchmark claims. Counter with your data.

• Do you have evals that measure model performance on your actual workload ? Yes/No. If no, you are buying on their terms by default.
• Which models have you tested against your task suite in the last 90 days? List them. If the answer is only theirs, you have no comparison point.
• What is your acceptable quality threshold, defined numerically? “Good enough” is not a threshold. A number is.
• Have you run a cost-per-correct-output comparison across providers? Price per token is a distraction. Price per correct result is the metric.
• Who owns your eval framework and can demo it in the meeting if needed? Named person, not a team.

4. Exit Credibility

A vendor that believes you cannot leave does not negotiate. Make them uncertain.

• Do you have a documented migration plan, even a sketch? It does not need to be final. It needs to exist.
• What is your contractual notice period to exit? Know this before they remind you of it.
• Have you identified which vendor you would move to first if pricing increased 40%? Name them. Vague alternatives are not alternatives.
• Is there a sunset timeline for any features that are vendor-exclusive today? If yes, the vendor knows your dependency has an expiration date.
• Can your team absorb a two-week migration sprint without derailing the roadmap? Yes/No. Honest answer only.

If you cannot fill in the workload numbers, you are not done preparing — you are about to negotiate against someone who has already modeled your spend. If you have no eval data, you will accept their performance claims by default. If there is no exit plan, any number they name is essentially a take-it-or-leave-it offer. The meeting itself is the wrong place to discover these gaps. Thirty minutes with this worksheet before you walk in is worth more than any negotiation tactic once you are in the room.

AI programs rarely fail because one team is incompetent. They fail because the organization tells itself three different stories about the same system. Engineers hear one version of reliability, executives hear one version of commercial impact, and investors hear one version of scale. By the time those stories collide in a board meeting, the disagreement has already been baked into the program. A CTO’s job is to keep the story true enough that people can act on it.

The Alignment Problem

Every layer in a company listens for a different failure.

Engineers ask: can we make it reliable without turning the stack into a science project?

Executives ask: can it matter this quarter, not someday?

Investors ask: can it scale without becoming a support burden, a security problem, or a margin leak ?

If those questions are not coordinated, the organization drifts into avoidable conflict. Product thinks it shipped success. Engineering thinks it shipped risk. Finance thinks it shipped cost. The AI program becomes a political object instead of an operating system.

What Each Layer Needs to Hear

A good communication protocol gives each audience the right level of detail and nothing more.

Engineers need constraints, failure modes, ownership, and the exact conditions under which they should stop or escalate.

Executives need the business outcome, the tradeoffs, the cost of delay, and the risk of waiting for a perfect answer.

Investors or board members need the thesis, the numbers, the confidence interval around those numbers, and the reason the company believes the numbers are real.

The common mistake is predictable: over-share implementation detail upward and under-share operational reality downward. Leaders either talk past each other or sand off the complexity to keep the room calm. Neither habit helps. Clarity is kinder than politeness when the system is expensive.

Build a Communication Rhythm

Strong CTOs do not improvise every update. They set a rhythm that forces the same narrative to appear at predictable intervals, so the organization can spot drift before it becomes a surprise.

A practical cadence looks like this:

• weekly: operational progress, blockers, decisions made, decisions deferred
• monthly: outcome metrics , risk posture, and what changed in the operating assumptions
• quarterly: strategy shifts, tradeoffs, roadmap changes, and what the board should expect next

That structure gives the organization memory and gives the board a clean way to compare this quarter with the last one.

The point is not to produce more slides. The point is to keep the story consistent enough that people can challenge it honestly.

Misaligned narratives are delayed incidents.

Use the Same Three Questions Everywhere

Keep asking the same three questions in every forum: what changed, what did it affect, and what happens next? Those questions work at the team level, the executive level, and the board level because they force the same discipline: outcome, consequence, next move. If a layer cannot answer them, the communication is not yet useful.

Alignment is not consensus. It is a shared operating picture.

Key Takeaways

• AI programs fail when each audience hears a different success definition.
• Engineers, executives, and investors need different levels of detail, but they need the same core truth.
• Use a consistent communication rhythm so the story does not change every time the room changes.
• Keep asking what changed, what it affected, and what happens next until the answer is sharp enough to survive board scrutiny.

Most AI dashboards count motion, not progress. They record pilots, prompts, and meetings, then call that momentum. If the scorecard cannot show adoption, reliability, margin, or cycle-time improvement, it is a prop. A board should be able to read it and know whether the business is better off.

The Theater Problem

AI reporting drifts toward vanity metrics because vanity metrics are easy to collect and hard to argue with.

The usual suspects:

• number of pilots launched
• number of prompts written
• number of models tested
• number of meetings held
• number of slides in the board update

None of those is useless on its own. The problem is that none of them answers the only question that matters: what improved because we shipped this?

A Better Executive Scorecard

A serious AI scorecard should be small enough to remember and strong enough to force a decision.

Start with four dimensions:

1. Adoption — are real users using it in a real workflow?
2. Reliability — does it fail in bounded, observable ways?
3. Margin — does it reduce cost or improve unit economics?
4. Speed — does it shorten a real business cycle time?

If a project does not move at least one of those numbers, it is not strategic. It is a lab exercise with a budget.

The point is not to build a perfect dashboard. The point is to make it impossible to hide weak outcomes behind busy activity.

What to Report Weekly

A weekly AI review should be short, blunt, and decision-oriented.

Report:

• what shipped
• what users actually did with it
• what broke
• what it cost
• what decision changed because of the data

That last bullet matters. Progress reporting without decisions is performance art.

A team can launch five experiments in a week and still have no strategy. Strategy shows up when the evidence sharpens the next choice.

Keep the Dashboard Honest

There are two reliable ways AI dashboards lie.

First, they drift toward lagging metrics only. By the time the board sees the number, the product problem is already old.

Second, they reward volume instead of signal. A busy roadmap can still be a weak roadmap.

Keep the dashboard honest by requiring every metric on the top page to map to one of three board outcomes :

• margin expansion
• risk compression
• execution-speed advantage

If a metric does not help the board understand at least one of those outcomes, it belongs lower in the stack or not at all.

A line worth keeping: if the scorecard cannot survive finance review, it is not strategy.

Key Takeaways

• Measure adoption, reliability, margin, and speed.
• Weekly reviews should force decisions, not decorate slides.
• Tie every visible metric to margin, risk, or execution speed.
• If the dashboard cannot survive finance review, move it off the first page.

Most AI strategy decks are full of nouns and short on numbers. That is usually the tell. If a project cannot move margin, reduce risk, or shorten the path to an outcome, it is not strategy. It is activity with a steering committee.

Why Three Numbers Are Enough

Leaders overcomplicate AI strategy because they do not want to choose.

But every AI decision eventually lands in one of three buckets:

• Margin — does it improve unit economics?
• Risk — does it make the system safer or more controllable?
• Speed — does it shorten the path from decision to outcome?

That is the executive frame. Everything else supports it.

If a project cannot clearly improve at least one of those numbers, it does not belong near the top of the roadmap.

The Trap of Novelty Metrics

AI teams love the wrong metrics because the wrong metrics are easy to count.

Number of models tested. Number of pilots launched. Number of prompts written. Number of demos shown. Number of meetings held.

Those numbers can tell you whether work is happening. They do not tell you whether the company is getting more profitable, less exposed, or faster to act.

Build a Scorecard Around Outcomes

A serious AI scorecard is short.

1. Did margin improve?
2. Did risk go down?
3. Did cycle time shorten?

Everything else is instrumentation that helps answer those questions.

That does not mean you ignore adoption, reliability, or cost. It means you use them as inputs to the three executive numbers, not as substitutes for them.

The strongest boards and founders do not need twenty metrics. They need a few numbers that are hard to fake.

Make the Three Numbers Operational

The framework only works if the numbers are real.

For each AI initiative, define:

• the baseline
• the target
• the measurement cadence
• the owner
• the rollback path if the numbers move the wrong way

That keeps the conversation concrete and makes the project accountable.

A line worth keeping: if a strategy cannot change one of the three numbers, it is probably theater.

Key Takeaways

• Margin, risk, and speed are enough to evaluate AI strategy.
• Stop reporting novelty metrics as if they were outcomes.
• Give every project a baseline, target, owner, cadence, and rollback path.
• If the work does not change the numbers, the work is not strategic.

In 2026, a CTO’s AI strategy is not a model shortlist. It is an operating model for data, latency, evaluation, and failure. The model will change. The system around it should not.

If your AI plan still starts with “which model should we buy,” you are solving the easiest problem in the room. The moat is the pipeline that feeds context, the eval loop that catches regressions, and the fallback path that keeps the product standing when the model misses.

The Strategy Is the Infrastructure

The single biggest mistake engineering organizations make is treating the model as the brain. It is not. It is the most expensive dependency in the stack.

The brain is everything you build around it: context assembly, retrieval, validation, retries, telemetry, and rollback.

A CTO must focus ruthlessly on three pillars:

1. The Context Pipeline

The model is only as intelligent as the context you feed it. If Postgres, Cassandra, or Scylla takes five seconds to assemble structured context, encode it, and hand it to the orchestrator, your feature is already late before inference begins.

Strategy means architecting data replication, embedding generation, and caching so the latency budget stays intact for the inference layer. If your data infrastructure is not close to real time, your AI will not be either.

2. The Evaluation Framework

You cannot scale what you cannot measure. If your organization is still eyeballing model outputs before deployment, you are running a pilot, not a production system.

Leadership means demanding continuous evaluation. Every PR that touches an orchestration layer must be blocked by a CI pipeline that runs 500 deterministic evals against the new reasoning flow. Building that telemetry is the AI strategy.

3. Graceful Degradation and Fallbacks

LLMs fail. APIs throttle. Endpoints rotate. If a model hallucinates malformed JSON and your core application crashes, that is not an AI failure; that is an architectural failure.

A mature strategy wraps every AI interaction in circuit breakers. If the model fails three times, what is the deterministic fallback? If the cloud provider rate-limits you, where is the local, quantized 8B-parameter fallback model running in your own cluster?

Stop Chasing the Frontier

The frontier-model conversation is a distraction. Unless you are OpenAI or Anthropic, you do not win by having the smartest model. You win by having the tightest feedback loop, the cleanest data access, and the lowest cost per transaction.

A strong CTO designs for swapability : a single configuration commit, zero downtime, and telemetry that proves the new model performs 4% better on the exact workload that matters.

That is the strategy. Everything else is theater.

Quick take

Technical due diligence isn’t a code audit. It’s a risk conversation. Investors want to know if the technology can do what the pitch deck promises, whether the team can sustain it, and what breaks first under growth. If you’re being evaluated, lead with honesty. If you’re evaluating, ignore code style and focus on architecture, people, and the gap between plan and reality.

What Investors Actually Care About

Here is what doesn’t matter: whether you use tabs or spaces, whether your code coverage is 80% or 90%, whether your variable names are poetic. I’ve never seen a deal die over formatting.

Here is what does matter: Can the product do what the sales team is promising customers today? Can the team extend it to do what the business plan says it will do in eighteen months? What are the risks that could slow that down or stop it entirely?

That’s really it. Everything else is a detail that feeds into one of those three questions.

Stage changes the lens considerably. When I went through diligence at the mobility startup, we were early. The codebase was scrappy. Some of our deployment was still manual. Nobody cared. The investors wanted to know if we understood our technical risks, if we could ship fast, and if the founding team had the judgment to make sound architecture decisions under pressure. At growth stage, the bar moves. Multiple engineers need to work in the codebase without stepping on each other. Deployments need to be repeatable. Security can’t be an afterthought. But even then, perfection isn’t the standard. The standard is: does this team know what they are doing, and are they making reasonable tradeoffs for their stage.

Preparing When You’re Being Evaluated

I learned this the hard way at the fintech startup. Our first due diligence session was a scramble. An investor’s technical advisor asked for an architecture diagram and we didn’t have one. Not because the architecture was bad, but because nobody had written it down. We spent half the session whiteboarding basics instead of talking about the interesting parts of our ML pipeline. That was a waste.

Prepare a one-pager: architecture overview showing major components and data flow, stack list with brief rationale for key choices, infrastructure and deployment notes, team structure, and how a feature moves from idea to production. You can write this in an afternoon and it will cover 80% of what reviewers ask for.

Surface your weaknesses before they surface them. Every startup has technical debt. Every startup has areas where security is thinner than it should be. Every startup has a bus factor problem somewhere. If you say “we know our payment integration is fragile and here is our plan to fix it in Q1,” that builds trust. If the reviewer discovers it and you look surprised, that destroys trust. I’ve seen founders try to hide known problems. It never works. Good technical reviewers will find them, and then you have two problems: the weakness itself and the fact that you tried to hide it.

Clean up the obvious things. Remove dead code. Make sure there are no credentials committed to the repo. Fix the broken tests that have been ignored for months. Reviewers will sample, not read every line, but first impressions carry weight. A repo with secrets in the commit history signals carelessness.

Get your IP house in order. Employee IP assignments should be signed. Third-party licenses should be compatible with your business model. If anyone copied code from a previous employer, deal with that now. This is one of the few areas where a due diligence finding can actually kill a deal.

Evaluating Someone Else’s Technology

When I evaluate a company for an investor or acquirer, I follow a specific order that has served me well.

Architecture first. I ask the CTO to walk me through the system on a whiteboard. Not slides. A whiteboard. I want to see if they can explain their own system clearly, where the boundaries are, how data flows, and where the external dependencies live. This conversation tells me more in thirty minutes than reading code for a week. If the CTO can’t explain their architecture clearly, that’s a serious signal regardless of what the code looks like.

Team second. I talk to engineers individually. Not the CTO’s hand-picked representatives, but a cross-section. I ask about the last production incident. How they handle disagreements about technical direction. What they would change if they had a week with no feature pressure. The answers reveal whether the team has real ownership or whether everything flows through one person’s head. Bus factor is a real risk. If one departure would cripple the product, that needs to be in the report.

Code third, and selectively. I look at authentication and payment code because security mistakes there are existential. I look at the core business logic that creates differentiation. I read a few recent commits to understand current engineering standards, and I look at some older code to see how legacy is handled. I’m not grading style. I’m looking for evidence of judgment.

Operations and infrastructure. How often do they deploy? What happens when something breaks at 2 AM? Is there monitoring? Is there alerting? Are there runbooks, or is the incident response plan “call the CTO”? Manual deployments are a yellow flag. No monitoring is a red flag. At the mobility startup, we had invested in Terraform and automated deployments before our due diligence. That came up in the review and signaled operational maturity that investors valued beyond the code itself.

Scalability in context. I don’t care if the system can handle ten million users if the business plan targets ten thousand. I care about whether the team has thought about what changes at 10x their current scale. Honest answers like “our database will need read replicas at 5x and we’ll probably need to shard the activity feed at 20x” are far more reassuring than “we can scale infinitely because we’re on AWS.”

The Signals That Actually Change Outcomes

Red flags, in my experience, cluster around people and process more than technology.

No version control. I’ve seen this exactly once, and it ended the evaluation immediately. Foundational process failure.

The CTO can’t explain the architecture. If the technical leader doesn’t have a clear mental model of the system, nobody does.

Defensive answers. When I ask about a weakness and the response is deflection or minimization, I assume there are more problems I haven’t found yet. Transparency is the single strongest signal of engineering maturity.

Key person dependency with no mitigation plan. One person holding all the context for a critical system isn’t unusual at a startup. But if the team hasn’t acknowledged it as a risk or started documenting, that tells me something about how they think about risk generally.

Yellow flags need context. Technical debt is normal. Outdated dependencies are common. A monolith is fine at early stage. Limited monitoring is fixable. A junior team can work if leadership is strong. These are concerns, not deal breakers. The question is always: does the team know about it, and do they have a credible plan.

Writing a Report That’s Actually Useful

The worst due diligence reports I’ve read are laundry lists of findings with no prioritization. Twelve pages of “this function lacks error handling” tells the investor nothing about whether to write the check.

A useful report answers three questions: First, can the technology deliver on the current business promises? Second, what are the top three risks that could slow or stop progress? Third, what investment in time and money is needed to mitigate those risks? Everything else is appendix material.

Be balanced. If the team built something impressive given their constraints, say so. If the architecture is sound but the deployment process is fragile, say that too. Decision makers need to weigh risk against momentum, and a report that only lists problems is as useless as one that only lists strengths.

The Real Point

Technical due diligence is a conversation about risk, not a code review. The best outcomes I’ve seen, on both sides, come from honesty. As a founder, lead with what you know is weak and what you plan to do about it. As an evaluator, focus on architecture, team, and the gap between the plan and reality. The code is the least interesting part.