Web 3D Virtual Scenes: Outsource or Build It Yourself — Seven Decision Points

Planning a web 3D virtual scene, the first move is not to search for "which company is good." It is to answer a prior question: should this be handed to someone else, or should you stand up something you can keep growing? Answer that wrong and every comparison afterwards is meaningless — because you would be comparing two different things.

Let me state plainly who is writing this: Genesis (a.k.a. the Genesis Virtual World CRM) is a source-available web 3D virtual scene base layer. It is not a virtual-scene building service. We do not take showroom projects, we do not send a team to build yours, we do not take "here is my idea, you make it" work. What this article can do is walk you through seven decision points if you are hesitating about outsourcing, and — if you decide to build — spell out which layers this base layer covers and what the measured numbers are.

Licensing terms first: the source is available (source-available); it is free to run locally; online, commercial, or federated use requires a subscription license. Exact terms live in the repo's LICENSE / EULA.

1. Decide whether to build, before comparing who builds well

There is a common misjudgment about web 3D virtual scenes: treating them as a deliverable you can outsource.

It is not one. It is closer to an asset you maintain long-term.

A deliverable is handed over like this: accept, pay, done. A long-lived 3D space keeps generating work after handover: swap an exhibit and you edit models; add a product line and you rearrange the layout; connect a product database and you write interfaces; someone reports a bug and you trace it; a model format changes and you migrate. The volume of that work usually exceeds the initial build itself.

This is not a case against outsourcing — outsourcing is often the better deal precisely for that follow-up work (section 3 says plainly when it is). The point is: if you have not first judged how long this thing lives, you have no judging criteria. Comparing vendors by "how good does the first screen look," or comparing products by "can I get the source," measures two different things with one ruler.

2. Seven decision points

Listed in judging order. The first four decide direction; the last three decide what kind of thing you need.

Point 1 · Is the content one-off, or does it stay up?

This is the most upstream question; the other six inherit from it.

The test is simple: will someone still be maintaining this in three months? If nobody will, let the vendor maintain it — that is how they make a living. If someone will, you have to decide where that capability lives, because whichever route you take, upkeep capability ends up on one specific team or person's desk.

Point 2 · How often will you need to change things?

The normal rhythm of exhibition design is: first draft → client asks for changes → more changes → final. The frequency and size of those changes decides the shape of the solution.

Things that change once and then freeze are fairly priced as outsourcing. Things that change repeatedly should not have their core logic locked inside someone else, because every change then becomes a cycle of communication, quoting, and scheduling.

One caution here: the cost of custom development is not in the first build, it is in every build after it. If a quote covers only "making it," ask what one change costs and how it is metered. Asking that question alone lifts the quality of the conversation immediately.

Point 3 · Can the data leave your building — or the intranet you must stay inside?

For many requirements this is not a technical preference but a hard constraint: equipment drawings, defense-related material, unpublished product parameters, a client's unapproved design.

Once such a constraint exists, the answer is basically determined: it must be self-hosted, on infrastructure you control. Cloud-hosted options drop out entirely here — and there is no "but we encrypt it" answer to this: encryption solves transmission and storage, not "which machine, controlled by whom, does it sit on."

A quick test: ask the vendor "where are my uploaded models stored, and can your staff see them." If the answer stalls, end the evaluation there.

Point 4 · Who visits, and how many of them?

Ten internal viewers and several thousand public visitors are different orders of engineering. Public scenes add a layer: phone share, weak networks, hostile input, bandwidth cost.

This one gets skipped often, yet it decides which layer your money belongs in. Optimizing first-screen load for ten people is waste; ignoring it for several thousand is a disaster.

Point 5 · Does it have to talk to existing business systems?

A showroom pulling from a product database; training pulling from assessment records; a configurator that places orders — the moment there is an integration, this is development work, not showcase work. Many showcase teams cannot do it.

One hidden cost to price carefully: once an integration is implemented by an outside team, you depend long-term on that team's API documentation and response speed. If the integration is core to your business, keeping that code on your side is the safer arrangement. This is not an argument against working with vendors; it is an argument for drawing the line: let them build "the part inside the world," and keep your business logic and data yourself.

Point 6 · Is there anyone on your side who can maintain it?

Self-hosting does not mean "done"; it means "someone is now responsible." This is a plain question, and it is the one that tends to get skipped during evaluation.

If the answer is "nobody," don't jump to "then how do we hire." Ask instead "does this really need to be self-built?" A self-hosted option requires at least one person who can read it, change it, and debug it. Count that person's cost and put it on the same table as the outsourcing quote.

Point 7 · Will this still be in use in three years?

This decides whether you are buying an asset. Assets justify self-investment; one-off content does not.

When the answer is unclear, use a middle path: ship a validation version that is good enough first, run it a while, and see whether it actually gets opened. Many requirements have nobody opening them by month three, and at that point you have saved the entire self-build route. This validation version does not need to be pretty — it needs to be enterable, walkable, and openable by real people.

3. When outsourcing is the right call

Section 7 needs its other half written out in full: in some situations outsourcing is right, and visibly so.

If you checked any row in that table, stop here — do not keep reading the self-build part. But if none of those conditions hold — long-lived content, frequent changes, a compliance constraint, an integration requirement, and someone available to maintain it — then self-build is probably right, and the reasons are in the next section.

4. Once you decide to build: which layers the base layer has to cover

The commonest way a self-build fails is not technical difficulty. It is spending effort at the wrong layer — burning weeks on work that the base layer should have absorbed.

These four layers are the dividing line between "runs without effort" and "actually runs":

None of these four layers is a business problem, and each one can eat weeks of schedule. They are also all "answer the question once" problems — so either buy them ready, or go through them yourself and then go through them again.

Measured values for these four layers in this base layer (all from acceptance scripts that ship with the repo and can be re-run against your own build):

This is a live shot of the in-browser editor: model library on the left (direct GLB/GLTF upload, VRM packaged with textures, OBJ with mtl), scene viewport in the middle, object list and properties panel on the right — this particular scene holds 373 objects, with position, rotation, scale, and animation all adjusted in the panel.

Worth noticing what the editor itself covers: section 5 explains why separating "placing" from "behaving" is what gives your workload a floor.

This is a live desktop-browser view. Stated plainly: this is an in-development test world with no visual polish — models and scene are in the state we debug with. It is here because it represents the real form more honestly than a retouched screenshot: what you assemble in the editor looks like this.

5. An optional layer: AI-guided tour

"Can someone do the narration?" is a question that comes up constantly in showroom scenarios. This layer is possible now, but the boundary matters more than the capability.

What it is: given a domain and a key, an external AI can walk into your deployed world as a humanoid character — it has coordinates, it moves, real visitors see it, it can speak and lead. The server sends structured JSON; the visitor's browser renders the picture.

This is a live phone-browser view: virtual joystick, voice, camera, and jump controls. Most showroom visitors arrive on a phone, so this layer's real weight is higher than you might assume.

What it is not — this part matters more than the part above:

• It cannot see the screen. What the AI receives is structured spatial data (something like radar), not video and not screenshots. It does not know what your models look like, does not know materials, does not know the text on your interface.
• It does not host a knowledge base. Your product parameters and business material must be supplied by you, through prompts or documents. What it says depends on what you give it — this is routinely misread as "it learned to introduce our company by itself," which is not what happens.
• No speech recognition or synthesis. The voice path does zero processing server-side; transcription belongs to your own AI client.
• It cannot teleport and cannot touch assets. Its actions are walking, turning, following, jumping, speaking, interacting — it cannot change the position of anything in the scene.
• No promise of autonomous consciousness. It is executing the logic you connected.

So the accurate framing: an AI guide suits "when someone is watching, the narration doesn't get tired." It does not suit "fully unattended automatic Q&A." The latter needs a separate body of content and rules work, which is a different job.

6. What to prepare

Once you have decided to build, line these up before you start:

1. A server you control. Self-hosting is this solution's stance; there is no hosted edition. Server spec, bandwidth, domain filing, and SSL are your work.
2. A database. This base layer uses PostgreSQL — installing, initializing, and creating accounts are steps you do.
3. One person who can read it. Back to point 6: this is a cost item, not a precondition, but it must be counted.
4. Content assets. Showroom models, exhibit information, narration material. Models you have; narration material is separate work — back to the previous section, what the AI says is what you supply.
5. One verifiable baseline. After deployment, run the acceptance scripts once to get baseline numbers, so every later change has something to compare against.

⚠️ There is deliberately no time estimate here. We have no citable deployment-time statistics, and inventing "one or two days to get it running" does not help you. Estimate the way that works: list items 1 and 2 above as tasks and cost them against your own team.

7. What does not fit

• You just need to show five product images and one simple animation. That does not need 3D. Images and video are the better tool; do not add complexity for the sake of the technology choice.
• You need a hosted page you can bring online at any time, without touching operations. Self-hosting means operations are yours.
• Your target is console-grade visuals and heavy physics simulation. This is a browser stack (Three.js), bounded by browser performance budgets — not a substitute for that class of engine.
• You want "one AI sentence generates a whole world." Generative world-building is on the roadmap, not implemented; do not evaluate it as an existing feature.

8. Boundaries and unmeasured items

Listed honestly:

• This article provides no virtual-scene building, consulting, or implementation service. It is a decision framework plus measured data for the self-build path.
• The paid B2B path is still being validated; there are no citable customer cases. This article gives no customer list and no outcome claims — only mechanisms and measured numbers.
• Mobile frame rate and power draw are not fully measured. The phone screenshot above proves "enterable and walkable"; take performance numbers from your own target devices.
• Roadmap items are unimplemented: AI-assembled worlds, agent store, agent interoperability, cross-world federated AI.
• Both screenshots are live captures at the version current when this was written; the UI evolves.

FAQ

Q: Outsource or build — one sentence?

A: Long-lived content + frequent changes + a data compliance constraint + integration with business systems + someone who can maintain it → build it. If any one of those fails, outsourcing is cheaper. Failing five of them means you are building maintenance capability for something nobody will maintain.

Q: We are a small company. Is self-hosting still for us?

A: Size is not the criterion; accountability is. The question is "who changes this in three years." If the answer is "nobody," the hidden cost exceeds the fee you saved. If one person (even part-time) can maintain it continuously, a small team is well served by building.

Q: What exactly is the hidden cost of self-hosting?

A: Three blocks: the time spent on pitfalls (performance, asset formats, multi-client adaptation — each step can eat weeks), the continuing upkeep, and the communication cost of every change. None of these appear on any quote, and all of them are real.

Q: Can we outsource version one, then bring it in-house later?

A: Possible — but the asset terms decide the migration cost: whether code, model source files, and data structures come over at handover. Settle that at contract stage, not at acceptance stage.

Q: How does this base layer relate to hiring a vendor?

A: Neither conflict nor substitute. It covers the four layers an outsourced showcase usually does not (rendering kernel, asset pipeline, performance and multi-client, real-time communication). You can use it as the self-build path, or as a base for a vendor you work with — but be clear that it is not a building service.

Source & Repositories

The three mirrors are identical; the first two are faster inside China. The repos include deployment docs and a set of acceptance scripts you can run yourself to see the measured numbers.

• Gitee (fastest in China): https://gitee.com/miduoxinxijeji/miduo.git
• GitCode (China mirror): https://gitcode.com/qq_35054471/virtual-world
• GitHub: https://github.com/miduo100/3d-virtual-world

About Genesis

Genesis is a self-hosted 3D virtual world system built on Three.js + WebGL, helping individuals and businesses build their own 3D spaces. Accessible directly from a browser, compatible with both PC and mobile, it supports multiplayer online, federated teleportation, a shop system, and Agent integration—where an AI can enter your world as an embodied character. Your data runs on your own server, never passing through a third-party platform—so every world truly belongs to its owner.

Still deciding whether to outsource? Genesis (a.k.a. the Genesis Virtual World CRM) is a web 3D virtual scene base layer that runs on your own server — it is not a building service; it covers the four layers that consume real schedule on the self-build path: rendering kernel, asset pipeline, performance and multi-client, and real-time communication. The source is available; run it locally free of charge; online, commercial, and federated use require a subscription license. Search "Genesis Virtual World CRM" to find the site with a walkable demo world.

About the name: Genesis in this article is the same self-hosted 3D virtual world product also called the Genesis Virtual World CRM. If "Genesis" does not find us, search "Genesis Virtual World CRM".