Most developers have this conversation two or three years too late, usually at renewal, and usually in the same shape. The launch went well. The interactive master plan did its job. Now the contract is up, the renewal number has moved, and somebody asks the obvious question: if we walk away, what do we actually keep?
The answer is often less than everyone assumed.
The renders you commissioned are yours. The thing built on top of them may not be.
The three layers, and who tends to own each
An interactive master plan is not one asset. It is three, and they are contracted differently even when nobody says so.
Layer one: source material. The master plan render, building views, floor plans, the brand assets. You commissioned these and you almost always own them outright. This layer is rarely disputed.
Layer two: the build. The boundaries traced over the artwork, the navigation between views, the interactive behavior. With a bespoke build this is software, and software belongs to whoever wrote it unless the contract says otherwise. Many developers assume they own it because they paid for it. Paying for work and owning its output are different arrangements, and the default in most software contracting is not the one buyers assume.
Layer three: the accumulated data. Unit inventory as it evolved, enquiries with the context attached, and the exploration history showing which zones and unit types buyers actually wanted. This layer did not exist when you signed. It accrued. It is also, after two years, frequently the most valuable of the three, and the least likely to have been addressed in the contract at all.
The layer that was worth nothing on day one is usually the one worth most on the day you leave.
The question that surfaces the answer
Skip the ownership clause on the first pass and ask something more practical instead:
If we gave notice today, what could we export, in what format, and how long would it take?
Ownership is a legal position. Export is an operational fact. A vendor can hold a perfectly reasonable ownership position and still leave you unable to move, because the thing you own is a running system rather than a set of files you can take somewhere else. Conversely, a vendor who retains the code but hands over your inventory, your leads, and your geometry on request has left you materially free.
The feature checklist covers what to check about the product. This is the parallel question about the arrangement around it.
What to establish before signing
Source files. Confirm in writing that the renders, drawings, and brand assets you supplied remain yours and are returnable on request. This is usually uncontroversial and takes one sentence.
Inventory export. Your unit list, with status history, in a structured format such as CSV. Not a PDF, not a screenshot of a dashboard. If the inventory can only be read through the vendor's interface, it is not portable.
Lead export. Every enquiry with its timestamp and the context it carried: project, building, floor, unit, and the action the buyer took. These are your customer records. Treat them the way you would treat any other customer database and confirm you can extract them at any time, not only at termination.
Geometry. The boundaries drawn over your artwork during setup represent real work. Establish whether they come with you or stay behind.
What happens at phase two. Not strictly an ownership question, but it belongs in the same conversation. Whether the next phase is a variation on the current agreement or a new project fee changes the economics of the whole relationship. The cost guide sets out how the different delivery models handle this.
Sell-out. Ask what happens to the experience when the last unit sells. Some arrangements end there. Others keep the same master plan running for resale and rental, which is a different asset life entirely.
Where the categories actually differ
The instinct is that a custom build is safer because you commissioned it and might own the code. In practice the picture inverts more often than not.
A bespoke application whose code you own, written by a studio that has moved on, running on infrastructure nobody at your company can administer, is a liability rather than an asset. Owning source code you cannot deploy is ownership in name.
A platform arrangement where the software is licensed rather than owned, but your renders, your inventory, and your leads export cleanly on request, leaves you materially freer. You can take your inputs and your data and go somewhere else. What you would rebuild is the configuration, with the assets already prepared, not the years of accumulated buyer data.
Ask what you can export, not who holds the source code. The second question sounds more serious and tells you less.
The uncomfortable version of this question
There is a variant worth asking about any vendor, including us: what happens if you stop trading?
Nobody enjoys the question and every serious buyer should ask it. The useful form is not a promise about longevity. It is a mechanic: can we get our data out on demand today, without asking permission, in a format something else can read? A vendor who can answer that concretely has given you a real answer. A vendor who responds only with reassurance about their stability has not.
For RegalScene, ask us the same questions. Your source assets stay yours. Ask how your project and enquiry data is handled, what access remains available during the contract, and what happens to it if the service ends, and get the answers before you sign.
Related reading:
- Interactive Master Plan Software for Property Developers
- Interactive Master Plan Features: A Developer's Checklist
- How Much Does an Interactive Master Plan Cost?
- What to Prepare Before Building an Interactive Master Plan
- Your Master Plan Shouldn't Retire When the Last Unit Sells
RegalScene is a platform: your renders stay yours, and the data questions above are ones we expect you to ask. See how it works or ask us the awkward questions.