From magnetic particles to a liquid identity

Vercel Ship 2024 used magnetic particles as its visual language. When Fluid compute launched, those particles gained motion. For Ship 2025, the team wanted to build on that trajectory with something that felt simultaneously fluid and fast.

The exploration began with ferrofluid, a magnetic liquid originally developed by NASA. It combined magnetism, motion, and visual complexity that read as simple on the surface. Initial explorations produced striking results, but internal reviews flagged a problem: the clustered bumps triggered trypophobia in some viewers. The direction pivoted.

Full-spectrum color, oil-slick finishes, and a callback to a previous Next.js Conf prism all got consideration, but each drifted too far into shiny and loud territory. The team pulled back. A model trained to produce consistent lighting, form, and material provided a stable foundation. Softening the shapes and removing spikes resulted in a darker, sleeker, near-metallic liquid system that felt reflective and grounded.

Throughout the exploration, the team generated over 15,000 images and videos using Flux, Google Veo 2, Runway, and Ideogram. Work-in-progress was shared early, and the team iterated on each other's ideas rather than waiting for perfect outputs.

Rapid prototyping from AI to code

AI output seeded visual direction; v0 handled the interactive side. With the core structure and functionality mapped in Figma, the team prompted registration, schedule, and gallery interactions directly in v0, aligned to the design system. Live prototypes shipped on day one, letting the team share and iterate quickly.

Prototyping inside the Design team removed friction from the handoff. Design Engineering received real components with structure, layout, and interactions already settled, rather than starting from static mockups.

Simulating fluid in the browser

While the concept was still forming, experimentation moved toward rendering fluid interactively on the site. The initial approach translated AI concepts into code using ray-marching, which produces smooth surfaces without visible polygons. Explorations included simulating light bending through a glass prism and displacing a subdivided mesh with magnetic particles.

The mesh displacement version produced a plausible ferrofluid effect but didn't feel right. The team shifted to more realistic fluid simulation with ray-marching. Two simulations ran in parallel in one version: one for the floor plane and another for a central tetrahedron. The fluid simulation was calculated in one shader and passed into a ray-marching scene as input. A smaller plane acted as a portal; light rays shot from the camera through the portal into the simulated surface, meaning the liquid was never composed of triangles. Shading and collision with a solid prism were added afterward. Once lighting and interaction were tuned, this became the hero visual.

A simplified backend and content stack

Conference sites carry hidden complexity. Content must be editable without deployments, registration data needs to be queryable, and everything must feel fast. Previous years relied on external tools supplemented with internal caching layers, which grew increasingly difficult to maintain. An attempt to introduce Redis as a fast supplementary data layer improved latency in key areas but introduced duplicated data, extra update steps, limited querying, and engineering dependencies for high-priority edits like promo codes and workshop capacity.

This year's approach simplified the architecture. The site runs as a Next.js app backed by Postgres, with Payload as the CMS. Owning the API and database directly let the team shape the system around their workflows, unifying content, registrant data, and internal models into one source of truth:

  • A CMS for editable landing-page content
  • A searchable, real-time registrant database
  • A backend engineering could build against directly, without sync logic

Teams gained independence. The Events team manages capacity, content, and promo codes without engineering involvement; developers optimize for performance without depending on upstream APIs.

Rendering and caching strategy

Speed required deliberate choices atop the new stack. CMS-driven pages use Incremental Static Regeneration with on-demand invalidation. Partial Prerendering generates most of the homepage at build time while keeping CTAs and login states dynamic. The use cache directive and cacheLife tune freshness by content type: ticket availability gets a short cache lifetime while lower-churn content stays cached longer. after() handles post-checkout logic such as confirmation emails without blocking the user flow.

Running the Payload admin panel on the same domain as the Ship site streamlined debugging and logging. Sign In with Vercel provides account-based access without extra setup. The backend lives in the monorepo, so shared UI assets like logos and design tokens are available directly in the CMS.

Reusable building blocks

A library of themeable components supports multiple events per year, built with shadcn, Geist, and cva. Transactional emails use React Email plugged into the CMS, letting marketing preview and edit content live without engineering support. The shared systems let Brand, Engineering, and Marketing collaborate across surfaces while staying on-brand.

Remaining friction

Self-managing the database surfaced limitations in local tooling. Standing up Postgres locally, running migrations, and seeding data adds overhead to UI work and feature prototyping. Seed scripts help, but the local developer experience is still a work in progress. Future work targets automating setup, previewing real data locally, simplifying schema updates, and improving dynamic content workflows. On the frontend, the team continues exploring how to add visual detail without sacrificing performance.

Motion without the jank

The site was designed to move as smoothly as it looked. The "What you can expect" section uses useTransform from Motion for React with sticky containers and full-screen sections to control scroll behavior. A custom zoom effect required nontrivial math; v0 helped prototype the logic quickly. The sticky header needed to adapt across light and dark sections. Clip-paths were tested, but mix-blend-mode provided a simpler solution.

The registration page brought Brand, Engineering, and Marketing together around a stack that was fast, fluid, and collaborative. Prototyping happened in code, visual directions pivoted when needed, and the platform pushed forward along the way.