Appearance
Marketing Websites
Purpose: The public brand websites where prospects discover and browse homes. This is the top of the funnel: prospects land here, explore, and then hand off to the booking forms to book a viewing or reserve.
Primary users: Prospects (the public); the marketing team, who author the content.
See it live: wayoflife.com, theeades.com, thedraper.com. See Accessing the systems.
Marketing sites are per operator. Each operator that comes onto the platform brings its own websites, with their own URLs, branding, design and (usually) their own repositories. What they all share is the destination: every operator's sites hand off to the same booking platform.
The rest of this page describes Way of Life's sites, as the current operator. A future operator's sites will look different and live on different URLs, but follow the same pattern: a browsing site (or sites) that deep-links into the shared booking platform by the unit's reference. The specifics below (five sites, Storyblok, Netlify) are Way of Life's implementation, not a platform requirement.
Way of Life's sites
| Repo | Site | Brand |
|---|---|---|
| wol-multi-family | wayoflife.com | The Multifamily portfolio (all developments, locations, search) |
| wol-single-family | Single-family homes brand | |
| wol-students | Students brand | |
| wol-eades | theeades.com | The Eades (white-label, single development) |
| wol-draper | thedraper.com | The Draper (white-label, single development) |
Key rules:
- They share a common starter (a Nuxt boilerplate) but are independent repos that have diverged: different Storyblok spaces, different design systems, even different build tooling. A fix in one is not automatically in the others.
- A development can appear as a coming-soon page on wayoflife.com and/or graduate to its own white-label site.
What's on them
Home, locations, buildings, individual apartment listings, portfolio-wide search and filters (on the multifamily site), saved favourites, a journal/blog, FAQs and contact. White-label sites are a smaller subset focused on their one building. Nearly all of this is authored in Storyblok.
Where availability & pricing come from
The sites do not call Everest live. Each property and apartment page carries a block of listing data (availability, rent, beds, features, images) that a separate process syncs from Everest into Storyblok. The sites only read it.
So availability and pricing are as fresh as the last Everest-to-Storyblok sync and the last cache refresh, not real time. "Why is a let apartment still showing as available?" is a sync or cache question, not a website bug.
Handing off to booking
From an apartment or building, the "Book a viewing" and "Reserve" links carry that unit's Everest reference across to the booking forms app. Two patterns exist across the family:
- The multifamily site links straight to the booking app.
- The white-label sites route through a short "taking you to Way of Life" gateway page first.
Reservation links can be switched off per building.
Content management (Storyblok)
The marketing team edit content directly in Storyblok, where each site is its own space. Pages are built by stacking modular sections, and publishing a change fires a webhook that purges only that page from the cache, so it appears on the next visit. The synced listing data is machine-owned, so editors should not hand-edit it.
Resident-app onboarding (not part of the funnel)
The multifamily site also hosts resident-app onboarding pages (register, password reset, app download). That's an off-ramp for existing residents, separate from the prospect journey.
Integrations
| System | Role |
|---|---|
| Storyblok | The CMS all content (and the synced listing data) is read from |
| Everest | Source of the listing data, synced into Storyblok (not called live) |
| Booking forms | Where "book a viewing" / "reserve" hand off, keyed by the Everest reference |
| HubSpot | Contact, newsletter, wait-list and coming-soon form capture, plus chat |
| Analytics & marketing | GA4, Meta Pixel, TikTok and Google Ads, all fired through GTM under cookie consent |
| Cookiebot | Cookie consent and Google Consent Mode |
| Hotjar | Behaviour analytics |
| Google Maps | Location and neighbourhood maps |
| Curator | The social-media wall |
Hosting & ops
Server-rendered on Netlify. Content freshness is driven by the Storyblok publish-then-purge flow above rather than a schedule. Staging sites are behind basic authentication, and releases go out on a scheduled deploy day rather than on every merge.
Related documentation
- Booking Platform: the app these sites hand off to.
- Everest: the ultimate source of the listing data.
- Key journeys: browsing is the first step.