After enough projects, the patterns repeat. The same problems show up in new disguises. The same mistakes resurface, and the same handful of decisions decide which projects ship and which don't.

This article is the senior-developer retrospective — the patterns I've learned from years of shipping interactive 3D web features to production. Most of them are obvious in hindsight and weren't obvious in real-time. That's the value of this kind of post: a buyer or technical hiring manager reading this can recognize, before scoping their first project, what someone who's shipped many of them has learned.

If you're hiring an independent 3D developer for a browser-based project right now, or evaluating one you've already engaged, the patterns below are roughly what a senior version of this work looks like in practice. The contractor who recognizes these patterns is the one who'll save your project from the failure modes most others walk into.

Lesson 1: The asset pipeline determines whether the project ships

A project's success or failure is decided more by the asset pipeline than by any other single factor — including the framework choice.

I've seen Unity projects ship cleanly because the asset pipeline was disciplined. I've seen Three.js projects fail because nobody owned compression, optimization, or LOD strategy. The framework gets the architecture credit; the asset pipeline gets the production credit.

For any project that takes mobile traffic seriously, the pipeline must be set up in week one. KTX2 textures, Draco geometry compression, mobile LOD, asset budget tracking. Trying to retrofit these in week eight after performance complaints come in is a project-threatening rework.

The harder lesson: most teams new to browser 3D underestimate this by 3-5x. They budget for the framework choice and the scene logic; they don't budget for the pipeline. And by the time they realize the pipeline is the work, they're behind schedule.

Lesson 2: The desktop demo lies about mobile reality

Whatever the desktop demo looks like, mobile reality will be 10x harder than the team expects. This isn't pessimism — it's the structural difference between desktop GPUs and mobile GPUs, magnified by thermal throttling, by network constraints, by mobile-specific UX requirements.

The desktop developer's experience of "smooth, beautiful, ready-to-ship" tells you almost nothing about whether the project will work for the 60% of the audience on phones. The teams I've worked with who took this seriously from week one shipped successfully. The teams who said "we'll optimize for mobile later" usually shipped late, ugly, or not at all.

The senior call: mobile is a primary requirement, not a polish concern. Test on real mid-range devices throughout development. The first time you discover a fatal mobile issue should be in week two, not in week eight when launch is committed.

Lesson 3: The integration boundary is harder than the scene code

For projects embedded in existing sites — most browser 3D work falls in this category — the boundary between the 3D module and the host application is the hardest part of the engineering.

The scene itself, in the abstract, is solvable. The integration with React or Vue or WordPress, with the host site's design system, with the build pipeline, with the existing analytics stack, with the lazy-loading strategy that keeps Core Web Vitals from collapsing — that's where the time goes.

I've come to budget integration time at 30-40% of total project time on serious embed projects. A team that budgets 10% for integration ships late. The integration discovery question I cover in scoping is the most important non-obvious thing to ask early.

Lesson 4: Shaders are how senior developers separate from mid-level ones

The shader is where 3D web development gets non-obvious. Most shipping 3D projects have at least one custom shader — a material that needs a specific look the standard shaders can't produce, a post-process effect that defines the visual style, a vertex deformation for animation, a shader-based particle system.

Mid-level developers struggle with shaders. The mathematics, the GPU performance characteristics, the debugging without breakpoints — it's a different discipline than scene code. A senior 3D developer is comfortable in GLSL; a mid-level one is comfortable assembling pre-built shaders.

This shows up in client conversations. A senior developer describes the visual look they'll achieve and how. A mid-level one describes the standard materials they'll use and hopes those will be enough. For a project where the visual style is part of the value, the difference matters.

Lesson 5: The buyer's success metric should be visible to the developer

Most 3D web projects exist to move some metric — conversion, engagement, completion, time-on-page, AOV, qualified leads. The developer should know which metric the project is being measured against, and it should influence build decisions throughout.

The most common failure mode: the project is scoped without explicit success metrics, the developer optimizes for visual quality and performance, and the deliverable looks great while underperforming on the actual business metric. A configurator scoped for AOV uplift gets built differently than one scoped for engagement time. A training simulator scoped for completion rate gets built differently than one scoped for visual fidelity.

Hardest version of this lesson: when the buyer doesn't know their own success metric, the developer's job is to surface that gap, not to assume. Building blind to the metric usually produces a deliverable that misses it.

Lesson 6: Backend and content logic eat more time than expected

For projects where the 3D feature is more than a single static scene — configurators with pricing logic, training simulators with progress tracking, educational games with content management, e-commerce embeds with SKU integration — the backend and content layer is often the long pole.

The 3D rendering is solved. Three.js, Babylon, PlayCanvas all do the rendering. What's not solved off the shelf:

These are not small efforts. I budget more time for these than for the rendering on most projects.

Lesson 7: Documentation handover is the deliverable

For embedded engagements, the project deliverable isn't just the code — it's the in-house team's ability to maintain and extend the code after the contractor leaves.

A 3D project handed over without documentation, knowledge transfer, and architectural notes is a 3D project that becomes unmaintainable within six months. The team that built it has moved on; the team that inherited it doesn't know which of the abstractions are load-bearing.

I treat the handover as a phase of the project, with explicit time budgeted: a documentation pass, a knowledge transfer session with the maintaining team, sometimes a retainer for the first month post-launch to answer questions.

The teams that benefit most from this: those that brought in the contractor specifically to learn the patterns alongside building the feature. Those engagements produce both a shipped feature and a lasting team capability.

Lesson 8: The first prototype is rarely the final architecture

For any project that's the team's first browser-based 3D feature, the architecture decisions made in the first two weeks are usually wrong.

This isn't a developer error. It's structural — the team doesn't yet know what they don't know about their specific project. The framework choice, the asset pipeline, the integration boundary, the state management approach — all of these become clearer after two weeks of actual building. A reasonable refactor in week three is normal and healthy. Trying to get the architecture right on day one before learning anything specific to the project usually produces over-engineering and rigid abstractions.

The pattern I follow: scope the first two weeks as "learn the project, build a working spike, identify the architecture gaps, then refactor." It feels slower but produces better outcomes than committing to architecture in week one and grinding through whatever it gets wrong.

Lesson 9: The team I'm joining matters as much as the brief

A great engineering team makes a hard project easy. A mediocre one makes an easy project hard. I've stopped pretending this isn't true.

The signals I read for in the discovery process: how does the team make decisions? Is there a clear technical lead? Does the team commit to specifications, or does the brief keep moving? How responsive are they on Slack? Do they have time to participate in the engagement, or am I being hired as a substitute for engagement they don't have time for?

The engagements that go best are with teams that are engaged, responsive, and decisive — even if they have no prior 3D experience. The ones that go badly are with teams that want to outsource the problem entirely. Identifying which team I'm joining before quoting is one of the senior-developer skills that's harder to articulate than to feel.

Lesson 10: The work is the scoping, not the building

The valuable thing a senior 3D developer does isn't writing scene code. It's making the right calls about what to build before any code is written.

The scene code, by the time the project gets there, is largely a mechanical translation of decisions already made. The hard work is upstream: the framework choice, the asset pipeline, the integration boundary, the success metric, the team fit, the timeline trade-offs, the things to descope when the project starts running long.

Junior developers spend most of their time on the building. Senior developers spend most of their time on the scoping. The work that's hardest to copy is the senior judgment about which questions to ask and which trade-offs to make.

This is the case for hiring a senior independent contractor over a cheaper junior alternative. The same scene code can be written by either. The decisions about which scene to write — and which not to — are where senior experience pays back.

What this means for hiring

If you're an engineering manager or technical founder hiring an independent 3D developer for a browser-based project right now, the patterns above are roughly what you should expect from a senior version of this work.

Listen for the lessons in the discovery call. A contractor who has internalized them will mention them naturally — they'll ask about mobile share, about the integration boundary, about the success metric, about the team they'd be joining. They'll have opinions about which mistakes are worth avoiding because they've made them.

A contractor who hasn't internalized them will sound enthusiastic about the building and quiet about everything upstream. Both can ship a 3D feature. Only one will ship the right 3D feature for your project.

If you have a 3D project that's about to start, or that's started and isn't going well, the patterns above are roughly the diagnostic. Most projects that struggle are missing one or two of them — usually the asset pipeline or the success metric. Identifying which two saves the project; ignoring them costs the engagement.

The discovery call is where we'd figure out which lessons apply to your specific project. After enough of these, the diagnostic gets fast — usually thirty minutes is enough to know what the project actually is and what it'll take to ship.