{"id":31472,"date":"2025-07-09T11:00:04","date_gmt":"2025-07-09T10:00:04","guid":{"rendered":"https:\/\/www.intercom.com\/blog\/?p=31472"},"modified":"2025-07-09T11:00:04","modified_gmt":"2025-07-09T10:00:04","slug":"notes-from-a-product-design-vibe-coding-hackathon","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/notes-from-a-product-design-vibe-coding-hackathon\/","title":{"rendered":"Notes from a product design vibe coding hackathon"},"content":{"rendered":"

In May 2025, the product design team at Intercom came together for a hackathon in our London office.<\/p>\n

Folks flew in from as far afield as Dublin, Barcelona, Amsterdam, Chamonix, and Merseyside. Our org has 30+ product designers sprinkled across the UK and Europe, so it\u2019s always special to meet up in person.<\/p>\n

Our mission: build an Intercom-related feature, product, webpage, or experience using nothing but AI. We could experiment with any number of tools, like Lovable, Windsurf, Replit, or Cursor. The goal was to choose a project, choose an AI tool, and build something usable \u2013 fast.<\/p>\n

<\/p>\n

Our team brief, built with AI, set the tone for the hackathon.<\/em><\/p>\n

 <\/p>\n

I teamed up with Daria Vorontsova<\/a> and Tanya Ermolaeva<\/a>. We wanted to build a new website for \u201cIntercom Design\u201d \u2013 a single space for all things design at Intercom, where our team could share case studies, inspirations, and thought leadership with the world. This was the perfect opportunity to start vibe coding and see where it took us.<\/p>\n

In the end, we were able to spin up an initial version of the Intercom Design<\/a> website in just over a day, and set it live shortly after. Here\u2019s a look at our process and what we learned along the way.<\/p>\n

From nothing to something: The AI \u201cah-ha!\u201d moment<\/h2>\n

We wanted our site to be a metaphor for the messy canvas that design teams often operate in. Inspired by portfolios from Alec Babala<\/a> and Yeji Seo<\/a>, and collaborative tools like FigJam, we decided to build a \u201cdesktop collage\u201d experience that encouraged people to roam around and explore our content.<\/p>\n

We jumped straight into Lovable and spent time crafting a long, detailed prompt. We were hoping to \u201cone-shot\u201d our creation \u2013 in other words, get the bulk of our prompting right the first time, then refine it bit by bit. Our master prompt was two pages long.<\/p>\n

We dropped it into Lovable, sat back, and waited.<\/p>\n

<\/p>\n

Our prompt for Lovable was deep and detailed (or so we thought).<\/em><\/p>\n

 <\/p>\n

Eventually, Lovable returned its result: a simple canvas-style website containing a collection of content blocks. This was too good to be true. From nothing to something, just like that!<\/p>\n

When AI’s confidence outpaces its capabilities<\/h2>\n

But then we realised the blocks on the canvas weren\u2019t draggable, even though our prompt had specified this. And the canvas wasn\u2019t scrollable \u2013 something else our prompt had specified. Everything was static and locked in place, so we asked Lovable to fix these problems.<\/p>\n

Soon, we were confidently informed: \u201cAll content blocks can now be dragged and the website is fully scrollable.\u201d But neither of these things were true. And, as it turned out, no amount of re-prompting could guide the LLM to fix this.<\/p>\n

Updating scrolling and dragging rules seemed like small tweaks in the grand scheme of things, yet every time we asked for these updates, Lovable would rewrite huge chunks of code. In doing so, it would alter other areas of the site we didn\u2019t want to change.<\/p>\n

We began to realise that unique interactions \u2013 like endless scrolling on a canvas \u2013 are not what an LLM \u201cexpects\u201d a website to do. Lovable would try to execute our prompts, but something would always be off: the scroll speed would be wrong, the canvas borders would be incorrect, objects would be too big or too small.<\/p>\n

The technical behavior we desired was challenging to capture in a prompt, without getting help from an engineer. We realized that MCPs were probably the best way to reach our desired UI, but by that point we were running out of time.<\/p>\n

Done beats perfect: Calling it at MVP<\/h2>\n

We agreed to draw a line in the sand and step away from our laptops. The website didn\u2019t work perfectly and it didn\u2019t look beautiful. But, as an MVP, it was done and it existed. We\u2019d built a basic site in a handful of hours and had something real to share with the hackathon crew.<\/p>\n

<\/p>\n

Four hours in Lovable gave us something messy \u2013 but it worked.<\/em><\/p>\n

 <\/p>\n

To close the day, all product designers reconvened to show off their creations. When we all voted for our favourite ideas, the Intercom Design website came out on top.<\/p>\n

Our thoughts: Yay, we got first place! Oh no, now we have to actually launch it!<\/p>\n

Choosing the right AI tool for the job<\/h2>\n

Over the next two weeks, in small focused bursts, Daria, Tanya, and I continued refining our prototype.<\/p>\n

First, we decided to switch tools. Lovable had got us this far, but now we made a conscious switch to Cursor. There was no way to migrate from Lovable, so we built our site again from scratch. This was time-consuming but once it was done, things felt faster by comparison.<\/p>\n

In Lovable, we\u2019d been using libraries in React, but our site didn\u2019t need ready-made components like toggles or cards. Cursor gave us Vanilla JS instead, with no need for external libraries or frameworks. This helped us move quicker.<\/p>\n

Second, we kept refining the design. Piece by piece we made improvements:<\/p>\n