Build vs buy interactive 3D: the costs nobody puts in the quote

A developer principal sits with two quotes on the desk. One is from an agency to build a bespoke interactive 3D sales experience in-house. The other is from a platform that delivers the same thing as a package. Both are written as a single number, and that framing is where the reasoning slips. The build quote reads as a one-time figure, so it gets compared against the platform quote as though the two costs behave the same way after launch. They don't. One recurring cost tracks flat, and one tracks your traffic, and the quote hides the difference.

The variable the quote hides

Build price is easy to quote because it is bounded. Someone scopes the work, adds a margin, and hands you a number. What the quote can't show you is how the recurring costs behave, and they do not behave alike.

Most of them hold flat. Post-launch data edits and model re-syncs recur, but they cost roughly the same whether ten people or ten thousand open the page, and they spread across the months a project sells. One cost does not hold flat. If you render your 3D in real time, you pay a GPU slice for every concurrent viewer, so that term climbs with exactly the launch-day traffic you were hoping for. This post is about that single variable: the compute term that scales with demand, and who can actually afford to carry it in-house. The flat recurring costs, and the full three-year dollar model, are the neighbouring post's job, and we hand them off below.

Set the flat costs aside first

Before the GPU term, clear the flat costs off the table, because they are not what decides this. Two recurring jobs come with any interactive 3D project. Data edits (price, availability, galleries, translations) are made by the sales team in the Back Panel CMS with no developer and no redeploy. Model re-syncs (re-importing a revised floor plan from the architect's file, which Vinode reads from Revit, ArchiCAD, or 3ds Max) run through the render pipeline. Buy a platform and neither reaches your payroll. Both recur at roughly the same cost no matter how much traffic you draw, so they spread flat across a project's selling months. That flat-cost model, priced out over three years, is the neighbouring post's whole subject: the true cost of ownership. We defer it there and keep this post on the one cost that does not hold flat.

The real-time trap: a bill that scales with your traffic

Here is where the pre-rendered-versus-real-time choice stops being about looks and starts being about your bank balance. Both approaches can look photorealistic. The difference that decides build-versus-buy is a single term in the cost.

A real-time engine, the pixel-streaming path a DIY team is most likely to reach for, renders every frame on a server GPU and streams it to the viewer. That means one GPU slice per concurrent viewer. The cost tracks GPU price per hour, times concurrent viewers, times hours live. A single entry-class cloud GPU is cheap on its own: as of July 2026, in us-central1, an NVIDIA T4 lists on-demand at well under a dollar per GPU-hour (Google Cloud GPU pricing). The problem is the multiplier. On pre-sale launch day, when a thousand people open the link at once, the bill scales with exactly the traffic you were hoping for.

This is what makes it a trap rather than a line item. The flat costs above at least stay put. The compute term is the one that tracks demand, so the day your marketing works hardest is the day the meter runs fastest. It is also the one cost a build cannot cap, because it is set by your own traffic rather than by a scope you agreed up front.

Vinode's pre-rendered video has no per-viewer compute term. The scene is rendered once, ahead of time, and streamed as video, which is why a page loads in two seconds (against six for WebGL and twelve for in-browser Unity in the company's own comparison), and one more viewer costs only what one more video stream costs. If you want the full cost and reach argument, the neighbouring posts carry it: pixel streaming versus pre-rendered 3D on cost, and why pre-rendered beats real-time on device reach.

What a from-scratch build actually needs on payroll

"We'll hire an Unreal developer" understates the job. A browser-based, interactive 3D sales tool needs three skill sets held at the same time: a 3D and Unreal artist to build and light the scenes, a web and front-end engineer to wrap them in a real product with filtering and lead capture, and someone to own the render and deploy pipeline so a floor-plan change doesn't turn into a week of downtime. Those are different people, or a very stretched few.

Wages set the floor, and none of these roles sit on a platform buyer's payroll. Time compounds it: Vinode's productized packages ship in two to four weeks (one week for a small estate up to six units, two for a medium, four for a large one), while a from-scratch build is measured in months, plus the hiring it takes to start. There is no verified benchmark for how long a DIY build actually runs, so we won't invent one.

When you should actually build

Sometimes you should, and a piece that never admits it isn't worth trusting. One profile makes the in-house build the right call.

If you are a serial developer shipping many projects a year, with 3D artists and web engineers already on staff, and you need a bespoke real-time interaction no platform offers, the calculation flips. Now the fixed cost of a team spreads across a pipeline of work, and the GPU term is one you have the volume and the engineering to manage rather than fear. A build can pay off. In fairness, that profile is real. It is also narrow: most developers weighing this decision are not in it. A single-project developer, or one without a standing 3D team, is not who a build is for, and the amortisation that would justify carrying a payroll and a traffic-scaling compute bill never arrives.

The reason a platform is the safe default for everyone else is range. One approach has to serve a six-unit infill and a 528-unit, 67,000-square-metre, 25-building development like Safa Al Fursan, a 535-unit community like Safa Almukaymen, 110 filterable rental apartments in St. Gallen, and a 515-hectare masterplan at +Colonia. A single in-house build, scoped to one project, cannot amortise across that spread. A platform is built to.