Rebuilding the website a 250-person conference staked its business on.

As a co-owner of Nomad Summit and a web designer by trade, this website wasn't just a shared problem — it was my problem more than anyone else's. I'd been the one most frustrated by it for years: every broken flow and every off-brand page was something I knew exactly how to fix but couldn't, because of how the old stack was built.

When we brought on a CTO, the original plan was that hewould rebuild the website. I chose to take it on myself instead, for two reasons. First — speed. I didn't want to spend months on a brief → revision → development → review loop with someone else when I could just be in the codebase making the decisions and shipping them. Second — I wanted to learn how to do this so I could keep doing it. In my own studio, on my own projects, without waiting on a developer to make a change I could make myself in ten minutes.

So I took the rebuild on end-to-end: strategy, information architecture, visual decisions, and every page that ended up in the codebase.

There was one significant catch: I had never built a website in code before.

The new site was built on Next.js on Vercel — a complete departure from the stack that had been failing. Supabase for the database, a headless CMS for structured content across blogs, podcast episodes, and event pages. Our CTO Petr set up the infrastructure and scaffolded the foundation; everything built on top of it was mine to drive.

A URL structure built to last

The old structure was chaotic — /program resolved to a programme from two years ago while the current one lived at /chiang-mai-2026/program. I rebuilt it from scratch: a clean hierarchy that prioritises the current event while keeping every past edition at permanent, predictable URLs.

SEO baked in from the start

Every partnered venue now has its own page populated with venue data — which means the site ranks in searches for the restaurants, bars, and coworking spaces where events take place. Every page exists for a reason.

A custom backend built for this team

Behind the site is a fully custom-built admin section — not a CMS configured to approximate what we needed, but a backend designed specifically for how this team operates. Each person gets precisely the access they need: the podcast producer manages podcast content and nothing else; the marketing team updates event pages and blog posts without touching anything they shouldn't. The right access to the right databases and pages, for the right people, and nothing more. Built to be extended as the operation grows.

Podcast publishing in five minutes, not thirty

On the old site, publishing an episode meant manually pulling everything from Libsyn separately. Now it syncs in one click. What used to take 30 minutes per episode takes five.

The site launched ahead of the next conference. Ticket sales worked. Sponsor conversations restarted as soon as there was something credible to send them to.

The old WordPress + Divi build was slow, fragile, and dragging its own score down with every plugin we added. The rebuild ships a fundamentally different page: faster, leaner, and accessible by default. PageSpeed numbers (desktop):

The underlying metrics tell the same story — what used to take seconds now happens in under a second:

Lighthouse / PageSpeed Insights, desktop. Old WordPress + Divi build vs the new Next.js build.

I took this project on for two reasons: the event needed it done, and I wanted to be the one who could do it.

My work had always lived in design tools. With Nomad Summit, I put myself in the codebase instead — learning to work with Claude Code, understanding how Vercel and Supabase fit together, getting my head around a Next.js project well enough to build inside it. I set up a GitHub account, learned to send pull requests, and figured out what it means to work on a shared codebase with a developer — not through design handoff, but through the code itself. VS Code became the place where the work actually happened.

It was uncomfortable, then empowering, then just the way things work.

The design instinct — asking “does this serve the person using it?” — carries into engineering decisions the same way it carries into visual ones. I walked in knowing that. Everything else, I learned as I built it.

We launched while my business partner and I were both in Danang. We started planning a beach club event — then realised we'd want to actually show the website, which meant we needed a screen the beach club didn't have.

So I made a joke: “Maybe we should just print it.”

We laughed. Then we did it. And if we were already doing something ridiculous, we might as well commit — each page went inside an old-style browser chrome frame, complete with URL bar and tabs. Hidden across the pages were promo codes in a Where's Waldo format: the easier the code was to find, the smaller the discount. People were leaning over printed website pages trying to spot them before anyone else did.

It was exactly the kind of launch that made sense for a conference built around people who left the conventional script behind.

• Alexandra Mosnitska
  Design & development
• Petr Penicka
  CTO
• Claude Code
  Development partner