DeFi Connect 2025 Event Platform

The workflow connected external event operations to a public-facing platform.

• Party Action People managed the event concept, summit structure and launch needs.
• Speaker and agenda data were managed in Sessionboard.
• The platform consumed speaker, agenda, session and event metadata from Sessionboard.
• Shared Next.js components rendered summit pages, agenda views, speaker navigation and session pages.
• Each summit kept its own visual identity while reusing common routing, layouts and data access.
• Ticket purchase remained external through the dedicated ticketing platform.

The architecture evolved from a single website into multiple summits, shared infrastructure, independent visual identities, a shared content model, an external Sessionboard source and external ticketing.

The platform used one modular Next.js application instead of five separate websites.

Sessionboard acted as the external source of truth for speakers, agenda data, sessions and related event metadata. The frontend normalized that data into reusable views for agenda browsing, speaker navigation and session details.

The public platform separated shared event behavior from summit-specific presentation:

• Shared infrastructure for routing, data access, deployment and layout primitives.
• Shared components for agenda, speaker, session and navigation surfaces.
• Summit-specific pages and custom shader-based visual identities.
• External ticketing links that kept registration outside the web platform.

This reduced duplication across the five summit experiences while keeping enough flexibility for each summit to feel visually distinct.

The first important decision was to build one modular platform instead of five independent websites. The event contained five summit experiences, but separate sites would have duplicated components, data loading, agenda logic and deployment effort.

A shared platform required more upfront content modeling and component architecture, but reduced delivery risk and made speaker and agenda integration more consistent. One unified platform could support five distinct summit identities while sharing Sessionboard integration, layout primitives, agenda rendering and ticketing flows.

The second important decision was to use custom shader-based visual identities for summit differentiation. The client wanted a non-standard creative direction and each sub-site needed to feel different without requiring five completely separate design systems.

Shader-based visuals required more careful performance handling and responsive testing, but created a stronger identity while staying componentized.

Multi-event websites should be modeled as content systems, not static page collections.

Shared architecture becomes valuable quickly when multiple identities reuse the same agenda and speaker data. The more summit pages, schedules and session views depend on the same information, the more important normalization becomes.

External tools like Sessionboard can remain the source of truth if the frontend has clear data boundaries and reusable rendering primitives.

Creative frontend work still needs performance discipline. Shader-based visual direction can support a distinctive event identity, but it has to be implemented with responsive behavior and runtime cost in mind.