Taking Several Browser 3D Showroom Jobs a Year: Subcontract Each Time, or Build Up Your Own Set?
build vs outsource a 3D showroomshowroom design studio online versionbrowser 3D outsourcing costvirtual showroom system selection3D display option comparisonself-hosted 3D showroomshowroom model library reusemanaging multiple showroomsGLB importthree.js3D virtual world base layersource-available
Anyone on this path hits a moment: you look back through your project records and find you did four showrooms last year, three more by August this year, and three of them had much the same form — one space, a set of exhibits, one link to send out. And the online-version part was subcontracted every single time, paying the same capability fee on each job.
That is the moment to do a second calculation: which is actually cheaper — subcontracting each time, or keeping a set of your own.
A note on who we are: Genesis (创世Genesis ／ 创世虚拟世界CRM系统) is a browser 3D base layer you deploy on your own server. We do not take on showroom building projects or implementation work. This article is a calculation for the party taking the job, not a pitch.
Licence, stated up front: the source is available (source-available), running it locally costs nothing; going online, commercial use or federation requires a subscription license. The binding terms live in the repository LICENSE / EULA.
Three things this article covers
- Why the criterion is not "which is cheaper" but three other things
- Three job frequencies and what each should choose
- If you do build up a set, what you are actually accumulating — and it is not code
1. The criterion is not "which is cheaper"
Avoid this trap first: building your own and subcontracting are not two prices for the same thing; they are two cost structures.
The cost of subcontracting is per occurrence and predictable: one quote, one delivery. The advantage is cleanliness — no staff to carry, nothing to maintain, no 2 a.m. call about a site that will not open.
The cost of building your own is paid once up front, then only in increments: the first time in (deployment, learning the interface, assembling the models and space skeletons), after which each project is largely a change of content. But it comes with a precondition: you need enough repetitions to spread that first time across.
So the real criteria are three things:
| Criterion | Why it is the criterion |
|---|---|
| How many jobs a year | Decides whether the "first time" can be spread |
| How many edits each project takes after launch | Decides whether the increment is "small" or "not that small after all" |
| Who handles it when something breaks | Decides whether you bought a result or a capability |
The third is the one people skip. Subcontracting effectively buys a transfer of responsibility — when the site will not open, you call them. Building your own means that call comes to you, or to someone on your team. If there is nobody to take that call, the first two can be calculated beautifully and still not hold.
2. Three frequencies, three choices
| Jobs a year (same form) | Recommendation | Reason |
|---|---|---|
| One, or fewer | Subcontract each time | The fixed investment cannot be spread; carrying a capability for a single display is waste |
| Two or three | Hybrid: subcontract the heavy ones, deliver the standardised ones yourself | Accumulate the repeating part, leave the part that is different every time outside |
| Three or more, similar in form | Keep a set of your own | The repetition rate is high enough to spread the first investment over every later job |
The middle band deserves a note, because it is easy to handle wrongly. People in this band usually subcontract everything — paying again for the same thing each time, and because every delivery has a different form, what the client receives is stylistically inconsistent and you accumulate nothing.
The right handling is partitioning: keep subcontracting the part that is different every time (creative expression, unusual interaction, non-standard forms), and deliver the part that is the same every time (one space, a set of exhibits, one link) yourself. The allocation rule is simple — whatever repeats is worth accumulating.
Above: the model library of the in-browser 3D editor. Its job here is to make one thing concrete: what the asset you accumulate actually looks like. The library on the left holds 115 uploaded models, the scene viewport is in the middle, and the object list and properties panel are on the right. A client's machines, an industry's common exhibits — once they are in the library, the next project can reference them directly instead of importing again.
3. What you accumulate is not code — it is four things
This is the point most people get wrong. What you build up is not code — the code is the part someone else wrote. What you accumulate is the part you will use again:
| What to accumulate | What it is concretely | When it starts paying back |
|---|---|---|
| Model library | The models that recur for this client or this industry, consistently named, consistently formatted (prefer GLB / GLTF), size already handled | The second project |
| Space skeletons | A few common circulations, initial camera views, lighting and atmosphere — change the fit-out, not the structure | The second project of the same form |
| Delivery script | What to ask before taking the job, how to write the boundary into the contract, how edits are accounted | Immediately |
| Acceptance checklist | One open per device, first-screen time, order of magnitude of model size, the edit procedure | On the first handover |
The fourth is the least work and pays back soonest. A written acceptance checklist means you do not rethink "what should I check" before every handover, and gives you something to point at when the client raises an objection.
The second is the most valuable. What clients read as "consistent style" is usually not that your images look alike, but that the space skeletons come from one set.
4. Four columns to calculate
Put the two approaches on one table:
| Subcontract each time | Keep a set of your own | |
|---|---|---|
| The first time | The quote includes their capability fee | One investment (deployment, learning the interface, assembling skeletons) |
| From the second time on | The capability fee is paid again every time | Only the content increment |
| Edits | Through their process and schedule | You do it |
| Something breaks | Call them | Locate it yourself (someone still has to be able to) |
| Capability accumulation | Accumulates with them | Accumulates with you |
⚠️ No numbers appear in this table on purpose. We do not know your project price and have no citable time figures; inventing "it pays back in three jobs" would not help you. What you should do is fill in your own quote and your own actual frequency — by the second row, the conclusion usually appears on its own.
5. An optional layer: AI explanation
A frequently requested add-on to the online version is explanation. That layer can be added now, but set the boundary first.
What it is: give it a domain and a key and an external AI can walk into the world you deployed as a humanoid character — it has coordinates, can move, is seen by real people, and can talk and lead the way. The server sends structured JSON only; the picture is rendered by the visitor's browser.
What it is not:
- It cannot see the picture. It receives structured spatial perception data, similar to radar; it does not know what the models look like or what the materials are.
- It does not host a knowledge base. Exhibit specifications and company material must come from you. What it says depends on what you gave it.
- It does not do speech recognition or synthesis. The voice leg is not processed on the server.
- No teleporting, no touching assets. It can move, turn, follow, jump, speak and interact; it cannot change the position of anything in the scene.
- No claim of autonomy. It is executing the logic you connected.
Above: the world in a phone browser. It is here because of the "cost of one edit" row — visitors mostly arrive on a phone, and confirming every device after each edit belongs on the acceptance checklist as a fixed step.
6. Where this direction is the wrong fit
- One job a year. Subcontract each time, no hesitation. Carrying a capability for one display is pure outlay.
- You want a full turnkey arrangement. That is finding a service provider, not building your own. The two have different quoting and different responsibility splits; do not negotiate them as one.
- Nobody on the team wants to touch the technical side and you do not intend to hire. Then "who do I call when it breaks" does not hold, and the earlier arithmetic is empty.
- You are only trying to save money. Building your own is not a saving path; it converts cash paid out per job into one investment plus your own time. If time is short, the arithmetic runs the other way.
7. Limits and what we have not measured
- We do not take on showroom building projects or implementation work. This is an arithmetic method, not a service description.
- This base layer is not capacity. It will not take jobs for you, design for you, or maintain itself for you — somebody still has to handle operations, and the server, domain, backups and renewals are all on your side.
- No client case is cited here. The B2B paid path is still being validated, so nothing like "we have served company X" appears.
- Phone frame rates and battery use have not been fully measured. The screenshots show that it opens and can be walked around; actual performance must be measured on your target devices.
- Planned, not shipped: AI-assembled worlds, an Agent store, Agent interoperability, federated cross-world AI.
- Screenshots show the build as of writing; the interface evolves with versions.
8. Common questions
How do I tell which band I am in?
Count how many online-version requests with a similar form you had in the past twelve months. Count only the similar ones; forms that differ every time do not count — those should be subcontracted anyway.
For projects I already subcontracted, can I get the models back and reuse them?
It depends how the contract was written. This is exactly what to confirm at the contract stage: whether source files and data structures come to you on handover. For anything already signed, check what you hold and note it as a lesson for the next project.
After building up a set, can I still subcontract?
Yes, and you should. Keep subcontracting the heavy projects and the unusual forms; your own set handles the standardised part. The two run in parallel without conflict.
How long does this take to learn?
Depends which layer you use. For just deployment, layout and day-to-day edits, what you learn is an interface, not programming. We have no citable time figures; the way to assess it is to have the most suitable person on your team actually try it once.
Will library content leak between clients?
It is separated by space and account. As for permission granularity, test it against the way you actually work before fixing the rules.
9. Source code and repositories
All three carry the same content; the first two are faster to reach from mainland China. The repositories include the deployment guide and a set of acceptance scripts you can run yourself.
- Gitee (faster from mainland China): https://gitee.com/miduoxinxijeji/miduo.git
- GitCode (mirror for mainland China): 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.
Put "paid per job" and "paid once then by increment" on the same table and the second row usually gives the answer. Genesis (创世Genesis ／ 创世虚拟世界CRM系统) is a browser 3D base layer you deploy on your own server — if you decide to build up a set, it provides the model library, spaces, multi-device and networking layers, and the design stays in your hands.
About the name: the product referred to here as Genesis (创世Genesis) is the same self-hosted 3D virtual world product as 创世虚拟世界CRM系统. If searching for "创世Genesis" does not find us, search for "创世虚拟世界CRM" instead.