A $1.25 trillion valuation now sits on a funding round that hasn't finished closing

A $1.25 trillion valuation now sits on a funding round that hasn't finished closing.

OpenAI has reportedly taken in around $11 billion in a first close, with SoftBank and MGX among the participants. The round is still open, and the final total could climb well beyond that. Those are big numbers even by the standards of this industry, and it's tempting to read them purely as a story about one company. I think they say more about everyone building on top of it.

So rather than comment on the valuation itself, I want to look at what a round like this means for the teams shipping products on these models every day.

A small number of very large cheques

What I find most interesting is how much of the AI economy now depends on a small number of very large capital commitments. Every product team, startup and enterprise building on these models is, in a real sense, a stakeholder in whether that money keeps arriving.

That isn't a criticism of anyone involved. Training and serving these systems is expensive, and somebody has to pay for it. But it does mean that decisions made far away from your product can still show up inside it. Most teams don't think about their AI supplier this way. They see an API with a price per token, wire it in, and move on to the next ticket.

How capital shows up in your roadmap

For those of us building software on top of foundation models, the useful question is how that dependency shows up in our own roadmaps. Pricing, rate limits, model deprecations and feature priorities all trace back to what it costs to train and serve these systems, and to what investors are willing to fund next.

In practice it tends to look like this:

• Pricing changes. A model you budgeted around gets cheaper, more expensive, or moved to a tier with different terms.
• Rate limits. Capacity is finite, and your share of it can change as demand shifts.
• Deprecations. The model your prompts were tuned for is retired, and its replacement behaves slightly differently.
• Shifting priorities. Features you were waiting for slip, while others you never asked for arrive first.

None of these is dramatic on its own. Together, they mean part of your product's behaviour is shaped by someone else's funding plans.

The point isn't to predict which of these happens next. It's to notice that each one lands on your team as unplanned work: a re-tuned prompt, a regression nobody caught, an awkward budget conversation. If you build on these models, that work is coming at some point. The real question is whether you've made room for it.

Make the model layer swappable

I think the sensible response is to design products so the model layer can be swapped without a rewrite. Abstraction layers, evaluation suites and clear fallbacks turn a vendor decision into a configuration choice, which feels like cheap insurance when the numbers involved are this large.

Each of those pieces does a specific job:

• An abstraction layer keeps provider-specific calls in one place, so the rest of your codebase talks to your own interface rather than to a vendor's SDK.
• An evaluation suite gives you a repeatable way to check whether a different model is good enough for your actual tasks, using your own examples rather than a public leaderboard.
• Clear fallbacks decide in advance what happens when a model is slow, unavailable or too expensive, so an outage becomes a degraded experience instead of a broken one.

This isn't about avoiding any particular provider. It's about keeping the choice yours. Putting this kind of structure in place is a large part of our AI services work, and it is far easier to do early than to retrofit later.

What founders and product teams can do this quarter

• List every place your product calls a model, and note which ones would break if that model changed tomorrow.
• Build a small evaluation set from real user tasks and run it against at least two models.
• Keep prompts, model names and parameters in configuration, not scattered through the code.
• Decide what the fallback is for each critical feature, and actually test it.
• Track cost per completed task, not just cost per token, so a pricing change doesn't catch you out.

None of this needs a big programme. A week of focused work on a typical product gets you most of the way, and the payoff is that the next pricing email or deprecation notice becomes a routine change rather than a fire drill.

Two years from now

It also makes me wonder how many of the products we're all shipping today will still be built around the same model in two years' time. My guess is fewer than we expect. The teams that handle that well won't be the ones who picked the winner early. They'll be the ones who made switching boring.

If you're weighing up how to structure your next AI build, get in touch.