Startup events do not wait for you to finish. When the date is set and speakers are confirmed, the website has to work, and it has to work on phones, in multiple languages, with forms that route to the right place, and with an access flow that makes sense to three different kinds of visitor arriving through three different doors.
PaulsonTalks was a talks and events website, and this was their entire web presence for a flagship startup event. I built it in Framer across a compressed sprint in March 2025. It was not a landing page. It was a full event system: a homepage with brand routing, a sortable talks archive with CMS-backed detail pages, an event page with interactive ticket and registration flows, and a separate investor-relations page with its own visual language and form pipeline.
The same site, three different experiences
The most interesting product decision was the access flow. A normal visitor landing on the event page would see the standard ticket and waitlist path. But some visitors would arrive through a QR code printed on a physical invitation or issued ticket. Those visitors needed a different experience: an activation flow that recognized their existing ticket rather than asking them to buy one again.
So the site was context-aware. It detected the entry path and changed its CTA copy, form fields, and registration states accordingly. A QR-code visitor saw an activation-oriented interface. A public visitor saw the standard purchase and waitlist flow. An investor inquiry went through its own form into its own pipeline.
This sounds simple in retrospect, but it is the kind of thing that breaks at events. Someone scans a QR code, lands on a generic buy-tickets page, and the experience feels broken. Designing the site to respond to how you arrived is the difference between a polished event brand and a form that confuses its own guests.
An event page that earned its own attention
The visual world was dark, technical, and spatial. The event page itself was built to feel alive rather than static. A 3D floating ticket in the hero reacted to mouse position for lighting. Modular text components carried inline interactive icons. A floating video player followed a custom hover cursor and expanded to full-screen on click. Speaker cards, agenda blocks, and VIP hierarchy sections used glowing, mouse-reactive borders. A sticky CTA appeared only after the hero call-to-action scrolled out of view, so it was always reachable without cluttering the first impression.
None of this was decoration for its own sake. Every interactive element served the job of making a visitor understand, quickly, what the event was and how to participate.
Plumbing that had to hold
The unglamorous side mattered equally. The site ran English as its default with German localization, auto-detecting the visitor's device language and caching the choice. Media moved to Cloudinary after images and videos started disappearing from Framer's native hosting, which is the kind of problem that only surfaces under real build pressure. Talk-detail pages were backed by CMS entries with subheadings, image and video URL support, preview capabilities, and a modular full-screen overlay.
Form routing went through Zapier into Monday for waitlist, VIP, and investor flows. Analytics tracked properly. Mobile and tablet responsiveness was fixed and polished in the final days. The investor-relations page had its own material language of gold, glass, and premium spacing to signal a different register without breaking from the brand.
What the sprint looked like
This was built across roughly ten days of intense work, from initial roadmap and localization setup through homepage redesign, event-page component building, CMS extension, media-hosting migration, access-flow logic, form automation, investor page, and final responsive polish. It was compressed startup delivery, and the site had to be ready before doors opened. Aftercare and general technical assistance went on for 1.5 additional months, until the event was over.
What I take from it
The project taught me that event web systems live or die on access logic and information architecture. The interactive design gets the attention, but the part that actually works is the routing: who sees what, which form goes where, and whether the site can handle three kinds of visitor without breaking. That is the work I care about most in this kind of project.
