Real Estate Platform: DUNE CITY

#Dune City, comprehensive investment website on the Baltic Sea

Three hundred and thirty apartments. That number reads as a marketing line in a brochure and as something else entirely in a content model, and the difference is the whole project. Each apartment has a floor area, a floor, an aspect, a layout, a building, a sales stage, a status and a price, and at least half of those fields change over time. A developer’s website is therefore not a showcase with photographs. It is an interface over a database that keeps moving while people are reading it.

The complex is Dune Resort in Mielno, on the spit that separates the Baltic Sea from Lake Jamno, roughly ten kilometres north of Koszalin. The developer is Firmus Group and the architecture came from the SAS and Mellon studios. Apartments range from one to four rooms, and building B holds a year-round wellness zone with indoor pools. The scope covered identity work alongside the site itself, which is why this entry sits in both the logotypes and the websites categories.

The implementation ran in 2017 and took about six weeks. As the WordPress developer I built a custom theme and the modules that present the inventory. The client supplied the layout and the placement of elements.

#What a developer sells and what a buyer looks for

Someone buying a seaside apartment moves through a website in the opposite direction to someone booking a room. They do not browse the offer, they eliminate it. They arrive with one hard constraint, usually budget or floor area, cut most of the inventory inside the first minute, and only then start looking at photographs. That inverts the usual hierarchy of a page: the filter is primary content here, and the visual layer only starts doing work once the list has shrunk to a dozen entries.

The second criterion is spatial and does not fit in a form. On a development built on a spit, what matters is which side of the building a unit sits on, because that decides whether the view runs to the sea, to the lake, or to the next block. No slider asks that question. Selection therefore has to be possible on a floor plan and on a site map, not only in a list of results.

There is a third factor specific to this location. Mielno is a seasonal town, but buying an apartment is not a seasonal decision, and a large share of buyers treat the purchase as a rental investment rather than a second home. Those are two entirely different conversations held on the same pages. A buyer for personal use asks about layout and quiet. A buyer for rental asks how many weeks a year the unit can be let and whether the building offers anything that extends the season. The year-round wellness zone in building B answers precisely that second question, so in the information architecture it cannot be one more amenity tile next to the car park.

Trust is the fourth. A development sells something that, at the moment of purchase, often does not exist yet, at least not in the state in which it will be handed over. Everything the site presents as fact therefore has to be either verifiable or clearly marked as a visualisation. That is an editorial decision with a technical consequence: renders and construction photography have to be distinguishable inside the content model, not dropped into one gallery together.

#Key features and modules

The map module combines a Google Maps API integration with the Leaflet.js library and serves both the site map and the interactive floor plans. Separating the two is deliberate. The site map answers where this is in relation to the beach and the promenade, and geographic data belongs there. A floor plan is not a map of the world; it is an image with clickable regions, and driving it through the same mechanism as a map ends in scaling that falls apart on a phone.

Search and sorting run on custom fields and taxonomies, with results fetched asynchronously over AJAX. Multi-dimensional filtering is where a property catalogue usually falls over, because every added attribute multiplies the number of combinations. A naive implementation queries the database once per toggle, and with three hundred and thirty units and six filters that becomes dozens of queries per click. Here the set of available values is computed once and held in cache, and a single filter change swaps the result list rather than reloading the page.

Integration with external systems over REST API synchronises availability, reservation status and offer updates. This is the most sensitive part of the whole build, because the source of truth about status is not the website but the developer’s sales system. Any lag in that synchronisation carries a very concrete cost: a prospect calls about a unit sold yesterday, and the first sentence of the sales conversation is a correction.

Analytics tooling shows which units are viewed most and how interest distributes across stages. For a developer that is operational information rather than a report for a meeting: if a particular layout attracts many views and no enquiries, the problem is in the price or in the description, and both can change the same week.

The performance layer rests on caching (Redis, Memcached) and content distribution through a CDN, with infrastructure on AWS. The tension here is the exact opposite of a brochure site: a developer’s site has to be fast and current at the same time, and in cache architecture those two properties pull against each other.

#Technical solutions and challenges

The theme was built as fully responsive and modular, on HTML5 and SASS. Modularity is not an architectural flourish here; it is a response to the life cycle of this kind of development. Stages launch one after another, each gets its own building, its own pool of units and its own campaign, and the site has to absorb a new stage without a template rebuild. A project where building A is hardcoded in a dozen places costs a week at building C instead of an hour.

Geolocation data required dedicated endpoints returning position and unit parameters for dynamic display on the map. The hard part is not drawing points. It is that the floor plan and the result list have to show the same state: a visitor who filters for two-room units expects exactly those apartments to light up on the plan. Holding one source of state for two such different views is the real difficulty.

Asynchronous processing over AJAX and REST API improves the browsing experience and costs something in a place that is easy to forget. Filter results loaded without a page reload have no address of their own, so they cannot be shared or indexed. The answer is to mirror filter state in the URL and return a full server response for a direct entry, while keeping the asynchronous path for subsequent toggles. That is roughly twice the work of the AJAX layer alone and the only way search results exist outside one browser session.

URL structure deserves its own paragraph, because it decides whether the development exists in search beyond its own name. People do not search for the name of a development until they know it. They search for a two-room apartment in Mielno with a sea view. That means filter combinations carry real search potential, but only some of them. All of them at once produce thousands of near-identical addresses, which is the classic way to dilute a site. The answer is to pick a dozen or so combinations that match questions people actually type, give them their own addresses and content, and keep the rest of the filter space out of the index.

It is worth naming the cache tension plainly, because it defines this project. Descriptions, photographs, plans and marketing copy can sit in cache for weeks. Unit status and price cannot sit there for an hour. Put both under one policy and the policy has to follow the shorter one, which means giving up caching for the ninety percent of content that never needed freshness. Splitting them means the page shell and the gallery come from the edge, while the status fragment arrives in a separate, cheap request.

Performance measurement means something different here than on a corporate site. The heaviest view is not the homepage but the result list after filters have been applied, and that view has no fixed address, so a standard homepage audit never reaches it. Testing has to follow the paths traffic actually takes, and preferably against a production copy with the full inventory loaded. On an empty installation with ten sample units everything is fast and nothing is learned.

Campaign behaviour is the second measurement worth planning for. A developer launches advertising for one stage and within an hour a single subpage takes more traffic than it saw in the previous month. That pattern is predictable, so it can be handled cheaply: the stage page is fully cacheable apart from the status fragment, and the status fragment is light. Without that split, the same campaign means paying for server capacity for one day.

Mobile deserves a note too, because first contact with the offer happens on a phone while the purchase is finalised on a desktop. A floor plan on a four-hundred-pixel screen is unreadable if treated as an image to scroll. Clickable regions have to be finger-sized rather than cursor-sized, and on a smaller screen that usually means the plan stops being a map and becomes a list with highlighting. That is not a simplified mobile version, it is a different answer to the same user question.

#Our actions

For Dune City we delivered the site with its map modules, search and external synchronisation, so that a visitor could check the current offer without walking through a dozen subpages by hand, plus the identity layer aligned with the development’s other materials.

The work differed from a typical corporate site because the content was produced in parallel with construction. Plans changed during the project, some units were renumbered, and photography arrived in stages. The content model therefore had to survive a situation where the same entry carries a render first, a construction photograph later and a finished interior at the end, with none of those swaps requiring anyone to touch a template.

Unit numbering is the thing that most often breaks a year after launch rather than on launch day. It changes during construction more often than anyone assumes while designing the data model, and if the unit identifier is also the number shown to customers, every change breaks links already circulating in emails and sales documents. Separating the internal identifier from the visible label costs one database field and saves a week of corrections.

Photography is the second such place. Interior shoots usually happen after the first building is handed over, so the site lives on renders for a year or more. The moment of the swap is critical for credibility: if renders and photographs share one gallery, what remains after the swap is a mixture in which nobody knows what they are looking at.

The third is the price list. Developers change prices by stage and often prefer not to publish them in full, releasing them after contact instead. That requires price to be a separate field with its own visibility rule rather than a paragraph typed into the description. All three cases share one nature: whatever changes independently has to be its own field, or every change becomes editorial work in a dozen places at once.

#Summary

Dune City is a project where the presentation layer is the least interesting part of the work. The difficulty lives in the data model, in holding one state across a list, a plan and a map, in synchronising with the sales system, and in separating what may be cached from what has to be fresh.

There are no result metrics on this page. Lead counts, sales pace and percentage increases belong to the investor rather than to a contractor’s case study, and none of them could be attributed to a source here. What transfers to the next project is the order of the questions: establish what changes and how often, then choose the technology. On a property development that question matters more than the choice of framework, because the answer decides whether anyone can add a new building two years later without a developer in the room.

One more consideration shapes the long tail of such a site. Part of the complex is run by a rental operator, City Apartments, managing close to two hundred and fifty units. That means the same address serves a different purpose once sales finish than it did during the development phase, and the information architecture had to anticipate that rather than assume the site dies with the last unit sold. The two usual directions for extending a build like this are a deeper integration with the sales system, removing the manual update step, and support for the post-sale phase. Each is a separate scope, quoted after analysis.