A $13 billion deal and the question to ask your own product

Short answer. Nvidia has agreed to buy Hugging Face, and nothing in your system changes tomorrow. The useful question is a different one: which parts of your product stop working if a single supplier changes its price, its licence or its terms. Most companies have no answer, because nobody asked.

Good news almost always arrives without instructions for what to do about it.

What exactly did Nvidia buy?

The place nearly everyone gets open models from. The price is $12.93 billion, announced on 3 September.

Strictly, the deal is not done: Nvidia has agreed to buy, closing is expected in the first half of 2027 and needs regulatory approval. Of the total, $11.9 billion goes to shareholders and up to $1 billion is a retention programme for staff joining Nvidia. It is Nvidia's second-largest purchase, after the $20 billion it paid for Groq assets.

Hugging Face in numbers from the press release: 18 million developers, more than 3 million models, more than 200,000 companies finding and deploying AI there.

Jensen Huang said the thing everyone wanted to hear straight away. The platform stays open to the whole industry, and Nvidia hardware will not be required to build on it.

That is a statement from a party to the deal rather than a guarantee. Disputing it in advance would be silly, and writing it down to check it against later is sensible.

Should you change anything now?

No, and that is arithmetic rather than caution.

Nothing changes tomorrow. The models stay where they are, the licences are the same, your code runs as it ran. Closing is at least six months out, and changes to terms, if they come, will not arrive on the day of signing.

Moving on a rumour costs more than the risk does. You spend weeks of engineering time hedging against a possibility and arrive at another supplier who has its own deal a year later.

Two things get confused here and are worth separating. Dependency is normal: you depend on electricity, on a bank, on Vercel or AWS. It becomes a problem in two cases: when you did not know about it, and when there is nothing to replace it with.

So what is the question worth asking?

Which parts of your product break if one supplier changes its terms. The answer is usually shorter than people expect, and worse.

Most people answer with a list: we use OpenAI, we host over there, the database is this one. That is not an answer, it is an inventory. The answer appears when each line has two more columns beside it: how long a replacement takes, and what is lost in the swap.

The last row is the important one and it usually goes unwritten. What you built yourself is not cancelled by anybody else's deal.

What does owning your own stack actually mean?

Not writing everything from scratch. Keeping the things you cannot buy twice.

Four of them count as yours, and none is the model.

Data. Your enquiries, your conversations, your deal history. If they live only in somebody else's service and only export halfway, you own them conditionally. One action tests it: press "export everything" and look at what arrives. Attachments often do not come, links between records are gone, and dates have moved into a format of their own. An export you cannot load anywhere else is not an export.

Prompts and rules. How your agent talks and what it decides. That took months to write and takes a day to reproduce on a new model, provided you kept them.

Process logic. Who approves what, which limits apply, what the system does overnight. That is your business, not a supplier's feature.

Integrations. The wiring into CRM, mail and payments. Slow to build and easy to lose along with a platform, if they live inside it.

Abstracting the model provider costs less than people assume: usually one layer in the code where calls go through an interface of your own rather than directly. A day at the start, a week later on.

It looks dull and works for exactly that reason. Instead of calling the model from twenty places, you call it from one and the other nineteen call that one. On the day a price rises or a model retires, one file changes. Without that layer the same move takes a week of searching the project, and somewhere there is always a forgotten call that breaks in production.

Checking your own is easy. Search the codebase for the provider's name. If it appears more than twice, you do not have the layer.

One honest caveat. Custom development is not always the right answer. If the job is ordinary and a packaged product solves it, buy the package: it will be faster and cheaper, and we will say so on the first call. Building your own earns its place where the process is what makes you different, or where the package would force you to reshape the business around it.

How do you check your system in an evening?

Write down what you depend on and answer, next to each line, what happens if it disappears.

1. List everything external your product calls. Models, hosting, databases, mail services, payments, search. From the invoices and the code, not from memory.
2. Put a replacement time in days beside each one. Not "hard" and not "expensive", a number. Where no number appears, you have found the weak spot.
3. Note where your data lives. If the export is partial or the format is closed, that costs more than any supplier swap.
4. Check whether you call the model directly. If you do, put a layer in between. It is the cheapest insurance on the list.
5. Separate what can be replaced from what will never need replacing. Your logic and your integrations should not be on that list at all.

One honest thought to close on. Some dependency always remains, and that is fine: nobody needs their own power station. The difference between a healthy dependency and a problem is whether you know what the exit costs, and whether that is written down anywhere other than in one person's head.

The Nvidia deal broke nothing in your system. It is just a good reason to finally write it down.