Twenty-Nine Turbines That Never Shipped

Crusoe raised $3.9 billion. Crusoe also just walked away from a $1.25 billion turbine order before a single unit arrived. Both of those things are true at the same time, and the gap between them is where the interesting part lives.

The short version: Crusoe, the Denver-based AI data center builder, cancelled its agreement to buy 29 natural gas-fired Superpower turbines from Boom Supersonic, also of Denver. The partnership ended before any deliveries began. Boom lost the first customer it had publicly named for its power business.

I build bots, not power plants. But I have killed enough dependencies mid-project to recognize the shape of this decision, and I think it’s the most useful thing to talk about here.

Canceling Before Delivery Is the Cheapest Cancel There Is

Every builder eventually picks a component that isn’t shipping yet. A model API in preview. A vector database with a promising roadmap. A framework at version 0.3 that solves your exact problem in the docs and nowhere else. You bet on the roadmap because the roadmap is better than what exists.

Then one of two things happens. Either the component ships and you look prescient, or the timeline stretches and you’re maintaining a workaround for something that was supposed to arrive last quarter.

What stands out about this cancellation is the timing. Nothing had been delivered. No hardware to decommission, no integration work to rip out, no operational history to untangle. That is the cheapest possible moment to change your mind, and it’s the moment most teams miss because by then they’ve already talked themselves into the sunk cost.

I’ve watched projects carry a bad dependency for months past the point where everyone privately knew it was wrong. The switch stays in because switching feels like admitting the original call was bad. Crusoe made that admission with $1.25 billion and 29 units on the line. The scale is absurd compared to anything on my machine, but the decision structure is identical.

Unproven Components Carry Unproven Timelines

Boom’s turbine line was new. Crusoe was going to be the launch customer, which means Crusoe was going to be the one discovering every edge case in production. For AI data centers, where power is the binding constraint on everything else, being the first to find out whether something works at scale is a specific kind of exposure.

Launch-customer status looks like use in the negotiation and feels like a liability in the deployment. I’ve been the first adopter of enough libraries to know how it goes: you file the bug reports, you write the missing documentation in your own codebase as comments, and you absorb the schedule slip nobody forecast. Sometimes that’s worth it. When the component is load-bearing and the alternative is a known quantity, it usually isn’t.

What This Means If You Are Building Agents

The bot-building version of this story plays out constantly, just with smaller numbers. Here is how I try to keep it manageable:

• Write down the bet. When you pick an unshipped or immature dependency, record what you’re assuming — the timeline, the capability, the pricing. A bet you never wrote down becomes a decision nobody remembers making.
• Set a decision date, not a hope. “If this isn’t working by the end of the month, we switch.” Put it in the ticket. The date does the hard part for you.
• Keep the interface thin. Wrap the risky dependency behind your own abstraction so swapping it is a file change, not an archaeology project. This is boring advice that pays for itself the first time you need it.
• Know your fallback before you need it. The question isn’t whether the new thing is better. It’s whether the new thing is better than the specific alternative you’d actually use instead.
• Treat the cancel as a normal outcome. If backing out is framed as failure, your team will avoid it past the point of usefulness.

Two Companies, Two Different Mornings

For Crusoe this is a course correction with capital in the bank. For Boom it means the named launch customer for the power business is gone before deliveries started, and the next customer conversation begins without that reference.

That asymmetry is the part I’d sit with. When you’re the one depending on someone else’s roadmap, walking away is an option you can exercise. When you’re the one whose roadmap others depend on, a single cancellation reshapes how your product gets discussed. Most of us building bots are on the first side of that relationship, picking and discarding tools as we go. Worth remembering there’s a team on the other end of every dependency you drop, and worth building so that dropping one costs you a day instead of a quarter.

🕒 Published: September 26, 2026