Picture a project plan pinned to a wall in Denver. Twenty-nine boxes, each one a natural gas-fired turbine, each one sequenced against a data center build that has to come online before the GPUs inside it stop being the current generation. The turbines have a name, Superpower, and a price tag, $1.25 billion. Nobody has shipped one yet. Then somebody redraws the plan, and all twenty-nine boxes disappear.
That is roughly what happened when Crusoe, the AI data center builder that recently raised $3.9 billion, ended its agreement to buy those turbines from Boom Supersonic, a fellow Denver company. The partnership was terminated before any hardware was delivered. Boom lost the first customer it had named for its power business.
I build bots for a living. I do not pour concrete or permit gas lines. But I have made this exact mistake at a much smaller scale, and so have you, and that is why this story is worth sitting with.
The unshipped dependency problem
Every builder has done it. You are architecting something, you find a project that solves your hardest problem perfectly, and it is in beta. Or it is announced. Or a founder told you on a call that the API will be ready next quarter. The docs look great. The benchmarks in the blog post look great. You sketch your system around it because the alternative is uglier and slower and more expensive.
Then the thing does not ship, or it ships different, and now you are rewriting the core of your bot under deadline pressure.
Crusoe’s version of this ran into the billions and involved turbines instead of a vector database, but the shape is identical. A brand-new product line, no delivered units, a critical dependency in the plan. The difference is that Crusoe walked away before the money was fully committed and before the hardware showed up. That is not a failure of judgment. That is a decision point being exercised correctly, which is more than most of us manage with our own stacks.
What this means for anyone whose bot runs on rented compute
Here is the chain most of us never look at. Your agent calls a model API. That API runs in a data center. That data center needs power, and increasingly the companies building these facilities are sourcing power themselves rather than waiting in line for grid interconnection. Natural gas turbines on site are one of the ways that happens.
So when a $1.25 billion power deal for AI data centers collapses, it is a signal about the layer four or five levels beneath your code. Not a crisis, not something you can act on directly, but a reminder that the compute you treat as infinite and always-on is backed by physical objects that sometimes do not get built.
The practical takeaway is not “panic about electricity.” It is this: the AI infrastructure buildout is still improvising. Deals get signed and unsigned. Timelines move. If your product’s unit economics assume that inference costs keep falling on a smooth curve, you are making a bet on a supply chain that is visibly still figuring itself out.
Three habits I have picked up
- Write to an interface, not a vendor. Put a thin adapter between your bot and any model provider. Mine is boring, maybe eighty lines, and it has saved me twice already when pricing or rate limits changed overnight. Two providers behind one interface is cheap insurance.
- Know your cost per task, not your cost per token. If a provider’s price doubles or a region goes capacity-constrained, you need to know instantly which features are still viable. That means instrumenting cost at the workflow level, tagged by feature, not just watching a monthly bill.
- Treat announced capabilities as zero. If it is not in your hands and running in a test, it does not exist in your architecture. Design for what ships today, and let the good news be upside instead of a load-bearing assumption.
Walking away is a skill
The part of this story I actually admire is the cancellation itself. Crusoe had a signed agreement, a local partner, and presumably a lot of internal momentum. Killing a deal that size means telling people the plan they built is now the old plan. Most organizations, and most solo builders, will keep feeding a bad dependency because switching feels like admitting the original call was wrong.
I have shipped bots on frameworks I should have abandoned three weeks earlier. The cost was never the rewrite. It was the weeks I spent hoping the problem would resolve itself.
Boom, for its part, now has a power product without a named launch customer, which is a hard place to be and a reminder that being the first buyer of anything carries a premium nobody prices correctly.
Build your bots so that losing any single supplier is an afternoon of work, not a quarter. The companies spending billions on this stuff are learning the same lesson in public, at a scale where the mistakes have turbines attached.
đź•’ Published: