Engineering Notebook

Event operations

EthCC Conference Platform

Conference software for EthCC operations at serious scale: 1,200 applications, 6,500 attendees, 400+ speakers and a 30-person team coordinating content, schedules and publishing.

Multi-event evolution
flowchart TD
  A[Single event] --> B[Multiple events]
  B --> C[Teams]
  C --> D[Organizations]
  D --> E[Permissions]
  E --> F[Reusable platform]

Problem

The team needed software that could support a major conference while coordinating applications, speakers, schedules, sponsors, content and last-minute operational changes without turning the website into a manual publishing bottleneck.

Workflow

The core workflow moves from organizing team input to validated event data to public output.

  • Organizers maintain event content and operational data.
  • Applications move through review and decision states at high volume.
  • Speakers and sponsors become structured objects instead of ad hoc page content.
  • Schedule changes propagate to the public experience without turning every edit into a deployment crisis.
  • Permissions determine who can edit, review and publish.
  • GitHub Actions give the team repeatable release paths when changes need to reach production.

Architecture

The architecture separates event identity from reusable platform behavior. Each event has its own public surface, but the content model, permissions model and publishing workflows can evolve as shared platform capabilities.

  • SvelteKit and Next.js for event-facing web surfaces where the rendering model matched the product moment.
  • Firebase Auth for managed authentication around operational access.
  • Firestore for structured event data, speaker data, application state and operational records.
  • Cloud Functions for backend behavior around workflows, automation and integration boundaries.
  • Strapi where editorial content management needed a clearer authoring surface.
  • GitHub Actions for deployment and operational confidence around release workflows.

The important boundary was not framework choice. It was separating public event presentation from the operational data and workflows behind it. That allowed the product to evolve from a single event implementation toward reusable event-platform behavior without forcing every concern into one layer.

Decisions

The most important decision was to stop treating every event as a one-off website. Once the event became a domain object, teams, organizations and permissions could be added without rewriting the mental model.

Firebase Auth and Firestore were useful because the system needed managed identity, structured operational data and quick iteration under event timelines. Cloud Functions handled backend workflows where the public site should not own the logic.

Strapi belonged where editorial workflows needed a content-management surface. GitHub Actions belonged where the team needed repeatable deployment behavior. The architecture was a set of pragmatic boundaries rather than a single framework ideology.

Lessons

Multi-tenancy should appear only when the business has proven the need. The first version should reveal the operating model; the second version can turn repeated behavior into platform leverage.

At EthCC scale, the difference between a website and a platform becomes visible quickly. 6,500 attendees and 400+ speakers create operational pressure that cannot be solved by page templates alone.

The lesson is to model the event team as carefully as the public visitor. Applications, schedules, speaker data, permissions and publishing workflows are all part of the product, even when attendees only see the polished public surface.