Voluntary buyouts at Microsoft: what Bun teaches us

Microsoft offered a voluntary buyout program to roughly a quarter of the company. The news came out in the Seattle Times. And this wasn't a company in crisis. It was the owner of VS Code, TypeScript, GitHub and npm. At the same time, Bun, a JavaScript runtime built by a team that fits in a meeting room, keeps shipping release after release. This post isn't about corporate gossip. The question is a different one: what do Microsoft and Bun, side by side, say about how you should work and pick your tools?

What Microsoft announced

A voluntary buyout is not the same as a mass layoff. The company doesn't fire anyone outright. It puts a package on the table and lets each person decide whether to take it. In practice, the effect is similar. Fewer people on the payroll, just with fewer bad headlines.

The scale is what stands out. A quarter of a company with more than 200,000 employees means tens of thousands of people getting the same offer. Not everyone will accept. But nobody offers this to that many people unless they really want to shrink.

The underlying reason is no secret to anyone following the industry. Big tech is pouring billions into data centers and AI. That money has to come from somewhere. And the bet is that a smaller team, with better tools, delivers the same or more.

Why Bun is part of this conversation

Bun is living proof of the thesis Microsoft is trying to buy with cuts.

Think about what it ships:

• a JavaScript and TypeScript runtime
• a package manager
• a bundler
• a test runner
• native APIs for SQLite, Postgres, S3 and an HTTP server

In the Node ecosystem, every item on that list is a separate project. Different maintainers, different config. In Bun, it's a single binary. And the people who built it were never a team of thousands. It was a small group led by Jarred Sumner, which at the end of 2025 was acquired by Anthropic precisely because that kind of leverage is worth gold.

Team size was never a delivery metric. Leverage is.

Microsoft has enough people to maintain ten products that do the same thing. Bun doesn't. So it was forced to be opinionated, to cut layers, to write in Zig with a brutal focus on performance. Constraint became strategy.

What changes in your project in practice

Let's leave the thesis and get to the code. A typical Node project from 2023 had a package.json like this:

{
  "scripts": {
    "dev": "tsx watch src/index.ts",
    "build": "tsup src/index.ts",
    "test": "vitest run"
  },
  "devDependencies": {
    "tsx": "^4.0.0",
    "tsup": "^8.0.0",
    "vitest": "^2.0.0",
    "typescript": "^5.0.0"
  }
}

Four dependencies just to run, bundle and test. Each one with its own maintainers, its own release cycle and its own open issues.

In Bun, the same workflow looks like this:

{
  "scripts": {
    "dev": "bun --watch src/index.ts",
    "build": "bun build src/index.ts --outdir dist --target bun",
    "test": "bun test"
  }
}

Less to update. Less node_modules. Less surface for a supply chain attack, which in 2026 is no longer a paranoid concern.

I'm not telling you to migrate everything tomorrow. I'm saying the question "how many tools do I need to do this?" has become more important than "what's the most popular tool?".

What about the risk of relying on a small team?

This is the honest objection, and it deserves an answer.

A small project has a low bus factor. If the main maintainer disappears, the project can die. That's real. Plenty of people turned their noses up at Bun for that reason, and they weren't wrong.

But the Microsoft news shows the other side. A big company is no guarantee either. When a big tech company offers a way out to a quarter of its staff, whole teams change hands. A product that had five dedicated people ends up with one, split across three other priorities. You won't hear about it on the official blog. You'll find out when the issue you opened goes six months without a reply.

I've seen this happen with big-company tools everyone thought would last forever. Remember Atom? It belonged to GitHub, which belonged to Microsoft. It was archived in 2022. The argument "it's from a big company, so it's safe" was never as strong as it looked.

The criteria I use today are simpler:

1. Does the project have an open license and code someone could fork?
2. Does it follow web standards (Fetch, Request, Response, Web Streams) or invent its own API?
3. If it died tomorrow, how much of my code would have to change?

Bun does well on item 2. A good chunk of what you write in it runs on Node, Deno or a Worker with little adaptation. That's the real insurance. The maintainer's company registration isn't.

The message for people who write code

There's a side of this news that's uncomfortable, and there's no point pretending otherwise. If Microsoft thinks it can run with far fewer people, other companies will copy it. Some will copy it without having the tools for it. The result is overloaded teams and worse products. But the direction is set.

The dev who does well in this scenario is the one who creates leverage. Not the one who types fastest. It's the one who:

• removes tools that don't need to exist
• automates what's repetitive, with or without AI
• understands the whole system, from the database to the front end, instead of just one layer
• can ship something alone when needed

Bun is a great example precisely because nobody there tried to be huge. They tried to be efficient. The difference seems small, but it changes everything when deciding what to build.

And a reminder is worth it. Productivity is no excuse for a company to cut people and dump the work of three onto one. Better tools freeing up time is one thing. A spreadsheet deciding you now do the job of the coworker who left is another. The first is progress. The second is just a cut with a nice name.

My take

Microsoft isn't wrong to bet that smaller teams can get more done. Bun proves it every day. The mistake would be thinking you just remove people and you're done. Bun didn't get fast because it had few people. It got fast because those few people chose very well what not to do.

For you, the practical message is similar. Look at your package.json today. Count how many tools are there just because "it's always been that way". You can probably cut a couple. And if you want to see how I've been applying this idea in real projects, take a look at my projects.

Microsoft offered voluntary buyouts to roughly a quarter of the company. And it's not in crisis.

Meanwhile, Bun keeps shipping release after release with a team that fits in a meeting room.

My takeaway: what drives delivery is leverage, not team size.

Being backed by a big company doesn't guarantee anything either. Atom belonged to GitHub and got archived all the same.

Now I keep asking myself: how many tools are in my package.json just because "it's always been that way"?

I wrote about it on my blog. If you want to talk it over, reach out.

#JavaScript #Bun #SoftwareDevelopment #Productivity #Technology