Enterprise web 3d prototype cost is almost never a technology problem. Every time we've seen a Unity WebGL project blow its budget or miss its deadline, the root cause was a scoping decision that nobody made explicitly — an assumption that carried over from a web-dev project, a performance requirement that only surfaced during QA, or an integration that turned out to be three integrations. This post is the postmortem we wish we'd written after the first project.
We're drawing primarily from two projects: NBK Virtugate, a gamified WebGL onboarding environment for the National Bank of Kuwait where employees explore a virtual bank and learn procedures through avatars, and RSA Road Safety, a 3D educational web platform adopted into the Irish national primary and secondary school curriculum. Both shipped. Both clients were satisfied. But both taught us things we now build into every scoping call.
Here are six mistakes — what we did, why it broke, and what we do now.
1. We Let the Client Define "Prototype" Without Pinning Down Fidelity
What we did: Early in our Unity WebGL work, we accepted "prototype" as a shared vocabulary without establishing what fidelity level it implied. The client heard "prototype" and pictured something close to the conference demo that had convinced their CTO. We heard "prototype" and scoped a proof-of-concept with placeholder art and no live integrations.
Why it broke: The gap between a $15,000 proof-of-concept and a $60,000 production-grade MVP is enormous — and it's almost entirely invisible until you're mid-sprint. A PoC proves that Unity WebGL can be embedded in an enterprise portal and maintain acceptable performance on target browsers. A prototype adds custom UX, branded environments, and basic analytics. A production MVP adds SSO, LMS integration, performance optimization for low-spec devices, and content update workflows. These are not incremental additions; each one is a distinct engineering workstream.
What we do now: Before any estimate leaves our hands, we run a fidelity calibration session. We show the client three reference builds at different price points and ask them to point at what they actually need. We also ask: will real employees use this on day one, or is this for a board demo? The answer changes the scope by a factor of two or three.
2. We Scoped Asset Fidelity Before Scoping the Loading Architecture
What we did: On an early WebGL engagement, we agreed on scene content and art direction before deciding whether assets would be bundled into the initial build or streamed on demand. The 3D environments looked great in Unity Editor. Then we tried to load them in a browser.
Why it broke: Unity WebGL builds that bundle all content upfront can easily exceed 50–100 MB uncompressed — and the browser has to download, decompress, and initialize all of it before the user sees anything. Even with Brotli compression configured correctly on the server (which requires sending Content-Encoding: br and Content-Type: application/wasm for WebAssembly files — something many enterprise web servers aren't configured to do by default), load times on corporate networks with content filtering can be punishing. Streaming assets via Unity Addressables solves this, but it introduces CORS policy requirements, manifest management, and the risk that code stripping removes types used only in bundles. We had to re-architect mid-project.
What we do now: Loading architecture is decided in week one, before a single asset is modeled. We ask: what is the maximum acceptable initial load time on the client's network? What is the lowest-spec device in the target user base? The answers determine whether we bundle, stream, or use a hybrid approach — and that decision shapes every subsequent art and engineering choice. It's the Unity WebGL equivalent of a 3D printing cost calculator: you have to account for all the overheads, not just the visible print time.
3. We Didn't Build a Low-Spec Test Environment Early Enough
What we did: For RSA Road Safety, we knew the platform had to run on school computers across Ireland — a heterogeneous mix of hardware that included machines several years old. We built and profiled on development workstations, then tested on low-spec hardware late in the QA cycle.
Why it broke: WebGL performance doesn't degrade gracefully by default. Patterns that are acceptable on a modern GPU — complex transparent shaders, objects with MeshColliders, high draw call counts — can cause significant frame-rate drops on integrated graphics. Memory pressure compounds this: browsers on older machines may have tighter tab memory limits, and if the Unity heap allocation exceeds what the device can provide, the build fails to load entirely. Finding this late meant rework on shaders, mesh complexity, and texture atlasing that should have been baked into the original art direction.
What we do now: We assemble a low-spec test machine that approximates the worst-case device in the client's target population before we begin production. We profile against it at every milestone, not just at the end. For enterprise deployments, we also establish a minimum spec in the project brief — and if the client can't confirm their hardware baseline, we build in a grace period to gather that information before committing to performance targets.
4. We Underestimated the Engineering Cost of Portal Embedding
What we did: On NBK Virtugate, the WebGL experience needed to live inside an existing enterprise portal with SSO and access controls. We scoped the Unity build thoroughly. We did not scope the embedding work with the same rigor.
Why it broke: Embedding a Unity WebGL canvas inside a React or Angular enterprise portal is not a matter of dropping an <iframe> into a page. Passing authenticated user context into the WebGL build requires a communication layer between the JavaScript host page and the Unity runtime. CORS policies mean that any API calls the Unity build makes to back-end services must either originate from the same domain or be explicitly permitted by the server — and enterprise IT teams often have strict content security policies that block cross-origin requests by default. Coordinating with the client's IT security team added weeks we hadn't budgeted for.
What we do now: Portal embedding is a first-class workstream in every enterprise WebGL estimate. We ask for a technical contact on the client's IT or platform team in week one, and we run a one-day technical spike to confirm that the target portal can host a Unity WebGL canvas, serve the required HTTP headers, and permit the API calls the experience needs. This spike is billed separately and explicitly — it's not absorbed into the prototype budget.
5. We Treated Analytics as a Post-Launch Addition
What we did: On an early enterprise WebGL project, the client asked for usage analytics — which modules employees completed, how long they spent in each area, where they dropped off. We said yes and assumed we'd wire it up after the core experience was built.
Why it broke: Retrofitting analytics into a Unity WebGL build is significantly more expensive than designing for it from the start. LMS integration via xAPI (Tin Can) requires a data layer that touches nearly every interaction in the experience. If the state machine, scene transitions, and user flow weren't designed with instrumentation in mind, adding it later means revisiting architecture rather than adding a few event hooks. On one project, the analytics integration took longer than the original scene build.
What we do now: We ask about reporting requirements in the first scoping session, before any architecture decisions are made. If the client needs xAPI, SCORM, or custom analytics, that requirement shapes the interaction model from day one. It's a cost driver that sits completely outside the visible 3D content — which is exactly the point. Enterprise web 3d prototype cost is determined by decisions like this, not by the number of polygons in the environment.
6. We Gave a Number Before the Integration Questions Were Answered
What we did: Early on, we gave ballpark estimates in initial discovery calls — before we knew the client's portal technology, their device baseline, their analytics requirements, or whether the experience needed to stream assets or bundle them. We thought we were being helpful. We were being imprecise.
Why it broke: A Unity WebGL estimate that doesn't account for embedding complexity, performance floor, loading architecture, and integration requirements is not an estimate — it's a guess with a dollar sign in front of it. When the real scope emerged, the number changed. Clients who had anchored on the early figure experienced the revision as scope creep, even when it wasn't. Trust eroded. Timelines compressed.
What we do now: We don't give a number until we've answered five questions: (1) What portal or system will this live inside? (2) What is the lowest-spec device in the target user base? (3) Does the experience need to stream assets or can it bundle them? (4) What analytics or LMS integration is required? (5) Will this be a proof-of-concept, a prototype, or a production MVP? These questions are not bureaucracy — they are the difference between an accurate estimate and a conversation that ends badly. Enterprise web 3d prototype cost is almost entirely a scoping problem. The teams that get accurate numbers are the ones who resolve these questions before asking for a figure.
Related Reading
- Unity WebGL Development — VVS Service Hub
- NBK Virtugate — Gamified WebGL Onboarding for the National Bank of Kuwait
- RSA Road Safety — 3D Educational Web Platform for the Irish School Curriculum
The Do-Not List: Enterprise Web 3D Prototype Cost Edition
Print this. Put it on the wall before your next scoping call.
Do not:
- Give a budget estimate before the client confirms their portal technology and SSO requirements
- Scope asset fidelity before deciding on loading architecture (bundle vs. stream)
- Assume "prototype" means the same thing to both parties — pin down fidelity explicitly
- Skip low-spec hardware testing until QA — build the test environment in week one
- Treat analytics and LMS integration as post-launch additions — they reshape the architecture
- Accept "we'll figure out the integration later" — later always costs more than now
- Conflate a proof-of-concept ($15K range) with a production MVP ($60K+ range)
- Ignore HTTP header configuration — Brotli and WebAssembly streaming require correct
Content-EncodingandContent-Typeheaders on the server - Forget that enterprise web 3d prototype cost includes ongoing hosting, maintenance, and integration upkeep — not just the initial build
- Let the client's web-dev mental model set the budget ceiling without challenging it
If you're scoping a Unity WebGL project and want to avoid the mistakes above, talk to us before you write the brief. We'll run the five questions with you in a single call and give you a scoping framework you can take back to your stakeholders — whether or not you work with us.