Just a few days ago, I was sitting in a meeting with a client, walking them through the cost structure of Unity Industry. I explained it clearly: if you build an app to sell externally, Unity takes a 4% revenue share. But if you're building an internal application - like a digital twin, a factory simulator, or a sales configurator - you're safe. You pay for your licenses, use it internally, and don't have to worry about extra fees.
And then, out of nowhere, Unity drops a new IDAO (internal deployment add on fee) policy. Published day and apply day on the same day!
Wow.
Enter the Internal Deployment Add-On (IDAO). My head is spinning.
Even if you aren't paying out of pocket yourself right now, watching another "Runtime Fee" style tragedy unfold in real time hurts. When you’ve invested years of your career mastering an engine, building an architecture around it, and pitching it to enterprise clients, sudden overnight policy shifts like this hit hard. It’s not just a financial burden for businesses - it is a massive mental burden for every technical lead and developer caught in the middle.
1. The Client Backtrack
As technical leads and agencies, our reputation relies on giving clients clear, predictable advice. How are we supposed to maintain client trust when the vendor changes the rules overnight? Yesterday, internal tools were free from deployment taxes. Today, if an internal app passes 100 active users, a client could be looking at an unexpected $7,500 to $75,000+ annual bill.
Having to go back to a client and say, "Remember what I told you last week? Unity just changed their mind," is an incredibly frustrating position to be put in.
2. Now I Have to Track Users? (The WebGL & MAU Tracking Mess - The operational headache)
Who is using how many users. Monthly active users. Internal MAUs. Sounds simple until you actually try to apply it.
WebGL user counts - how? A shared kiosk on a factory floor touched by 200 different workers a month - how does that count? Nobody explains it. There's no clear definition of what actually counts as a "user" in these deployments, and that ambiguity is exactly the kind of thing that turns into a surprise bill later.
3. The "Per-Application" Gray Area
And here's the one that really gets me: it's charged per application. Not per organization. Per app which is a relif (you can expect from unity to even do this per organization)
The policy states that the 100 MAU threshold applies per application. But what actually defines an "application" in real-world development?
So what happens if we create different copies of the same application? Is that allowed? Is that circumvention? Nobody says. You're left guessing whether you're being clever or whether you're setting yourself up for a very uncomfortable conversation with Unity's sales team down the line.
In enterprise dev, we constantly create variations of a base project. What if we build one core 3D configurator codebase and compile different branded copies for different internal branches or clients? Does Unity view that as one application under one project ID, or five separate applications each triggering their own MAU counters? The ambiguity is a minefield for software architects.
2. Published Yesterday. Applied From Yesterday.
Let that sink in. The article is dated August 3, 2026. The policy takes effect August 3, 2026. Same day. No warning, no consultation, but this time not applied to those who already have an app live on that same day. There is a grace period for people - but no one knows the details yet.
Yes, a grace period is given. So Unity can figure out what it wants to do next, during that period? You publish the cutoff and the policy on the exact same day, and then ask everyone else to sit and wait while you work out the fine print. That's not a grace period, that's a stalling tactic dressed up as generosity.
Just a support article that quietly rewrites the deal you thought you had.
5. The Real Cost Isn't only the Invoice
I'm not paying anyone right now. That's not the point.
The point is I have to sit here, wondering, calculating, second-guessing every internal tool I build from now on. Wondering if this quiet little support article is going to become next year's headline. Wondering if the platform I built my career on is going to keep doing this — announce first, explain later, walk back eventually, after enough people are angry enough for long enough.
That's not a pricing model. That's a tax on trust.
And trust, once it starts spinning like this, doesn't come back cheap.
The Bottom Line
Unity says they introduced this add-on to keep costs predictable and align pricing with value. But from the developer side, it feels like another layer of uncertainty pushed onto the people building on their platform.
We don't just need powerful engine tools; we need stability and predictability. When you spend years committing your technical career to an engine, you shouldn't have to wake up every few months wondering what fundamental business rule got rewritten overnight.
If you are running live enterprise apps on Unity today, check your deployment builds and make sure you register them before March 31, 2027 to claim your permanent exemption. But as for future projects? The mental math just got a whole lot more complicated.
.png)
0 Comments