Liquidation Cadence

James Phoenix
James Phoenix

Experimentation keeps my edge sharp. Liquidation cadence keeps my feet on the ground.


The Problem

Building infrastructure without shipping creates two failure modes:

  1. Infinite preparation risk: “I’m building leverage” becomes a story that hides fear of exposure
  2. Cognitive overfitting: Building systems for problems that never arrive

The Solution: Forced Liquidation Events

Every 2-4 months, do a liquidation event: ship something real (users/revenue/traffic/stakes) through the factory.

After each event:

  1. Do a short post-mortem
  2. Promote only proven learnings into boilerplate

The Promotion Rule

Nothing goes into boilerplate unless it survived liquidation.

Promotion criteria:

  • Liquidated once (used in a real shipped product)
  • Reused twice (proven generalizable)

The Extraction Test

“This should be easy to adopt in a new repo in an afternoon.”

If it passes, you’re compounding.
If not, you’re ossifying.

This is fundamentally a trade-off analysis problem: maximising reusability while minimising coupling.

Make sure you:

  • Periodically extract infra into templates
  • Keep it opinionated but lightweight
  • Avoid coupling it too tightly to one domain

The Barbell Strategy

A classic Probability-based approach to decision-making under uncertainty.

Leanpub Book

Read The Meta-Engineer

A practical book on building autonomous AI systems with Claude Code, context engineering, verification loops, and production harnesses.

Continuously updated
Claude Code + agentic systems
View Book

Cashflow Rail (stability)

Keep Udemy + selective client work alive enough that you’re never forced into panic decisions.

Compounding Rail (moat)

Keep building your software factory (agent harnesses, testing infra, OTEL, deployment repeatability).

This prevents the two failure modes:

  • (a) “no runway”
  • (b) “busy but not compounding”

Cadence Checklist

Weekly

  • Ship at least one improvement to the factory OR one user-facing increment
  • Run one “reality anchor” action (customer contact, prod experiment, real usage review)

Monthly

  • Measure lead indicators: time-to-ship, incident recovery time, regression rate, cognitive load

Quarterly (2-4 months)

  • Execute liquidation event
  • Post-mortem
  • Promote proven patterns to boilerplate
  • Prune unused abstractions

Your Only Obligation Now

Your only obligation now is to force a ship point so leverage meets reality.


Related

Math Reference

  • Probability: decision-making under uncertainty, risk management
  • Optimisation: trade-off analysis, balancing competing constraints
Topics
Coding AgentsReliabilityStartupsSystems Thinking

Newsletter

Become a better AI engineer

Weekly deep dives on production AI systems, context engineering, and the patterns that compound. No fluff, no tutorials. Just what works.

Join 306K+ developers. No spam. Unsubscribe anytime.


More Insights

Cover Image for Computer Use Kills the Config Tax, Not the Trust Tax

Computer Use Kills the Config Tax, Not the Trust Tax

My sister hates job applications because they make her re-submit information she already has. That is the same pain as API app review, and the same agent that lives in my codebase can dissolve both. This feels insane, and it is the new default shape of the work.

James Phoenix
James Phoenix
Cover Image for Sentry Errors Should Spawn Agents on Your Own Machine

Sentry Errors Should Spawn Agents on Your Own Machine

A new production error is an event. Events should trigger work, not sit in a dashboard. So I wired Sentry to spawn a coding agent on my own hardware, point it at my exact stack, and open a draft PR with a fix.

James Phoenix
James Phoenix