Who is Richard Ewing?

Richard Ewing is a Product Economist and AI Capital Auditor. He is the Founder of Exogram, a verification infrastructure for AI. He audits R&D spend and surfaces hidden capital risks like technical debt, AI cost overruns, and zombie infrastructure. He has scaled B2B SaaS from $0 to $25M ARR. Published in CIO.com, Built In, Mind the Product, and HackerNoon.

What is a Product Economist?

A Product Economist treats product decisions as economic decisions. Instead of measuring velocity or story points, a Product Economist measures Return on Invested Capital (ROIC), Cost of Goods Sold efficiency, and technical debt in dollar terms. The methodology was coined by Richard Ewing.

What is the Technical Insolvency Date?

The Technical Insolvency Date (TID) is the specific quarter where maintenance costs consume 100% of available engineering capacity, reducing feature velocity to zero. Calculate yours free at richardewing.io/tools/pdi.

Exogram is verification infrastructure for AI, founded by Richard Ewing. It prevents hallucination propagation with admissibility control planes and state-hashing commit enforcement. LLMs generate language; Exogram maintains reality.

How do I calculate technical debt cost?

Use the free Product Debt Index (PDI) calculator at richardewing.io/tools/pdi to quantify hidden technical debt in dollar terms, calculate your Technical Insolvency Date, and benchmark against industry standards.

How much does AI cost per query?

AI costs range from $0.0001/query for small models to $0.10+/query for frontier models like GPT-4. Use the free AI Unit Economics Benchmark (AUEB) at richardewing.io/tools/aueb to calculate your specific AI cost structure.

What is Dependency Hell?

Dependency hell describes the frustrating situation where software packages rely on other packages that conflict with each other, creating complex webs of incompatible version requirements. It is one of the most common and time-consuming forms of technical debt.

In modern software, a single application may have hundreds or thousands of transitive dependencies. When Package A requires version 2.x of Library Z, but Package B requires version 3.x of the same library, you're in dependency hell. The problem compounds exponentially as the dependency graph grows.

Dependency hell manifests in several ways: version conflicts that prevent updates, security vulnerabilities in pinned old versions, build failures after seemingly innocuous changes, and "works on my machine" problems caused by environment-specific dependency resolution.

The economic cost is substantial. Engineering teams can spend 10-20% of their time managing dependencies — updating packages, resolving conflicts, testing compatibility, and rolling back breaking changes. This is pure maintenance overhead that produces zero customer value.

Why It Matters

Dependency hell is a hidden multiplier of technical debt. Every unresolved dependency conflict makes future updates harder, increases security exposure, and slows down deployment velocity. Organizations that don't actively manage their dependency graph risk accumulating vulnerabilities that can lead to regulatory penalties or security breaches.

How to Measure

1. **Dependency Age**: Track the average age of your dependencies. Anything >2 years old is a risk.

2. **Known Vulnerabilities**: Use tools like Snyk, Dependabot, or npm audit to count known CVEs.

3. **Update Frequency**: How often can you update dependencies without breaking changes?

4. **Conflict Count**: Number of dependency version conflicts in your lock file.

5. **Time Spent**: Track hours spent on dependency management per sprint.

Frequently Asked Questions