Making of : “La nuit des Losers”

It's live! You can check out the site for our event, "La nuit des Losers," right now.

For those not sure what I'm talking about: this event is dedicated to bringing back forgotten projects that ended up in the archives. Rather than mourning them, it's a stage for those who gave it their all.

This blog post will share how we quickly built the site with the help of AI, our process and our learnings.

The site itself had one job: explain the concept, share the practical info, and make our friends in the industry want to come and bring their own buried ideas.

It had to feel like a fun, ironic and safe space. Somewhere people feel comfortable enough to notice and appreciate small design details.

Everything started with the regular process: wireframing. This time @alberto gave it a shot, and it turns out he's got some hidden design talent.

For this part we went back to pen and paper. Still the only tool that never goes offline and never lags.

As you can see, the single page opens with a big typographic hero, then moves through a concept presentation, reasons to attend, a quote, and a programme timeline. Further down, a speaker roster with portrait cards, a sponsors and partner agencies section, and a closing sign-off.

A simple structure that helps the user first understand the purpose of the event, why attend, the schedule and the participants.

I was given a key visual to help me understand the art direction of the event and take it further. The visual references the "Loser" hand gesture in thick black outlines on white. No shading, no texture. Flat, clean, with a cartoonish feel, the kind of thing you'd see in a system emoji pack.

What we were missing was a font. For that, I chose Proxima Soft. It had the right features and typographic details to match the hand illustration, and thanks to Adobe Fonts I could install it right away.

That turned out useful later too: I just gave Claude the font links, and it used them directly in the project without me having to install anything or authorize access on its end.

After having chosen a font and analysing the visual, I started iterating quickly on mobile screens to get ideas out and discard the ones that didn't work.

I decided to iterate on mobile since we expected a lot of users to come in from social apps, and it let me compare the different screens I was making side by side.

Once I was starting to have a solid product on mobile, I verified the layout worked as well on a desktop viewport. While working on it, I came up with a few ideas I got pretty excited about.

For example, I thought it'd be fun to have the hand follow the user's mouse, and that some sections could be spiced up with scroll-reveal animations. The craziest idea was near the footer: a pinball game. All good ideas to make the site engaging. But were they actually feasible on the web?

So once I was happy with a first draft, it was time to put those ideas to the test and see if they made sense in practice. For this I used Claude Code to quickly prototype my ideas, with the Figma MCP helping Claude "read" the design and generate the layout for the desktop viewport.

On the technical side, I kept the stack deliberately simple: Vite and TypeScript, nothing else. No framework, no backend, no build gymnastics. For a one-page site, anything more would've been complexity.

Vite's hot reload matters because every change Claude made showed up in the browser instantly, so I could judge an animation or a spacing fix the second it landed instead of rebuilding and guessing.

So I wrote my prompt and hit enter.

Once Claude was done, I was honestly surprised by how close it landed to what I'd designed. I had to apply some minor corrections: typography, spacing, and cutting a few things that didn't need to be there. After that, I moved into the fun part: animations and interactions.

I tested a few behaviours for how the hand should track the mouse. It took some back and forth to get right. I had to actually guide Claude through how the hand should twist with the cursor, not just follow it.

Then I had an idea I could test on the spot: click on "Nuit" and the site shifts into "night mode." Small idea, but I liked being able to test it on the spot instead of noting it down for later and spending time in Figma picking colours for a "dark" theme mockup first.

The banner at the top started as a simple element. Then I wondered if it could work as a marquee instead, and Claude handled the scroll progression without a problem. What caught me off guard was that it stopped the marquee animation whenever the mouse hovered over it. Something I might have added later on, but nice to see it already implemented by default.

These kinds of details make a site feel like someone actually thought about the users.

The card explaining the main event felt flat once I saw it built. I asked Claude to add a small reaction dashboard, where visitors could react and see counts update live.

It's not wired to a database. That would've added real complexity for not much payoff, so the counts are just random and reset.

Claude probably could have handled the real version too, but for a one-page event site, faking it was the right call.

For the "why attend" section, I wanted more than static cards, so I asked for a click-to-expand interaction showing more detail.

It worked well on the first try, except the animation felt stiff. Putting into words what "stiff" actually meant was the hard part, and my colleague @benoit helped with that. Once we could describe it properly, Claude fixed it fast.

This is also where I noticed my credit usage climbing. I burned through credits in a single afternoon of trial and error before changing how I worked.

Using plan mode, where you see what Claude intends to do before it touches anything, saved a lot of back and forth. And a lot of credits.

The speaker cards were more interesting. Hover to reveal the tear, and then, because why stop there, we made them cry.

The hard part was positioning the teardrops exactly where we wanted. So I asked Claude to build us a small tool: a bare page with the portrait, where I could drag the tear to the right spot, hit "copy position," and paste the coordinates back into chat.

Claude then placed every teardrop precisely. Once they were all set, I asked it to remove the tool. Strange sentence to write, but that's the workflow now: build a tool, use it for ten minutes, throw it away.

The sponsors and partner agencies section was the hardest part of the whole build.

First attempt: pinball. That meant thinking through every edge case for the walls, resets, how multiple balls interact, and keyboard controls for the levers versus clicks. And then, of course, the bugs.

My favorite bug was when the ball would occasionally clip through a wall at high speed and vanish from the board entirely. After fixing all of the bugs, I got it working well on desktop.

Mobile was another story. I deployed previews on Vercel and found that double-tapping the screen zoomed the whole page and broke the game. Claude was also struggling to lock down the canvas boundaries properly.

After a while I realized we were deep in a rabbit hole with a deadline approaching, so we cut our losses and switched to something simpler: a bowling-bricks game where the ball bounces around a board and scores points off the sponsor logos.

Less ambitious than pinball, but it worked cleanly on both desktop and mobile, with no fight required.

We originally planned to sell tickets, but decided the event should stay as accessible as possible, so we dropped that entirely.

The ticket button got repurposed into a "save to calendar" button instead. Hit it, and a calendar file pops up ready to save.

Claude even suggested adding details we hadn't thought to ask for: notification timing, a short description, location. A good example of Claude filling in gaps instead of just following instructions literally. It had enough context to know what we'd actually want.

I learned the hard way how to manage git properly: structuring releases, branching before testing anything big. I broke the site more than once by mixing features together in one branch. Slower process, but a real lesson.

Working this way also meant the three people who usually sit apart on a project (client, developer, designer) could look at the same live Vercel preview and agree on what "done" actually meant, instead of everyone imagining a different version of it in their head. People could react to the site while it was still rough, and we could fold in feedback fast instead of waiting for some big reveal.

Our dev team caught real issues too: accessibility, SEO, performance. Their feedback mattered. And it went both ways: the more precisely they described what they wanted, the better Claude executed, because they actually understand the code underneath.

My honest take: this process is great for small, single-page sites like this one. The moment you add databases, forms, or anything with real backend logic, you want an actual developer steering that part. And beyond the build itself, Claude ended up doubling as a lightweight CMS, fixing copy, dates, phone numbers, typos, without us needing to build one just for that. A new and pretty fun way to build a website.

If you haven't done so, go check it out at lanuitdeslosers.ch and find all of the fun easter eggs. See you at the event! 😉