A scoping conversation does two things at the same time. It tells the developer what the project is. And it tells the buyer whether the developer is worth hiring. Most senior buyers — the CTOs, VPs of Engineering, technical founders, and engineering managers who hire independent contractors — already know this. The first call isn't really about the project. It's the interview.

I've been on both sides of these calls. Hiring contractors when I ran a studio. Being the contractor on calls now. The pattern that separates senior independent threejs developers from less experienced freelancers shows up in the first thirty minutes — in what they ask, what they don't ask, and what they push back on.

This article is the discovery process I run when a project lands in my inbox. It's also implicitly an answer to the question every engineering manager is asking on these calls: does this person actually know what they're doing?

Why scoping is for the buyer, not the developer

The narrative around scoping is that it's how the developer protects themselves from underquoting. That's true, but it's the small half. The larger half is that scoping is how the buyer avoids hiring someone who'll deliver the wrong thing.

A developer who quotes immediately, without scoping, has either misread the project or doesn't know what they don't know. Either way, the project they deliver is unlikely to match what the buyer needed. The buyer pays once, then pays again to fix it. The cost of inadequate scoping is borne by the buyer, not the developer.

A developer who scopes carefully is signaling something specific: they've shipped enough projects to know which questions matter. They've made enough mistakes to ask about the things that always go wrong. They're treating your project like a real engineering problem, not a freelance gig.

For an engineering manager hiring an independent 3D developer for the first time, the questions a senior contractor asks are a free preview of how they'd actually run the project. Listening for those questions is the most reliable interview signal you have.

The eight questions I work through

Here's what I want answered before I quote anything. Not all of these need full answers on the first call — some I'll come back to in writing. But I'll have asked all of them by the time I send a proposal.

1. What problem is this 3D feature actually solving?

The feature description is rarely the answer. A "product configurator" might be solving a customer-experience problem, an SKU-management problem, a marketing-conversion problem, or an in-store sales-aid problem. Each implies different priorities — different fidelity, different UX patterns, different success metrics. Until I know which problem the configurator is solving, I don't know what to optimize for.

The most senior buyers anticipate this question and lead with it. The least senior buyers describe the feature in detail and get surprised when I ask why.

2. Who is the user, and on what device?

A scene that runs at sixty frames on a developer's laptop tells me almost nothing about a project that needs to ship to mobile. I want to know the device share — desktop versus mobile, iOS versus Android, broadband versus cellular — before I commit to any framework or asset strategy.

This is where mobile WebGL development service engagements separate cleanly from desktop-targeted ones. The constraints aren't comparable. A senior developer asks about device share before scoping. A junior one builds and tests on whatever's on their desk.

3. Who maintains this in two years?

If the answer is "you" — meaning me, the contractor — the architecture should be one I can return to and extend. If the answer is "the in-house team," the architecture has to be one they can credibly own. The framework choice, the code patterns, the documentation depth all change based on this answer.

A 3D website development project where the in-house team will inherit the code is not the same project as one where they won't. The handover is part of the deliverable, and it has to be scoped.

4. What's the integration boundary?

For a project embedded in an existing site: where exactly does the 3D module sit? What's the host stack — React, Vue, WordPress, Webflow, custom? What's the design system? How does the module respond to the rest of the page? Twenty minutes of integration discovery prevents two weeks of integration rework. This question alone is often where I learn whether the project is a 4-week build or a 10-week build.

5. Who's producing the 3D assets?

A configurator with twenty product variants and four materials is a small project if the assets exist already. It's a much bigger project if a 3D modeler hasn't been engaged yet. The asset pipeline — Blender to GLB, texture compression, optimization passes — is often more work than the scene code itself. I need to know who's producing the assets and on what timeline before I can quote a project end date.

For training simulator development or educational game developer projects with dozens of unique scenes, the asset production schedule is usually the long pole. The scene code is fast. The asset production isn't.

6. What does success look like?

Not "what does the feature do" — what does it measurably do? More qualified leads? Higher conversion on the configurator page? Better completion rates on the training module? Lower customer service tickets about product specs?

The success metric tells me what to optimize. A project optimized for completion rates makes different decisions than one optimized for time-on-page. A senior buyer either has a clear answer here or appreciates the question because they've been meaning to nail it down.

7. What's the timeline, and what's flexible?

I ask both because the answers are usually different. The desired launch date is one thing. The actual non-negotiable date — tied to a trade show, a product release, a quarterly campaign — is the real constraint. Knowing which is which tells me where to make trade-offs if the project starts running long.

A timeline with no flexibility means I scope smaller. A timeline with flex means I can scope the right project even if it takes a week longer than the original ask.

8. What's the team I'd be working with?

For an embedded 3D specialist engagement, I want to know who I'd be reporting to, who I'd be syncing with daily, and whether anyone on the team has prior 3D experience. This isn't gatekeeping — it's the difference between an engagement where I can run independently and one where I need to budget significant time for handholding. Both are fine. They're priced differently.

What I push back on, gently

There are a few patterns that come up in scoping calls that I'll flag if I see them:

A spec written before the user research. When the brief has decided on every UX detail before the team has thought about what the user actually does with the feature, the project usually needs to be rescoped. The senior call is to push for a discovery week before committing to a build plan.

A timeline tied to a marketing date with no design buffer. Marketing dates are real, but a 3D feature is a designed object. Reserving zero time for design iteration means shipping the first thing that works rather than the right thing. I'll flag this and propose a phased approach.

A team that wants 3D because their competitor has 3D. This isn't always wrong. Sometimes "match the competitor" is a legitimate business goal. But often it's a sign that the feature hasn't been thought through, and the project will get cancelled three weeks in when leadership realizes they don't actually know what they want it to do. I ask about the underlying motivation early.

A request to "just build a prototype" with no clarity on what success looks like for the prototype. Prototypes that don't have an explicit decision they're informing tend to become production code by default. I'll insist on naming the decision the prototype is meant to support before quoting it.

The proposal that follows

Scoping is a conversation. The proposal is the artifact. Both should be sized to the project — but neither should be skipped.

After a good discovery call, I send a written proposal that captures:

The buyer should be able to read the proposal in ten minutes and know what they're buying. A proposal that requires interpretation is a proposal that's hiding something.

This is the moment when many independent 3D developer engagements either start strong or never start. A clear proposal makes the buyer's hiring decision easy. An unclear one — even for the same work at the same price — usually loses to whoever wrote a clearer one.

What this looks like from the buyer side

If you're hiring a contractor for a 3D project right now, the questions above are a checklist for evaluating who you're talking to. Did the contractor ask all of them, or just the easy ones? Did they push back on anything in your brief, or just nod and quote?

A contractor who pushes back early is a contractor who'll push back when the project starts going sideways — which is when you actually need them to. A contractor who never pushes back is a contractor who'll deliver exactly what you asked for, including any flaws in the brief.

If you've made it this far in the article, you've also probably realized that this is what a senior independent threejs developer for hire actually looks like in conversation. The scoping process is the work. The build is the easy part once the scoping is right.

If you have a 3D project that needs scoping, the discovery call is what we do first. The eight questions above are roughly what I'd ask. The proposal is what comes next.