What Drives the Cost of a 3D Product Website: Reading a Quote and Its Scope

The price spread between 3D product websites rarely comes from page count. It usually comes from three places: whether the models must be rebuilt, how deep the interaction goes, and how far phone support extends. Those three answers set the amount of work. The scope clauses in a quote decide whether that amount grows after signing, and that effect on the final bill is larger than the unit price's. This article covers why prices move and how to read a quote. It does not cover amounts.

The model side: files from a modeler are raw material

One misunderstanding that comes up when commissioning a 3D website is “the models already exist, so this part can be skipped.” A file delivered by an outside modeler is raw material, not a finished product. The model file that goes live must be reproducible from its source, and every change to it needs a stated reason. Without that, any visual defect first calls for work to tell whether the asset itself is broken or the processing for the live version is. That work does not disappear. It shows up late in the project.

Outsourced models often arrive with missing faces, duplicate exports, stray nodes, or edits made by an earlier party with no note left behind. At intake, causes are separated by elimination. Open the light and full versions side by side: a defect in both has nothing to do with the encoding. Display textures alone, then disable textures entirely, to rule textures out. View the back faces, and a see-through gap marks a geometry hole. Open the source file directly in the modeling software to rule out the in-house pipeline. Compare same-named parts across two colorways of the same product.

In one past case, a part in one colorway of an outsourced model was missing about 270 triangles, and about 60 more triangles had stretched textures. Elimination showed the problem was in the source. The fix touched geometry only and left the textures untouched.

This belongs in the quote because repair and rebuild are different kinds of work. For a model with a complete source that passes intake, the main line items are lightweight optimization and going live. For a model whose source cannot be explained, repair needs its own line, and a rebuild comes up only if repair fails. Before intake, model-related items can only be written as conditional. Any figure that looks complete at that stage is a guess.

Model specifications should also point to a public reference rather than a vendor's verbal standard. The Khronos Group publishes asset creation guidelines for commerce-ready 3D content (Khronos Group, 2025), with the stated aim that photorealistic digital twins of products can be used across web, apps, games, and XR. This article cites only the existence and aim of those guidelines. The modeling details inside are not restated here.

The same reasoning applies to file format. glTF is an open, interoperable format for transmitting 3D assets (Khronos 3D Formats Working Group, 2021). If a quote is based on an open format rather than one application's proprietary files, the model files have more room to be reused when the vendor changes or the site is revised.

Part of intake can be automated. The Khronos Group provides an open-source glTF validator (Khronos Group, glTF-Validator) that checks JSON, GLB, buffers, and textures against the glTF specification, and runs in a browser, on the command line, or as a package. Putting the tool into an intake routine is this article's suggestion; the tool's own page does not discuss intake. It checks against the specification. Content problems such as missing faces or stretched textures still call for the elimination steps above.

The interaction side: how far it goes is calculated

Interaction is often treated as decoration, yet it readily causes disputes after signing. This article divides it into three levels: rotating and inspecting, choosing configurations such as color and parts, and stepping through disassembly and reassembly. Each added level brings more than visuals. It brings data, a timeline, and independent movement for every part.

The value of configuration is not hypothetical. A study on mass customization found that self-designed products carry a significantly higher willingness to pay, with the effect arising through a sense of accomplishment (Franke et al., 2010). The subject was customization tools in general, not 3D configurators specifically, so the study serves only as supporting evidence that configuring has value. It cannot predict the results of any particular site. How deep the interaction goes should be set by the business goal first and then converted into budget.

A client who already has a CAD exploded view will want to know whether it can move to the web as is. In the LIDROP 3D configurator case, the client's exploded sequence ran 52 steps, and the web version maps it to a 31-segment timeline. Before work began, the parts that would not carry over to the web version were written into a list: placeholder steps with zero displacement, sub-parts inside an assembly with no independent displacement, and cables hidden entirely during the explosion. The client also asked for reassembly steps to overlap more than the explosion. That was done by playing the same timeline backward, with no second version built, and it was listed as a difference in advance.

How far it goes is calculated, not negotiated. Without this list in the quote, gaps at acceptance turn into each side telling a different story. Requests like these fall under 3D interactive website development.

The device side: the phone limit is set by the owner

How far phone support goes changes the budget directly, because the phone's memory ceiling decides which features fit. The owner should set that ceiling, and the development team converts it item by item, rather than the team deciding afterward what to sacrifice.

The following example is a real-estate viewing website with 3D. The numbers come from a phone environment simulated in Chromium. Memory across the full flow started at about 2.6 GB. The ceiling was tightened in stages, first about 0.9 GB and then a lower peak across the whole flow, with every feature added later counted in. Measurement noise runs to tens of MB, so the figures indicate direction and are not guarantees.

The team converted the ceiling item by item rather than compressing everything at once. The decoding background thread closes after each batch loads. After textures and geometry are uploaded to the GPU, the in-memory copies are released. On phones, the environment map, shadows, water reflection, and panorama cache each step down a level. The texture resolution tiers are chosen by the owner.

Feature trade-offs are settled by measurement. Night scenes and trees each added under 5 MB, but running both raised a single step in the flow by about 40 MB, because the cause was the memory high-water mark, not the sum of the two. The decision from the measurements was to keep trees on phones and give the night city to desktop only, and the owner agreed. A lighter phone-only night scene that lights only the towers was built later, and its peak increase over a long flow was about zero.

So the phone memory budget has to be settled at the start of a project and allocated item by item, like a budget table. What a quote should state is how far phone support goes and which features are desktop-only, not the single phrase “supports mobile.”

Scope grows on its own

What gets paid in the end depends on whether scope grows. An empirical study of software projects (Komal et al., 2020) identified the drivers of scope creep through a literature review and expert interviews, then analyzed questionnaire data with PLS-SEM and found that those drivers are negatively correlated with project success. The study measured project success, not price or delay specifically, so this article uses it for one point only: runaway scope is not just an accounting problem, it also hurts project outcomes.

On a 3D website every detail is visible, and every detail invites a request for a bit more. If the scope is not fixed in writing, those additions have no boundary. The next four places are where a quote deserves a pause.

Where to look in a quote

Separate bugs from new requests before signing

A feature inside the contracted scope breaking and a new request outside the scope are two different matters. A quote should give these two cases separate columns, each stating how the case is handled and priced. Without both columns, there is no defense against additions after acceptance, because any request can be described as something that should have been there originally.

“Including but not limited to” contradicts the scope statement

A common clause reads, “the vendor shall provide services including but not limited to those listed in this quote.” That sentence leaves the vendor's scope without a ceiling, while the scope statement in the same document says that what is listed is the complete scope. With both present, the client will pick the broadest reading in a dispute. When reading a quote, check for contradictions between clauses. A wording that avoids the conflict is “shall provide services according to the content listed in this quote.”

Lump sum, with dates instead of month counts

Some public-sector procurement officers require quotes to be written as a lump sum, with the period stated as a performance deadline date and no month count. The reason given: the actual award date is uncertain, so the real performance period will be shorter than estimated, and a month count written into the quote gets converted into a monthly rate during negotiation and acceptance, which invites a request for a proportional price cut. When a quote gives only dates and no month count, it may not be an omission. It may be a deliberate way to avoid that conversion. Whether private contracts follow the same wording depends on the contract type.

List what is done, not what is excluded

A scope statement can be written two ways: list what is excluded, or state that what is listed is the complete scope and anything unlisted is priced separately. The first can never be finished. The second puts the boundary in the document itself. A good quote leaves no room for “it wasn't written down, but surely it should have been done.” Negative statements are reserved for the one or two items most easily misunderstood, such as integration with existing enterprise systems, a mobile app, or payments.

Questions for cutting the MVP boundary

When the budget is limited, the test for what goes into phase one is not whether something is expensive. It is the answers to the following questions, in order.

1. Whether an obligating document requires it: items that a contract, regulation, or subsidy program explicitly requires cannot be cut.
2. Whether the client will use it today: features that only make sense with real operating data, such as settlement and forecasting, start as database tables and back-office fields, and the output features wait until data exists.
3. Whether a zero-cost manual substitute exists: automatic determination starts as a person reading a rules table, a state machine as a dropdown menu, and a settlement report as a CSV export.
4. Whether it would set off channel politics: showing prices on the official site, for example, can provoke distributors. Cutting that feature saves money and also protects the client.

Member login is not always cut. The test is whether there is a loop that brings people back, such as repeat purchases, renewals, or rebooking. If there is, the feature is the foundation of revenue.

For every feature that is cut, leave one sentence on how things run now, so whoever takes over later knows what was traded away and why.

A complete path, using a residential development as the example, is in the path of a 3D property showroom.

When this approach does not fit

• When the site only needs to show how a product looks and visitors do not need to operate anything, images or a prerecorded video are usually enough, and the cost items of 3D interaction never arise.
• When both the model source and the depth of interaction are still undecided, a lump sum does not fit. Completing intake first and then settling the remaining scope is more honest than signing everything down at the start.
• When the contract is not a lump sum, the performance-deadline wording may not apply and should be judged by contract type.

Next step: what to prepare

Gathering the following before an inquiry makes the scope easier to settle. Anything missing can simply be described as it stands.

• Existing models and source files. Modeling-software originals or CAD both work. If there are none, describe what exists today.
• Any existing CAD exploded sequence or animation.
• How far phone support should reach, and any thinking on a memory ceiling. If nothing is decided, list the features worth keeping.
• Places where documents set requirements on scope, such as a contract, a subsidy program, or procurement papers.

Incomplete material is fine too. On the contact page, describe the 3D website requirements, and gaps get sorted out during intake.