Why I Pay for My AI Tools Myself, Not Through Employers

Microsoft revoked enterprise Claude Code licenses for thousands of developers in a single procurement decision. One IT ticket, and the tool people had built their workflows around stopped working Monday morning.

My workflow didn't change.

Not because I use something different. Because I pay for it myself.

That sounds like a small thing. But it reflects how I think about every tool I rely on professionally. If it runs without me — it's production. And production I don't control is someone else's production.

What corporate licensing actually means

Microsoft did what large organizations always do with third-party tools: evaluated cost, didn't see a direct line to revenue, cut the line item. No malice — just procurement.

Developers who accessed Claude Code through corporate accounts got an email: access removed as of a date. Some of them had spent months building on top of that access — custom CLAUDE.md files, workflow integrations, prompt patterns tuned for their specific codebase.

None of that disappeared. It just became inaccessible.

Some people found a replacement in a day. Others lost a week of productivity. A few discovered they couldn't quite remember how they did certain things without AI assistance.

Not a tragedy. But a preventable vulnerability.

The dependency you didn't sign up for

When an employer or client hands you tool access, it sounds like convenience. No subscription to manage. License already covered. Just log in and work.

The hidden cost is control.

You don't manage the plan. You don't decide when — or whether — to upgrade. You don't know when IT will revisit the approved SaaS list next quarter. And you definitely won't be the first person they ask before they do.

The tool is part of your professional workflow. Not theirs.

I work with several clients at a time. If each one supplied "their" AI tool, I'd end up with three different environments behaving differently, updating on different schedules, disappearing at different moments. That's not a workflow. That's chaos dressed as convenience.

I've declined the offer to use a corporate Claude or Copilot account more than once. Not on principle — on engineering logic. I don't take on a production dependency I don't control. Same reason I keep approval gates even when I could remove them.

My rules: what I always pay for, what I'll take from a client

I split tools into two categories.

First: tools that shape my workflow. Claude Code, IDE, email, task manager. These live in my environment, plugged into my rhythm, carrying my customizations. I pay for these myself. Always. Not up for discussion.

Second: tools specific to a client project. Access to their Jira, their Confluence, their deploy pipeline. Logic flips: they pay, because it's their infrastructure. I use them, but I don't build them into my core setup. When the project ends, the access goes with it — and that's how it should be.

The rule is simple: if I'd take it to the next project, I pay. If it's only needed here, the client pays.

This protects both of us. I don't get locked into their systems. They don't fund my personal stack.

What it actually costs

I wrote a full breakdown of AI tooling costs in my studio in a separate post. Short version: around $150 per month for the full stack.

That's roughly one to two hours of billable work at my rate. Not a luxury purchase for tools that save me many times that.

But the dollar figure isn't really the point. The point is that I know what I'm paying for, when I'm paying for it, and what I'm getting. I decide when to upgrade. I decide when to switch. Nobody kills my Claude Code access on a Friday evening.

The hire vs freelance angle

In a salaried job this gets complicated. Employers often want to control tooling for legitimate reasons — security policies, IP ownership, licensing compliance. That's their right.

But there's a difference between "we have a corporate Copilot license you can use" and "you will only use tools we approve." It matters to understand which one is being offered before you take a job, not after.

I've heard variations of: "we have enterprise Claude, GitHub Copilot under our account, no need to pay for anything yourself." That sounds appealing. But the subtext is that your workflow will be shaped by their configuration — and reshaped again when they change vendors.

I'm not saying that's unacceptable. I'm saying it's worth knowing clearly, rather than treating it as a benefit.

For a studio like mine, tool autonomy isn't a preference. It's a design constraint.

Why this matters now

The Microsoft incident isn't unique. It's a pattern. Enterprise software budgets get reviewed. Tools get bundled, replaced, dropped. That will keep happening — more often as AI tooling matures and consolidates.

If your workflow depends on access that someone else controls, that's the real risk to track — not which model is fastest or which IDE has the best autocomplete.

Pay for what you actually rely on. Own the access.