Three.js Consulting

Hire a builder when the work is clear and you need hands. Hire advice when the expensive decision has not been made yet, or when it was made wrongly and nobody has worked out which one it was.

The pattern that costs the most money is a team that is good at web development, new to real-time 3D, and three months into an approach that cannot reach the frame rate the design assumes. Nothing is obviously broken. Every individual decision looked reasonable. The cost only becomes visible when the deadline arrives and the phone build is at eleven frames per second.

That situation is diagnosable in days, not weeks, because the causes are a short list: too many draw calls, textures that were never compressed, a lighting setup that recomputes every frame, materials that force a shader recompile, or a scene graph that was designed for a file format rather than for rendering.

A review before the first line of production code is the highest-leverage thing on this page. It covers the questions that are expensive to reverse:

Which renderer, given who your visitors actually are. WebGPU is genuinely better and is not available to everyone; the honest answer depends on your analytics, not on a blog post.

Whether the design in Figma is renderable at the frame rate and file size the project needs, and if not, precisely which parts have to change. This conversation is much easier before the design is signed off.

What the asset pipeline has to look like: where models come from, who prepares them, what they are allowed to weigh, and what happens when marketing sends forty new products.

How the 3D degrades. Not whether — how. Every project needs an answer for the visitor whose GPU is blocked, whose connection is slow, or who is on a device that will not run the scene at all.

You get a written document with the recommendation, the reasoning, and the trade-offs that were rejected and why. It is meant to be forwarded to the people who did not attend the call.

The site is live or nearly live, and it stutters. Usually the request is for someone to "optimize it", which is not a task until the actual cause is found.

The work starts with measurement on real hardware rather than a desktop with a discrete GPU: frame timing, draw call counts, texture memory, shader compile stalls, and what the main thread is doing while the user waits. That produces a ranked list of what is actually costing frames, which frequently disagrees with what the team assumed.

Then the fixes, in the order that recovers the most for the least work. Often the top item is one texture that nobody compressed, or a post-processing pass that costs more than every model in the scene combined.

What this is not: a promise that any scene can hit sixty frames per second on any device. Sometimes the honest finding is that the design has to change. You will hear that early rather than after another month of tuning.

A quote arrived and you cannot tell whether it is reasonable. Or you have to produce an estimate yourself and 3D is the part nobody on the team has done before.

This is a short engagement: read the brief, ask the questions the brief does not answer, and come back with what the work actually involves, where the risk sits, and which line items are underestimated. Variant counts and asset preparation are underestimated more than anything else, and they are usually the largest hidden cost.

Agencies use this before pitching, so the number they put in front of a client is one they can deliver at. That work can also run under your brand, which is what the white-label pages cover.

Some engagements are ongoing rather than a single deliverable: a recurring review of pull requests that touch the 3D layer, pairing sessions when the team hits something unfamiliar, or being reachable while an internal team ships their first WebGL feature.

The goal is that you stop needing me. A team that understands why the draw call count matters does not need a consultant to tell them again next quarter.

If your team wants to learn this properly rather than by osmosis, the interactive courses cover TSL, shaders and WebGL integration with live code, and the guides are written to be read by developers who are new to 3D but not to programming.