PartyLife Events SaaS

PartyLife Events is an event business focused primarily on weddings. Their biggest problem was that everything lived in three places: the owner's head, her personal notebook, and a Google Sheet. They also run an equipment rental side of the business, so the wedding side needed one source of truth of its own to keep running smoothly as the company grew. They had already tried building something themselves with AI, but they needed it to look and work well in practice. That is where I came in. They needed something usable as soon as possible, with any extra features added later. So I got to work.

01 / 02

← →

During interviews I had Granola take notes so I could focus on listening, asking follow up questions, and writing down only the things that really stood out.

After the survey and interviews, I cross referenced all of the data to find the recurring issues and get to a problem statement. The core problem: there was no shared system for planning a wedding from end to end. PartyLife Events' wedding planning process runs on one person's memory. The owner holds client details, decor vision, and vendor info in her head and a personal notebook. There is no structured way for that information to reach the person who actually builds out the event, so it arrives late, or wrong, or not at all. From there, every wedding starts from zero: a brand new spreadsheet, rebuilt by hand, to plan out decor and room setups.

With the problem established, I wrote the PRD, and from the PRD I built the sitemap and user flows. Alongside that I did market research for inspiration and feature comparison using the Mobbin MCP connected to Claude. Everything Claude produced was saved back into Obsidian for documentation. Linear held the tickets and acted as a second source of truth, also connected through MCP. The sitemap and user flows were built in FigJam with Claude through the Figma MCP. Now it was time to design.

Now I could design. I took everything gathered in Define, put it into a single prompt for Claude, and asked for 3 low fidelity iterations of every required page. Once those generated, I picked what I liked and did not like from each version of each page and built a final design. I worked through it out loud with Granola recording for each set of iterations, then had Claude pull that recording, plus my written notes, to produce the final version. That gave me final designs for the global screens and the event workspace screens. I still did manual work on top to get spacing and hierarchy right. A few extra screens were needed to bridge gaps in navigating the tool, so I ran those through the same process.

01 / 03

← →

Color took a few passes. I wanted the brand present, but people will be in this tool all day, so it needed enough contrast for accessibility without straining anyone's eyes, and it needed to read as professional. I did the same for the dark mode I created. Both stay on brand per the design system I was given. Mobile access seemed useful for the day of itinerary so everyone stays on the same page. It was not built out either, so instead the tool will send a text or email with a PDF of the full itinerary. This one may get skipped entirely.

A client view would let couples follow the planning process. The stakeholders pushed back: they do not want clients that involved, because it generates more questions. So rather than a view, clients get emails and texts, the same approach as the team. This may also get skipped entirely. And I added onboarding so there is a defined first experience when someone creates an account. After those changes I cleaned up the files and fixed small visual issues. Claude handled a lot of the manual work throughout and moved me faster, but I checked behind it every time to make sure things landed correctly. I used Wispr Flow to prompt faster, since I can talk faster than I type. Then I explored the motion and behavior I wanted in the tool. Most of that could not be properly tested until Deliver, once it was converted into code. So it was time to deliver.

With everything as polished as it could get in Figma, I shared the Figma file with Claude Code in the Cursor chat window and asked it to build the project in code. We wanted to ship quickly, so the stack is Next.js, React, TypeScript, Lucide, Tailwind, Shadcn/UI, and Supabase. That is a stack a product designer like me can manage directly before handing it to an engineer, if it ever needs one. Once the repo existed I pushed it to a private GitHub repo and opened a localhost server in Cursor to see it running. Plenty of things did not translate cleanly at first, but feeding the Figma file back through the Cursor chat cleaned most of it up. From there I kept testing and polishing with Cursor's design mode.