What a Web 3D Project Needs to Start

Web based 3D projects rarely stall on rendering. They stall because nobody decided what the experience covers, or because the model everybody assumed existed turns out to be a construction file that will not open on a phone.

This is the list of what has to exist before production starts, why each item matters, and what the workaround costs when it is missing. It is ordered by consequence rather than by chronology, because the expensive gaps are not the obvious ones.

A decision about coverage, written down

The first document is a list of what the experience will contain, and it is the item most often replaced by a vague intention to show the development.

Which plan types are included, whether every one or a subset. How many views, and from which orientations and which levels. Whether interiors are included and for which plans. Whether amenity spaces appear. Whether price and availability are shown.

That list determines the production schedule, the budget and the timeline. Written down it makes quotes comparable and makes the delivery date real. Left unstated it becomes the thing that expands during production, quietly, until somebody notices the date has moved.

It is also the document that exposes the multipliers early, particularly views across orientations, which is the item that grows fastest and surprises people after the number has been approved.

An honest account of what geometry exists

This is the item that most often turns a comfortable budget into an uncomfortable one, and it is easy to establish in an afternoon.

Does a 3D model exist. Who has it. What was it built for. Has anybody opened it recently and confirmed what state it is in, or is its existence being inferred from the fact that renderings were produced from something.

The common and expensive situation is a project that believes it has a model because the architect works in a modelling application. A coordination model is built for construction and carries structure, systems and detail no browser can deliver to a phone.

Converting that is not an export step. It is a rebuild, and pricing it as a conversion is the single most common way a web 3D budget is understated.

A confirmed drawing set

Where the model has to be built rather than adapted, the drawings are the source and they change more often than anybody plans for.

What is needed is a current set with issue dates, confirmed in writing by somebody with the authority to say which sheet supersedes which. Floor plans, elevations, sections establishing floor to floor heights, and whatever exists of the site and landscape.

The failure this prevents is quiet and expensive. Content produced from a superseded elevation looks finished, passes internal review because nobody compares it to the drawing, and is discovered to be wrong months later when construction makes it obvious.

Where the set is incomplete, the workable approach is to produce what is stable and defer what is not, with an explicit note about which assets are provisional and a plan for revisiting them.

Site and context information

A web experience that shows a building floating on white answers half the question a remote visitor arrived with, and the other half is what is around it.

That requires something about the surroundings: neighbouring buildings at correct height and position, the street, the ground and anything that will remain. Massing accuracy matters more than detail, because the question is relationship rather than appearance.

For a site with real topography, ground levels from survey are needed rather than an assumed plane, since a building sitting on the wrong ground reads as wrong even to somebody who cannot say why.

This is also the content most likely to be omitted for budget reasons and most likely to be missed by a buyer deciding from another state, who has no other way to learn what is next door.

The interaction decision, made early

Whether the experience simply shows the development or lets the visitor do things is a decision that changes the production rather than a setting adjusted later.

A viewer is production work: it is made, it is tested, it is published. An experience where the visitor selects units, compares plans, filters or configures is software, with states, edge cases, a testing burden and years of maintenance.

Deciding late produces the worst outcome, which is a build that acquired interaction incrementally without ever being designed for it, and which behaves unpredictably in the combinations nobody anticipated.

The useful discipline is to name each interaction and the question it answers. Selecting a unit answers a real question. Toggling a time of day usually does not, and both cost the same to build and maintain.

Unit data, cleaned

If the experience shows plans, units or availability, the data behind it has to be in a usable structure, and it never arrives that way.

What is needed is consistent: a unique identifier per unit, plan type, level, orientation, area and status. What projects usually have is a spreadsheet built for a different purpose, with merged cells, inconsistent naming and three units sharing a label.

Cleaning that is a real task, it belongs to nobody by default, and it therefore lands in the final week before launch. Assigning it early with a named owner is unglamorous and it is one of the two things most likely to delay a launch.

A decision about price and availability

Settle this before the build, because it determines whether the experience is a published asset or a live system.

Showing neither leaves the visitor with the one question the experience cannot answer, and they go elsewhere to find it. Showing exact current figures creates an obligation that will be broken within months unless somebody owns it.

The workable middle for most developments is an indicative range, framed clearly as indicative, with an obvious route to a current answer. That satisfies the visitor without creating a maintenance liability nobody will honour.

Where the experience will live

An experience nobody can reach is the most common way this budget is wasted, and the placement decision belongs before the build rather than after it.

Decide which page it sits on, whether it is a primary action or a menu item, whether it appears in the email sequence, whether brokers get the link, and whether advertising points at it directly.

That decision also affects the build, because an experience embedded inside an existing page has different constraints from one occupying its own page, and retrofitting the embed later is real work.

The reference device and connection

Somebody has to name the least favourable realistic case the experience must work on, and it should be named in the brief rather than discovered in testing.

The oldest phone the audience plausibly carries, on a cellular or home connection rather than office wifi, held in daylight rather than in a meeting room.

Naming it early changes production decisions that are expensive to reverse: how heavy the model can be, how much texture detail survives, and how many things can be on screen at once.

Hosting and delivery arrangements

Cheap for this format and frequently unassigned, which produces avoidable delay at the worst moment.

Who hosts the assets, whether they are served compressed, whether the arrangement survives a change of web agency, and who has access to update them.

The question worth answering explicitly is what happens if the relationship with the vendor ends. An experience hosted entirely by a vendor with no source files is a rent rather than an asset, and that should be a conscious choice.

Legal and factual review, scheduled

A web experience is published to the world, which makes its claims more exposed than anything shown in a controlled room.

Views attributed to specific units, distances and travel times, finishes described as included, availability, pricing, and anything implying an amenity that is not committed all warrant review before publication rather than after.

Views are the recurring exposure, because an image showing a specific outlook is a representation about something a neighbouring development can change, and keeping a record of what was published and when is worth the modest effort.

Ownership, agreed in writing

The model outlives the experience, the engine and the agency, and it is the source of every asset the project will produce afterwards.

Owning the source assets in a usable format means the next phase is a derivative, a vendor change is possible, and a design change is a re export rather than a negotiation.

Owning only access to a published experience means every future output starts from nothing, and the leverage to secure the better arrangement disappears the moment the work is delivered.

Analytics decided before the build

This format reports on itself, which is a genuine advantage over every other visualization format and one most projects never use.

Deciding what to measure in advance, rather than adding tracking afterwards, is what makes the data answer commercial questions instead of technical ones.

Which plans were opened, how long people stayed, where sessions ended, how many forwarded the link. Those numbers make the case for the next phase from evidence rather than from preference.

A named owner on the client side

Web projects with no single responsible person on the development side drift, because the decisions required are spread across marketing, sales and the project team and none of them owns the whole.

The decisions that need one voice are unglamorous and constant: which plans are in, what the price framing says, whether a change is worth the delay, and who signs off that a view is acceptable.

Without that person, each question routes to a different stakeholder, answers conflict, and production stops while somebody works out whose opinion governs. That is the most common cause of a schedule slipping without anybody doing anything wrong.

The role does not require technical knowledge. It requires availability and the authority to settle a question in an afternoon rather than in a meeting next week.

A realistic timeline

The model is the long pole and everything else is comparatively fast, which is the opposite of how these projects are usually scheduled.

Model production or rebuild starts as soon as geometry sources are confirmed and runs continuously. Interaction design and integration happen alongside it and are shorter. Testing on real devices happens only when there is something to test, and it is the task compressed when everything else slips.

Legal review should run against content as it completes rather than as one block at the end, since a single objection at the end can hold the whole publication.

What each missing item costs

No coverage decision: production expands quietly and the date moves.

No honest account of geometry: the largest cost appears mid project, after approval.

No confirmed drawings: content built from superseded geometry and rebuilt later.

No context information: a remote buyer cannot learn what is next door and eliminates the development.

No clean unit data: the launch is delayed by a spreadsheet.

No placement decision: an experience nobody reaches.

No ownership clause: the next phase starts from nothing at full price.

The shortest viable starting point

For a development that wants to move quickly, the minimum honest set is a confirmed drawing set, a decision about which plans are covered, ground and context information, a named reference device and an agreement about ownership.

Everything else can be decided during production without holding it up. Those five cannot, because each of them determines work that is expensive to redo.

Gathering them takes days rather than weeks, and it is the difference between a project that ships on the date and one that discovers its real scope in week six.

Frequently asked questions

What most often delays a web 3D project?

Two things, neither of them the 3D. An undecided coverage list, which lets production expand quietly, and unit data arriving as a spreadsheet built for another purpose, which belongs to nobody and therefore gets cleaned in the final week.

We have an architect model. Is that enough to start?

Usually not without a rebuild. A coordination model is built for construction and carries structure, systems and detail no browser can deliver to a phone. Converting it is a rebuild rather than an export, and pricing it as a conversion understates the budget.

Do we need context and surroundings?

For a remote audience, yes. A building shown on white answers half the question and the other half is what is around it. Massing at correct height and position matters more than detail, and on real topography ground levels should come from survey.

Should the experience show current pricing?

Showing nothing sends visitors elsewhere and showing exact figures creates an obligation that breaks within months unless somebody owns it. An indicative range clearly labelled, with a route to a current answer, satisfies the question without the liability.

What has to be agreed about ownership?

That the project owns the source model and assets in a usable format rather than only access to a published experience. With ownership the next phase is a derivative and a vendor change is possible. The leverage to secure it disappears after delivery.