Two proposals labelled “building virtual tour” can describe very different deliverables. One may cover a few panoramas; another may include floor selection, apartment models, an enquiry form and website maintenance. Comparing totals before comparing scope can be misleading.

This article does not set a fixed price. It helps you write a clear brief, understand what you are paying for and identify what will be quoted separately. For your own project, see AXIWALK’s pricing and estimates.

1. The condition of the source files

An existing 3D model is not necessarily ready for the web. Layers may be unclear, textures may be missing or the model may contain far more detail than the finished experience needs. Conversely, readable, coordinated drawings can make the modelling work easier to define. Describe the condition and revision of your files, not just their formats.

The production team should explain how much new modelling, correction or conversion is required. Provide a small sample and an inventory of the available documents. The file preparation checklist will help you cover the essentials.

2. The spaces and interactions included

The number of floors is not enough on its own. A tall building with repeated floors may have only a few apartment types, while a smaller project may contain several distinct spaces. List the unit types, shared areas and panoramic viewpoints to be produced. State explicitly whether the exterior, roof and landscape are included.

Describe interactions as actions: selecting a floor, opening an apartment plan, switching between two views or sending an enquiry. “All features included” is not a scope you can assess. If a reference project has a particular feature you want, send a link and describe that feature.

3. Visual quality and optimisation

Define acceptable quality in terms of both appearance and performance. A model that runs smoothly on the producer’s workstation may behave differently on a visitor’s phone. MDN’s WebGL documentation discusses memory, device limits and processing costs. Source: WebGL best practices. Preparing a model for its target devices may be a separate part of the work.

Specify the target devices and provide a visual reference. Ask which tests are included: agreed browsers, mobile layout, initial loading, error handling and an alternative view. “The highest quality on every device” creates an unclear commitment unless the criteria are defined.

4. Revisions and changes in scope

Agree how many review rounds are included, which changes belong to each stage and who approves the work. Editing a label is different from replacing a floor plan. Approve the initial geometry before detailed materials and lighting, so structural changes late in the project do not spread across several outputs.

Ask for a short list of inclusions and exclusions. Initial modelling, interface design, data entry, hosting, drawing revisions and additional spaces can each have their own line. The purpose is to make responsibilities clear, not necessarily to increase the price.

5. Handover, hosting and maintenance

  • Publication: who owns the domain and hosting account, and how long are they covered by the proposal?
  • Deliverables: will you receive only a public link, or specified files and documentation as well?
  • Updates: who changes text, unit details and images?
  • Support: what is covered, for how long, and how should issues be reported?
  • Migration: which files and access details would be needed to move the experience to another host?

If forms or user accounts are included, describe what happens to the submitted information. Who receives an enquiry? How does the visitor know it was saved? These are part of the finished experience and should be settled before handover day.

A brief you can adapt

“Our project is a [building type] at the [design or construction stage]. We want [audience] to be able to [specific tasks]. We have [files and revisions]. The presentation should cover [unit types and spaces], and most visitors will use [devices]. Our preferred deadline is [date]. Please itemise the deliverables, approval stages, revisions, hosting and support.”

Ask every supplier to respond to the same brief, then compare the differences. A difference in price may reflect a difference in scope. Send these details through the AXIWALK enquiry form, or first use our guide to choosing the right type of experience.

Sources and editorial note

  1. MDN — WebGL best practices: memory, device and processing constraints

Sources were reviewed on 13 November 2026. Unreferenced checklists and examples are editorial suggestions, not client performance reports or guarantees of results.

Have a question or a correction to suggest?

Contact the editorial team