The language of codebase intelligence.

Decision archaeology

Decision archaeology is the practice of reconstructing why a software system became what it is. Most of the risk in a codebase lives not in the source but in the decisions that shaped it — decisions made under deadline, by people who have since left, that nobody wrote down. Decision archaeology correlates code, commit history, tickets, PRDs, roadmaps and ownership over time to recover that sequence of decisions.

The output is understanding, not a scanner report: you leave knowing not just what the software is, but why it is that way, and what that means for what you do next.

See it in practice: How it works.

Independent codebase intelligence

Independent codebase intelligence is a continuous, multi-source read of a software system — code, commits, tickets, roadmaps, ownership and data — produced independently of the team that built it. The word that matters is independent: it isn't the engineering team's account of itself, and it isn't a single scanner's score. It is evidence, traceable to the commit, that a CEO, board, or acquirer can rely on.

The firm built around it: About Founders Led Studio.

Codebase audit

A codebase audit is a structured review that reads the source, commit history and dependency tree directly to assess security, code quality, architecture, license risk and knowledge concentration. A thorough audit produces prioritized, reproducible findings — the three things that will actually cost you — rather than a thousand-line scanner dump and a number.

The engagement: Code audit services.

Technical due diligence

Technical due diligence is an independent assessment of a software asset's real condition for an investor or acquirer. It answers the questions a deal turns on: how far the system has drifted from its requirements, who holds the critical knowledge, whether it scales to the growth thesis, what you actually own, and what it would cost to replicate — read from the code itself rather than from a three-day round of interviews.

The engagement: Technical due diligence.

Engineering intelligence

Engineering intelligence is evidence about an engineering organization's reality — what exists, who holds critical knowledge, where time and risk concentrate — derived from the artifacts engineers actually produce: code, commits, and tickets. It differs from a metrics dashboard in that it explains the why behind the numbers, not just the numbers.

Technical debt (at the executive level)

To an engineer, technical debt is shortcuts that make code harder to change. To a CEO or board, it is something more precise: the quantified cost — in money and time — of those shortcuts, expressed by business domain. "The billing domain carries roughly nine months of accumulated debt and is where two thirds of your defects originate" is a board statement. "The code is messy" is not.

Related reading: Quantifying technical debt.

AI footprint

An AI footprint is the complete picture of where AI runs inside a company's software — which models, in which products, touching what data, making which decisions. It is the thing a CEO must understand before attesting to anything about AI, and it is surfaced from the code, dependencies and configuration rather than from a form the team fills out from memory.

For boards and CEOs: AI readiness & board tech read.

Shadow AI

Shadow AI is the AI and machine-learning running in a company's software that was never formally reported or reviewed — a model a team wired in last quarter, an AI capability buried in a dependency. Because manual inventories only capture what people remember to report, shadow AI is usually where a board's real exposure sits, and finding it requires reading the code, not circulating a survey.

How we surface it: AI readiness.

Key-person risk (bus factor, the hero problem)

Key-person risk is the exposure created when critical knowledge of a system is concentrated in one or a few people. The bus factor is the count of people who would have to leave before a component becomes unmaintainable; a bus factor of one on revenue-critical code is a material finding. We also call the underlying pattern the hero problem: the system runs because one person holds it in their head.

Related reading: The hero problem.

Roadmap drift

Roadmap drift is the gap between the roadmap leadership approved and what engineering actually built. It is measured by comparing stated plans against the work evidenced in commits and tickets — not by asking the team whether they're on track. Drift is rarely deliberate; it accumulates quietly, which is exactly why an independent read catches it before the quarterly review does.

For operators: PE operating-partner read.

Post-acquisition value-creation engineering

Post-acquisition value-creation engineering is the work that turns an acquired or portfolio company's software into value after close. It means directing engineering investment to the domains that drive returns and away from the maintenance nobody chose — a decision that depends on an independent read of where value is actually being created and destroyed in the code, not on the management team's narrative.

For acquirers: M&A diligence.

The Five Stories

The Five Stories is the framework Founders Led Studio uses to deliver findings as business narratives instead of a dashboard. Each story answers one decision a leader has to make: Architecture (what you actually have versus the plan), Knowledge (who holds the keys and what breaks if they leave), Risk (debt, security and AI exposure, quantified and ranked), Velocity (whether engineering time goes to the roadmap or to unapproved maintenance), and Investment (whether the strategic plan is being executed or investment is drifting).

Why narratives, not dashboards: The Five Stories framework.