How to build, buy, and operate so the power at the compute layer stays contestable, whether you’re a company with a budget or one person with a GPU.
Part I (The Tenants’ Kit) made the case and the asks for capitalized firms that rent the frontier. Part II is the deployment guide, and it widens the audience on purpose: the moves here are for those same tenants (Track A) and for the independent builders (Track B) whose alternatives are what make contestability real in the first place. Both tracks are below, and they need each other.
The one principle
Build for exit, not for convenience. Every layer of your stack you could walk away from is a layer that stays contestable, for you and for everyone behind you. Convenience is how lock-in gets in: the provider-specific service that’s a little easier today, the model you can only rent, the data you can’t get back out. None of it announces itself as a trap. The discipline is to keep choosing the option you could leave.
Two kinds of builders make contestability real, and they need each other. Companies with budgets create demand and proof at scale for portable, open infrastructure. Independent builders create the alternatives and the efficiencies that make it viable. Same direction, different leverage. There’s a track below for each.
Track A: If you’re a company with a budget
You’re a tenant who wants leverage. These are the moves that cut your dependency and, in aggregate, keep the market contestable. Most of them cut cost, too. That’s not a coincidence: lock-in and overspend are the same problem wearing two coats.
1. Architect for portability. Keep workloads, data, and model weights movable. Prefer portable services and open standards over provider-specific ones wherever an equivalent exists; put an abstraction layer over the APIs you can’t avoid. And test your exit: an untested migration plan is a story you tell yourself, not an option you hold.
2. Right-size the model. Most jobs aren’t frontier jobs. A large share of production work (classification, extraction, routing, summarization, support automation) runs fine on smaller or open-weight models. Default to the smallest model that clears the bar; reserve frontier calls for the work that genuinely needs them. Every workload you move off the frontier is rent you stop paying and a dependency you stop deepening.
3. Adopt and fine-tune open weights. Run models you can host, inspect, and fine-tune on your own data, and own the fine-tunes. That’s the line between renting a capability and possessing one. It won’t be every workload. It should be more than zero, and it should grow.
4. Keep inference you control. On-prem, private-cloud, or edge inference for sensitive or high-volume workloads. Even partial in-house capability is leverage at the table and a fallback when terms change. And terms change.
5. Pool with peers. Shared clusters, consortium purchasing, buyers’ clubs. Mid-tier firms pooling demand or capacity gain real pricing leverage and a credible alternative to the landlords. This is countervailing power you can build with a procurement budget instead of waiting for someone to legislate it.
6. Buy for contestability. Make portability, interoperability, and openness explicit purchasing criteria. Write data portability, model portability, and exit rights into contracts. Reward the vendors who don’t lock you in and penalize the ones who do. You have far more power as a buyer than you spend.
7. Measure your dependency. Know your inference spend, your single points of failure, your true switching cost. You can’t manage what you don’t measure, and you can’t make a credible case for a contestable market if you can’t show your own house is in order.
Quick self-check: how locked in are you? If most of your AI spend runs through one provider, your exit plan has never been tested, you run no open-weight models, and not one of your contracts mentions portability, you don’t have a strategy, you have a landlord. Start with whichever of those is cheapest to change, and change it this quarter.
Track B: If you’re an independent builder
You are the proof that the concentration isn’t permanent. The open, efficient, distributed alternatives you build are precisely the thing the powerful are betting won’t arrive. Building them is the most direct work there is.
1. Run local-first. Own your stack: local inference, open weights, your own or modestly rented hardware. Infrastructure literacy isn’t a slogan; it’s the practice of knowing and holding the thing that does the work, instead of renting it sight unseen.
2. Push efficiency. Quantization, distillation, smaller specialized models, better serving and inference. Every efficiency gain shrinks the compute moat by a little. This is direct work on the single thing that would dissolve the whole problem.
3. Grow the commons. Open weights, open evaluations, open tooling, datasets, fine-tuning recipes: the open ecosystem is the contestable layer. Contribute to it, depend on it, and make it better than the closed option for the jobs where it can win.
4. Chip at the hard one. Pooled, federated, and distributed training (the routes by which non-incumbents could reach real scale together) are early and difficult, and they are also the structural disproof of the whole problem. Even partial progress moves the line.
5. Show the work, and find the others. Publish what runs well locally and openly. Create demand signals. Teach the next person in. A scattered set of independent builders is a hobby; a connected one is a constituency.
6. Be the pressure. As a customer and as a community, demand portability and openness from the platforms and vendors you use. The big builders move faster when their users ask, and slower when no one does.
Where the two tracks meet
The company that practices Track A becomes a credible buyer of, and a demand signal for, everything the Track B builders make. The independent builder who pushes Track B makes the open and efficient options good enough that Track A stops being a sacrifice and becomes the obvious call. Neither track wins alone.
Together they are the substitute path: the alternative route to the same capability that, in every earlier technology, is what kept the door from locking for good. The difference this time is that it will not appear on its own. It gets built, by the people reading this, from wherever they’re standing.