Corporate Website: DUNE Resort

#The one value on this site that changes without warning

Almost everything on a property developer’s website is static. Renderings, floor descriptions, the site plan, the list of amenities and the directions to the sales office change perhaps twice a year. One value does not: whether a given apartment is still available. It can change at eleven in the morning on a Tuesday, and it is the only thing on the page that a serious buyer actually needs before picking up the phone.

That asymmetry sets the shape of the whole build. Serving a page from cache is what makes a media-heavy site fast, and a cached page carrying a sold apartment as available is worse than a slow one. The buyer calls about a unit that went last week, and the first sentence of a sales conversation becomes a correction. So the resolution was not “cache less”. It was to split the page into the part that can be cached for a long time and the small part that cannot be cached at all, and to make that second part cheap enough that regenerating it costs nothing.

In practice the shell of the page, the imagery, the descriptions and the site plan are shared across all visitors and cached aggressively. Availability and price arrive through a separate, deliberately tiny endpoint that returns nothing but unit identifiers and their state. It has a short lifetime and is invalidated the moment somebody changes a status in the admin. Redis carries the object cache behind the queries that build the listings, Memcached holds sessions and view fragments, and a CDN sits in front of the whole thing, mostly for images, which on a site of this kind outweigh everything else combined.

#DUNE Resort, an apartment complex on the Polish Baltic coast

DUNE Resort stands in the eastern part of Mielno, on the promenade at ul. Pionierow. The investor is Firmus Group, a development group with Norwegian capital operating in Central Pomerania. The complex grew to three buildings and 330 units in total, with outdoor and indoor pools, a fitness area and restaurants on site. The first building, with 114 units, opened in 2013; two further buildings of 153 and 63 apartments followed. Our implementation was carried out in 2017 and took around six weeks.

The chronology matters more than it looks. The site does not describe one finished building. It describes an investment that changes its unit count, its floor plans and its amenity list over the course of its own life. A content model that assumes a fixed inventory forces a template rebuild at every new phase, which is exactly the point at which a developer’s website usually gets replaced rather than extended.

#An apartment is a record, not a page

The common failure in this category is treating a unit as a page with a description. Floor area, storey, room count and sales status then live inside prose, where nothing can sort or compare them. A filter gets requested in the first quarter and a map in the second, and both require pulling numbers back out of paragraphs somebody has meanwhile edited by hand.

Here a unit is a record with fields from the start. Area, storey, layout, window orientation, building, status and the link to its floor plan are separate attributes; the marketing copy is one field among them rather than the carrier of the data. The same record then feeds the results list, the marker on the plan, the unit card and the export the sales office uses, and a single status change shows up in all four at once.

There is a second, less obvious payoff. Sooner or later the sales office asks a question: how many two-room units are left in building two, which of them face west, how does availability break down by size. When the data sits in fields, that is a query and the answer takes a minute. When it sits in descriptions, the answer takes an afternoon of clicking through pages, and it has to be redone after every change to the offer. The model that serves visitors is the same model that serves the internal work, which is the argument for paying its cost up front.

For the person maintaining the site, the consequence is that marking a unit as reserved does not involve editing text and cannot accidentally break a layout. It is a select field with a handful of allowed values. That looks like a detail at handover and it is the single thing that decides whether the data on the site still matches reality a year later.

#What the interactive map had to solve

The map on this site sells; it is not decoration. It shows how the buildings sit relative to the promenade and the beach, lets a visitor pick a storey and choose a unit from the floor plan. The hard part is not drawing a map. It is reconciling two scales: the site plan of the whole development and the plan of a single floor. Those are two coordinate systems, and a visitor moves between them expecting a building clicked on the overview to open the right floor rather than a list of all of them.

The floor plans were built as vector graphics with clickable regions bound to unit identifiers, rather than as coordinate hotspots mapped onto a bitmap. The difference surfaces at the first design revision. With a bitmap, any correction to the plan invalidates every region and they have to be re-drawn by hand; with vector graphics the file is swapped and the bindings survive. On an investment delivered in phases, that is the difference between an hour and two days for every plan update.

Search runs on attributes, not on words. Area, room count, storey, orientation and status are closed-value criteria, so a query resolves against an index instead of scanning text. That matters across several hundred units, because the naive implementation re-queries the database once per toggled filter. The set of available values is computed once and held in cache, and changing a single filter swaps the result list without a page reload.

#Integrations, and what happens when they fail

Availability and reservation data are not created on the website. They are created in the sales office system, and the site is a consumer of them. The exchange runs over a REST API, asynchronously, with validation on the receiving side, because data from somebody else’s system eventually arrives in a shape nobody announced.

The decision that mattered most concerned failure. The default behaviour of most plugins is to render an error or an empty section, which on a sales page reads as a site-wide outage and does more damage than showing nothing at all. Here every channel has a fallback: the last known response from cache, and when even that is missing, a static variant of the section stating that the sales office confirms current availability. The visitor sees a page without one module rather than an error message. An unreachable external system is an event for monitoring, not for the user.

Validation on the receiving side does something else that is rarely mentioned. A record with an empty floor area, or with a status outside the known set, is rejected and reported instead of landing on the page as a blank table cell. One malformed row undermines the credibility of every correct row around it, and a visitor has no way of telling which is which.

#Presentation, imagery and deliberate omissions

The theme is custom, modular, built on HTML5 and SASS. Layout and element placement came from the client, so our part was turning that into templates, responsive behaviour and a content model that survives being maintained. SASS earns its place not by shortening the syntax but by giving the brand colour and the type scale one home instead of forty, which on an investment extended in phases translates directly into the cost of adding the next building.

Imagery is both the main content and the main expense. A rendering of a sea-view apartment cannot be compressed to the point where the sea becomes a smudge, and a full-resolution gallery loaded up front can outweigh every other asset on the page combined. Images are therefore served in several sizes chosen against the viewport width, and anything below the fold waits until the visitor reaches it.

What the site deliberately does not carry is worth naming too. There is no counter of units sold, because such a number takes on a life of its own and within a quarter nobody remembers what was counted into it. There is no yield calculator, because it would produce a figure nobody will later confirm, and on an investment site an unconfirmable figure is a commitment rather than an argument. A deliberate omission is a legitimate result of the work, not a gap in scope.

#A site that has to survive its own construction schedule

A development delivered in phases puts a specific kind of pressure on a website, and it is not the pressure people expect. The expected problem is adding new units, which is trivial once units are records. The real problem is that the meaning of words on the page changes underneath the copy. “The pool” means one outdoor pool in one phase and two outdoor pools plus an indoor one in another. “The complex” means one building at first and three later. Copy written as though the finished state already exists reads as a promise on day one and as a mistake on day four hundred.

Two habits handle that. First, anything counted lives in the data rather than in a sentence, so a figure that changes is updated in one field instead of being hunted through prose that six different people have edited. Second, URLs are designed to outlive the schedule. An address containing a building number or a completion year expires the moment another phase lands, and each such change becomes a redirect somebody maintains for years. An address describing the thing rather than its position in a timetable needs nothing.

The same logic applies to the floor plans and the renderings. They are versioned assets tied to a building and a storey, not files dropped into a media library with names that made sense to whoever uploaded them. When the architect revises a layout, the replacement is a swap in one place rather than a search through every page that might be showing the old drawing. Media libraries on long-running projects decay in exactly this way, and the decay is invisible until a visitor is looking at a plan that no longer matches what was built.

#Our actions

A visitor arriving on the site sees the whole complex first, then narrows down to a single unit, then reaches a contact form, and the layout was built so that this path never doubles back. Attribute-based search holds on to the criteria already entered, so returning from one unit to the list does not throw away the work of getting there. The interactive presentation of the investment, the site plan and the mechanism that keeps statuses aligned with the sales office system all exist to hold that one path together rather than to be impressive on their own.

The most important sentence in this section is that testing of the main paths ran against a copy of production rather than a clean installation, because the performance of a site carrying several hundred records, a gallery and a live integration has nothing in common with the performance of a fresh install running a demo theme. Edge cases such as a unit without a floor plan, a building halfway through being entered, or a status that is not in the dictionary appear only against real data, and only there can they be fixed before launch.

After launch the site received basic monitoring, analytics and cache control. That is the minimum needed to notice that something has stopped working before the sales office notices it, which is the difference between a quiet fix on a Tuesday morning and a call from a broker with a client sitting in front of them.

#Summary

Three buildings delivered at different times, several hundred units in varying layouts, and shared facilities with pools, a fitness area and restaurants. That is more than one screen can carry, and the site was supposed to organise the complexity rather than reproduce it. Every technical decision described above follows from that single requirement, from a unit as a record with attributes, through floor plans as vector graphics bound to identifiers, to availability separated from the cacheable remainder of the page and integrations that degrade one section instead of a whole page when they fail. None of those choices is interesting on its own, and together they are the reason the site stays readable while the investment keeps changing underneath it.

What carries over to the next development project is the way of working, meaning a content model that precedes the template, a split between volatile and static data at the cache layer, and testing against a copy of production. The content model itself and the integrations stay behind, because they were built around one client’s data and the shape of one investment, so the next implementation starts with a scope analysis and the quote follows it.

Learn more on the website: duneresort.pl