Web Based 3D Cost and What Drives It

Web based 3D has an unusual cost profile: the technology layer is free and mature, and essentially all of the money sits in work that surrounds it.

That confuses buyers, because a quote arrives with no line for the thing they assumed they were purchasing and a large line for something they had not considered.

The engines are free, and that is not a discount

The rendering libraries and engines used for browser 3D are open source, well documented and cost nothing to license.

So a quote is not paying for software. It is paying for a model that does not exist yet, rebuilt for a constraint the model was never built for, plus the experience wrapped around it.

Buyers who benchmark against software pricing arrive at the wrong expectation and then treat a correct quote as inflated.

Driver one: the model rebuild

This is the largest line on nearly every web 3D project and the one most often missing from an initial budget.

A model built for offline rendering carries geometry and texture resolution that a browser cannot deliver to a phone. Publishing it directly produces something that either fails to load or loads so slowly that the audience leaves.

The rebuild preserves silhouette, proportion, opening positions and material behaviour while removing everything the viewer will never resolve at browser scale. It is skilled work and it is not a conversion step.

If no model exists at all, this line also includes building one from drawings, which is comparable in effort to producing a set of renderings.

Driver two: how many units are covered

Coverage is the second multiplier and the one a development controls most directly.

One building exterior and one plan is a small project. Every plan type, with real views for the orientations that differ, is a considerably larger one.

The temptation is to cover a subset and add the rest later. That works if the content was structured for it and costs a second setup if it was not.

Deciding the full coverage at the start, even if it is produced in phases, is what keeps the second phase cheap.

Driver three: how much it responds

A viewer that shows a building is production. An experience where the visitor selects units, switches finishes, compares plans and filters by price is software.

Software carries states, edge cases, testing and a maintenance obligation measured in years rather than weeks.

The honest test for each interaction is whether it answers a question the visitor arrived with. Selecting a unit does. Toggling a time of day usually does not, and it costs the same to build.

Driver four: custom build or platform

A platform brings inventory, availability and structure, priced as a licence with a predictable annual cost and a ceiling on customisation.

A custom build starts from nothing, can be optimised aggressively for a specific audience, costs more up front, and belongs to the project afterwards.

Volume and distinctiveness decide it. Several phases of similar product favour a platform. One distinctive building where the presentation is part of the positioning favours a build.

Driver five: integration with the existing site

Most developments already have a website that works, and the experience has to sit inside it rather than replace it.

That means embedding, routing, tracking continuity and making sure the page around it does not fight it for resources.

It is usually a modest line and it becomes a large one when a vendor proposes rebuilding the site to accommodate the experience, which is a different project being sold under the same heading.

The recurring costs

Hosting and delivery, which is genuinely inexpensive for this format and should be, because the assets are static once produced.

Periodic maintenance as browsers and devices change, which is real and modest.

Content updates when the design changes, which on a development is not a possibility but a certainty.

Budgeting nothing for the third is the common omission, and it converts a routine revision into a negotiation at the worst moment.

Why weight is also a cost decision

Optimisation is work, and there is a point where making something lighter costs more than the audience it recovers.

That point is much further along than most projects assume, because early optimisation is cheap and highly effective while the last increments are expensive and marginal.

A sensible brief sets a target for how quickly something recognisable appears and stops there, rather than pursuing a size figure with no commercial meaning attached to it.

What makes one quote larger than another

Almost always one of three things, and it is worth checking which before assuming a vendor is expensive.

The quote includes producing the model and the other assumes it will be supplied.

The quote covers every plan and the other covers a representative sample.

The quote includes interaction that is genuinely software and the other includes a viewer.

Once those three are normalised, serious quotes tend to converge, and any remaining outlier is usually a misunderstanding worth uncovering.

The specification work that determines every other number

Before anything can be priced honestly, somebody has to decide what the experience covers: which plans, how many views, what interaction, and what happens at the end.

That decision work is real effort and it usually happens informally during a sales conversation, which means it gets shaped by whichever vendor is most persuasive rather than by what the development needs.

A project that writes its own specification, even roughly, before requesting quotes gets numbers it can compare and avoids buying a shape that suited somebody else product.

It also surfaces the multipliers early. Coverage across plan types and views across orientations are the two that grow fastest, and seeing them written down before approval prevents the familiar mid project discovery.

What changes when there are several phases

A single building and a multi phase development have very different arithmetic, and pricing the second as a repeat of the first discards most of the advantage.

Phase one carries the model standards, the material library, the interaction design, the integration and the testing. Those are the expensive parts and they are built once.

Phase two reuses all of it and needs new geometry and new plans, which is a fraction of the original effort. Phase three is cheaper again.

That saving exists only if the same model and the same source assets are retained and owned. Commissioning phase two from a different vendor, or from a vendor who kept the files, resets the arithmetic to phase one prices.

What developments regret paying for

The patterns repeat across projects often enough to be worth naming plainly.

Configurators built before anybody confirmed buyers wanted to configure anything, which cost software money and are used by a small fraction of visitors.

Cinematic introductions, which absorb a meaningful share of both budget and page weight, and which visitors skip when they can and abandon when they cannot.

Experiences hosted by the vendor with no source files, discovered to be a permanent rent at the point the relationship ends.

Coverage of two hero plans only, which looks efficient and then eliminates the development from consideration by anybody interested in a third.

Measuring the return, which this format makes possible

Unlike every other visualization format, this one reports on itself, and that changes the budget conversation for the next phase entirely.

Sessions, time spent, which plans were opened, where people stopped, and how many forwarded the link. All of it available, all of it cheap to capture, and almost none of it collected.

A development that measures the first phase argues the second from evidence. One that does not argues from preference, and preference arguments are won by whoever is most senior rather than by what worked.

Deciding the measures before the build also improves the build, because it forces a clear answer to what the experience is supposed to change.

The hidden cost of getting the coverage wrong

Under covering is cheaper on the invoice and expensive in a way that never appears in any budget, because the loss is invisible.

A prospect looking for a three bedroom, on a site showing only the one and two bedroom plans, does not send an enquiry explaining that they left. They simply leave, and the development records nothing at all.

That silence is the reason coverage is consistently underfunded. The cost of the gap is real, it is recurring, and no report will ever surface it.

The practical defence is to price full coverage first and then decide what to defer deliberately, rather than pricing a sample and treating the rest as optional. The first framing makes the omission a choice and the second makes it invisible.

When updates are cheap and when they are not

Design change is certain on a development, and what it costs depends entirely on decisions made before anything was produced.

If the content is structured so each unit, each view and each plan is a separate asset drawn from an owned model, a change to one plan means reproducing a handful of assets and republishing.

If the experience was delivered as a single compiled build with the geometry baked into it, the same change means returning to the vendor and reopening the project.

The difference between those two situations is not visible at delivery and becomes the dominant cost by the second year. Asking what a single plan change costs, before signing, is the cheapest way to find out which one is being bought.

The comparison that frames it correctly

Against a rendering package, a web experience looks expensive and reaches far more people for far longer.

Against a sales gallery, it looks inexpensive and reaches an audience the gallery cannot touch.

Against a physical show unit, it is a rounding error and it answers questions the show unit cannot, for people who will never enter it.

The useful internal framing is cost per prospect reached rather than cost per asset produced, because this format wins decisively on the first measure and loses on the second.

Where the money produces the most return

The model rebuild, because it determines whether anybody sees the thing at all.

Plan legibility, because every visitor reaches the plans and a large share of sessions end there.

Real views for the units that differ, because that is what the price difference between units is being justified by.

Loading behaviour, because appearing quickly is worth more than appearing beautifully.

Everything after that is refinement, and refinement in this format has a weight cost that is paid by the audience.

Phasing the spend sensibly

A first phase that is complete but modest outperforms a partial phase that is ambitious, because gaps land exactly where the questions are.

Cover every plan simply before covering any plan lavishly.

Add interaction only after the coverage exists, since interaction on incomplete content amplifies the gaps rather than hiding them.

Add visual refinement last, and only where the weight cost is justified by what it communicates.

The cheapest version that is still worth doing

One well built exterior model, every plan legible, real views for the orientations that differ, an indicative price, and a way to send it onward.

No configurator, no time of day control, no guided tour, no audio, no account.

That configuration answers what visitors actually ask, loads quickly on ordinary hardware, costs a fraction of a full build, and can be extended later from the same model.

Starting there and adding only what a named requirement demands is the sequence that wastes the least money in this format.

Ownership, and the clause that changes the arithmetic

If the project owns the source model and assets, every future output is a derivative and the next phase is cheap.

If it owns only access to a hosted experience, every future output starts from nothing and the arrangement becomes a rent with no ceiling.

Over a multi phase development that single clause is worth more than any negotiation on the first invoice, and the leverage to secure it disappears once the work is delivered.

Frequently asked questions

Why is there no software line in a web 3D quote?

Because the rendering engines are open source and free. The cost sits in producing and rebuilding a model for browser delivery and in the experience built around it, which is why a correct quote looks unfamiliar to buyers benchmarking against software pricing.

What is the largest single cost?

The model rebuild. A model built for offline rendering carries geometry and textures a browser cannot deliver to a phone, so the same building has to be rebuilt lighter while still reading correctly. If no model exists, building one from drawings is included.

Why do two quotes differ so much?

Almost always because one includes producing the model and the other assumes it is supplied, or one covers every plan and the other a sample, or one includes genuine interactive software and the other a viewer. Normalise those three and quotes converge.

How should the budget be framed internally?

As cost per prospect reached rather than cost per asset produced. Against a rendering package it looks expensive and reaches far more people for longer. Against a gallery or a show unit it is inexpensive and reaches an audience neither can touch.

What is the cheapest version worth building?

One well built exterior, every plan legible on a phone, real views for the orientations that differ, an indicative price and a way to send it onward. No configurator, no audio, no account. It answers what visitors ask and extends later from the same model.