Use a headless CMS instead of hard-coded event content
A premium event site changes often: venues, editorial copy, event details, and booking-related content all move faster than a static portfolio-style frontend usually can.
Keep the site mostly static and update content in codeUse a lightweight JSON-driven setupModel the content in Sanity
Decision
I structured the project around Sanity so content changes could be made through an editorial workflow rather than through repeated code edits.
Tradeoff: The content model and frontend queries took more upfront design work than a simpler static build.
Impact: The README-backed schema strategy made the site easier to evolve once the presentation layer was already live.
Treat motion as a system constraint, not decoration
The brand needed cinematic movement, but the site still had to remain readable and responsive across devices.
Use large motion set pieces across every sectionKeep the interface mostly staticApply Framer Motion and Lenis only where they improved pacing and transitions
Decision
I kept the motion identity, but reserved it for areas where it improved perceived quality without obscuring the content model.
Tradeoff: That meant turning down some visual spectacle to keep the experience stable and legible.
Impact: The final UI stayed premium without making animation the only source of differentiation.
Include booking-response email handling in the core delivery
A visually strong event site still fails operationally if booking inquiries disappear into a passive form inbox.
Ship the marketing site first and add email laterDelegate responses entirely to third-party toolingOwn the transactional email path inside the project
Decision
I implemented the outbound booking confirmation path with Nodemailer during the main build.
Tradeoff: Email handling added backend responsibility to what could have been treated as a purely presentational site.
Impact: The delivered product covered both the public brand layer and the immediate communication workflow.