Synerggy Events

Content

Everything editable, with a live preview of the real thing

Every section's copy, imagery, and calls to action are database rows rather than hardcoded markup: the hero, the about block, services, team, the closing call to action, the footer, contact details, and every dynamic page behind a slug.

The preview is the part that took the design work. Rather than reimplementing each section inside the admin panel (which guarantees the preview eventually drifts from production), the admin frames a dedicated preview route on the actual website in an iframe. What the editor sees is the real component tree rendering the real content, with a desktop and mobile viewport toggle and a full-screen mode.

That preview surface is treated as internal: it is marked noindex, it hides the site's own header and footer so only the edited section shows, and it switches off analytics inside the frame so editors clicking around never pollute the site's traffic data.

The same pane powers the email builder, where it renders the exact HTML the API will send rather than a React approximation of it, so what the marketer approves is what lands in the inbox.

The hardest interaction

An opening sequence that reorders itself around a live event

The original plan was a three-part opening: hero, then a scroll-scrubbed video, then the first content section. That works right up until the company has an event to sell, at which point the most important thing on the page is the event and the brand hero is in its way.

So it was reworked to reorder itself. When any event is flagged to show in the hero, the opening becomes event showcase, then video, then the hero revealing behind it. With nothing flagged, or if the API is unreachable, it falls back to the original two-act sequence. One checkbox per event drives the whole thing, and the team can flip it themselves.

Both sequences are one sticky viewport with a long scroll track behind it, and scroll progress drives opacity, scale, and the video's playback position through overlapping ranges. The track length differs between the two versions because the three-act one has an extra reveal to give room to.

The centrepiece

A 3D podcast hero that had to be premium and tiny

The podcast studio page needed to feel like the studio itself rather than a page about it. A microphone arrives from the right, and as you scroll the camera moves through the space to settle on an empty chair with the mic angled toward it: the seat is waiting for a guest, and nobody has to be told that in a sentence.

The constraint was brutal in both directions. The assets had to download on a slow connection and render on a cheap phone, but a podcast studio selling premium recording time cannot ship a hero that looks low-poly. The microphone started at 2.31 MB and shipped at 435 KB, with meshopt-compressed geometry and 1K WebP textures. The chair is 329 KB. Neither costs the client anything extra to decode: the standard loader already ships the Meshopt decoder, and the WebP texture extension is handled natively.

Getting it to run everywhere took more care than getting it to look right. The page probes for WebGL2 before mounting anything, then explicitly releases that probe context, because mobile GPUs cap how many live contexts a page may hold, sometimes at eight, and a leaked probe will starve the real canvas into throwing. If the probe fails, or the visitor prefers reduced motion, a static hero renders instead. An error boundary catches anything that still goes wrong at runtime and falls back to the same static version.

A CDN detail worth knowing: the zone in front of these files ignores query strings when building its cache key, so a version query busts the browser cache but never the edge. Replacing a 3D asset means a new filename, and a filename requested before it was uploaded stays poisoned by the cached 404 for a day.

Podcast studio

A studio back office, not just a booking form

The public page sells sessions, picks a backdrop wall, and captures a detailed booking with the package the guest wants. Behind it sits enough tooling to actually run a recording studio's calendar.

Contests

A lucky draw that cannot fail on stage

Contests are fully dynamic: custom form fields, prize tiers, page sections, partner branding, registration windows, one-entry-per-email enforcement, per-contest booking reference prefixes, and their own meta title and description. Entries collect into the same lead system as everything else.

The draw itself is a separate application, because the failure mode is a room full of people watching a screen. It runs as two windows on one machine (an operator console driving a fullscreen presentation window), and they communicate over a same-machine channel rather than the network. A venue wifi drop cannot freeze a reveal halfway through.

Fairness had to be demonstrable rather than asserted. Selection happens server-side using a seeded HMAC-SHA256 stream and an unbiased Fisher-Yates shuffle. The seed's hash is displayed before the first round and the seed itself released after the last, so anybody can recompute the result afterwards and check it.

Leads & marketing

Every enquiry lands in one place, and can be campaigned to

Lead capture can be switched on per event, and captured leads list in the admin panel. Contest registrations, booking enquiries, and spreadsheet imports all resolve into a single lead record that keeps a trace of every origin it arrived through, so the same person entering two contests and booking a session is one lead with three origins rather than three duplicates.

The campaign engine is built for deliverability rather than blast volume. A campaign has a daily cap, a minimum gap between individual sends, a send window expressed in minutes past midnight, permitted days of the week, an out-of-hours override, and a priority for when several campaigns are competing. Sends are tracked per recipient with an unsubscribe token, and a suppression list is honoured across every campaign.

Infrastructure

Four containers on one VPS, hidden behind Cloudflare

All four apps deploy from the same repository as separate services, each building from the repository root so the shared type package resolves correctly. Multi-stage builds with standalone Next.js output brought the images from roughly two gigabytes down to between 150 and 250 megabytes each. A push to the repository rebuilds and rolls the affected containers with no manual SSH step.

Nothing is exposed directly. Traffic reaches the VPS through Cloudflare Zero Trust tunnels, so the origin IP is never public and DDoS mitigation and TLS terminate at the edge. Media sits in object storage behind the CDN, page HTML is edge-cached, and the site revalidates its API fetches on a short interval so content stays current without hammering the origin.

The old site was a Laravel application. A one-time migrator moved categories, portfolio items, services, site content, events, and admin users across, normalising media paths on the way, so nothing had to be re-entered by hand.