Building one platform for a dozen developments instead of a dozen websites

Visualisation studios producing 360 tours and rendered walkthroughs for property developers all reach the same ceiling. The media is excellent and the delivery around it is bespoke: every development gets a launch site, every launch site is built from the beginning, and the margin on the project is quietly consumed by work nobody is paying extra for.

The developer is not buying a website. They are buying the thing that lets a buyer in another country understand a building that does not exist yet, pick a specific apartment in it and ask about that apartment by name. A studio that can deliver that repeatedly is selling a product. A studio that rebuilds it each time is selling hours.

Off-plan buyers do not browse. They arrive with constraints - a budget, a number of bedrooms, a view, a floor they consider high enough - and they are trying to resolve those constraints against a building they cannot visit.

That makes the interaction a search through a physical hierarchy rather than a scroll through a brochure. Pick the tower, move up the floors, see what is left on each one, open a unit, look at its plan, see what the view from that height actually looks like, then ask about it. Every step is a filter, and the last step is the only one that matters commercially: an enquiry attached to a specific unit rather than a generic contact form.

A site that stops at beautiful renders and a form makes the sales team do the resolution by email. A site that carries the hierarchy through to the unit hands the sales team a qualified question.

• Development, then building or phase, then floor, then unit.
• Availability visible at every level, not just on the unit page.
• The floor plan as an interactive surface, not a downloadable PDF.
• Enquiries that carry the unit reference into the developer CRM.

The obvious model - development contains floors, floors contain apartments - survives exactly one project. The next development is two towers sharing a podium. The one after has duplexes occupying two floors, villas that sit outside the tower hierarchy entirely, and a phase two that is sold before phase one completes.

If those variations are handled in code, every new development forks the codebase and the studio is back to building bespoke sites with extra steps. If the hierarchy is data - nodes with types, arbitrary depth, units that can attach at any level and span more than one floor - then a new development is a configuration exercise.

This is the single decision that determines whether the platform is a product or a template. It is made in the first weeks, and it is expensive to reverse later, because by then a dozen developments depend on the shape.

Clickable regions over a rendered facade or inside a 360 panorama are what make a building navigable. The naive implementation places them as pixel coordinates against a specific image, which works until the render is revised - and renders are revised constantly, because the design is still moving while the site is being sold.

When the media is replaced, hand-placed coordinates silently drift. Nobody notices until a buyer clicks the eighth floor and lands on the ninth. The fix is to define regions in a normalised space tied to the model rather than the image, keep them versioned with the asset they belong to, and make a mismatch a loud failure at publish time rather than a quiet one in production.

The same applies to floor plans. A plan drawn as an image with a separate list of unit numbers goes out of sync the first time the developer renumbers a floor. A plan whose regions reference unit records directly cannot go out of sync, because there is nothing to keep in step.

Unit state - available, reserved, sold, on hold pending a deposit - moves constantly during a launch, and it does not originate in the website. It lives in the developer CRM, in a broker portal, or, more often than anyone admits, in a spreadsheet a sales manager updates by hand.

Showing a sold apartment as available costs the developer a conversation they should not have had. Showing an available one as sold costs them the sale. Neither is acceptable, and both are guaranteed if availability is copied into the site and then forgotten.

The pattern is the same one that governs booking systems: one source of truth, an ingestion path that is allowed to be imperfect, and reconciliation that re-reads and repairs rather than assuming the last update arrived. Where the developer has an API, use it. Where the truth is a spreadsheet, treat the spreadsheet as the interface and validate what comes out of it, rather than asking a sales team to change how they work as a condition of the site functioning.

Rendered 360 media is heavy by nature, and the audience for a development in Dubai or on the Spanish coast is international, frequently on mobile, and frequently on a connection the studio never tested against.

The tempting approach is to load the experience and show a spinner over it. The buyer leaves during the spinner. What works instead is a first frame that is immediately useful - a poster image and a working floor selector while the heavy media streams in behind it - so the hierarchy is navigable before the panorama has finished arriving. Preload the floor the buyer is looking at and the ones adjacent to it, not the entire building.

This is worth saying plainly because it is usually treated as polish and it is not. Every second before the building becomes navigable is paid for in enquiries the developer never receives.

The engineering test for reuse is simple: to launch the next development, does anyone open the code? If the answer involves a branch, a deployment pipeline per client, or a developer copying last time and editing, it is not a product yet.

Getting to a real answer means everything development-specific living in data and assets - the hierarchy, the media, the plans, the copy, the palette, the domain - and the platform itself staying one codebase that improves for every client at once. It also means the studio can hand configuration to its own team rather than routing it through engineers.

The commercial consequence is what the studio actually wanted. The interactive experience stops being an unpaid extra around the render and becomes a line item the studio sells to the developer, with a cost of delivery that falls with each launch instead of resetting.

We build and continue to build this platform for a visualisation studio that produces 360 material for developers internationally, with concentrations in the United Arab Emirates and Spain. It has been deployed for more than a dozen developments, and the studio resells it to developers as a service alongside the media.

We are not going to attach conversion figures to that, because the honest measurement belongs to the developers rather than to us. What we can say is the part we are accountable for: the same platform has carried more than a dozen launches, and launching the next one has not required a rewrite.

The pattern generalises past property. Any studio or agency delivering the same complex thing repeatedly for different clients is a candidate for exactly this move - build the thing once, make everything client-specific a matter of configuration, and sell the result instead of the hours. If that describes your business, the free audit is a reasonable place to test whether it holds for you.