// Overview · Case study 01

PartyLife Events SaaS

PartyLife Events is a wedding focused event business. I designed an internal tool that gives their team one source of truth for planning a wedding, from the signed contract to "I do."

Role

Product Designer / Design Engineer

Timeline

1 month

Team

1 designer and engineer, 3 stakeholders

02 · At a glance

One month, four phases, one designer and engineer working with three stakeholders. It went from a survey to a running build on Supabase.

// Discover · 03 to 06

Discover

Tools

Claude
Granola
Obsidian

03 · The notebook, the head, and the spreadsheet

Every wedding lived in three places: the owner's head, her personal notebook, and a Google Sheet. Only one person could read all three, and the wedding side needed a source of truth of its own as the company grew.

04 · Their first try, with AI

They had already tried building something themselves with AI. It looked the part, but it needed to work well in practice. They needed something usable as soon as possible, with extras added later.

05 · Survey first, then listen

I surveyed the three stakeholders first for quantitative signal, then interviewed them to learn why they answered the way they did. Granola took the notes so I could listen. Claude and Obsidian, connected through MCP, turned the notes into a problem statement.

06 · Same pain, worse with distance

Three people rated the same pains from one to five. The owner, who holds it all, gave every one a 1. The highest score anyone gave, a 4, came from the person who has to ask someone else for the answer.

// Define · 07 to 11

Define

Tools

Claude
Obsidian
Figma
Linear
Mobbin

07 · No shared system

There was no shared system for planning a wedding from end to end. The owner held client details, decor vision and vendor info, and none of it had a structured way to reach the people building the event. It arrived late, or wrong, or not at all.

08 · Where it breaks

The spreadsheet worked for planning but was never built to travel, and the cracks showed on event day. One forgotten piece of decor meant a 90 minute round trip mid celebration. Crews stalled between tasks, and takedown started before the event ended.

09 · Thirteen themes, sorted by cost

I sorted thirteen recurring themes by the effort to fix each one against the cost of its failure. The cheapest fixes landed on the most expensive failures. Two of the highest-impact answers were to build nothing at all: no client portal, no integration.

10 · Success, defined before design

The PRD set success before any design: seven metrics, each with today's baseline and a target for the pilot. One guardrail outranks all of them. If the notebook comes back for any step, that step failed.

11 · Two workspaces, one map

Two navigations, not one: a planner workspace across every wedding, and an event workspace inside a single one. Five features were considered and cut before a screen was drawn.

// Develop · 12 to 20

Develop

Tools

Claude
Obsidian
Linear
Figma
Wispr Flow

12 · Three versions of every screen

I put everything from Define into one prompt and asked Claude for three low fidelity takes of every required page. Then I picked what I liked and didn't from each.

13 · Then one

I talked through each set out loud with Granola recording. Claude merged that recording and my notes into one final version, and I fixed spacing and hierarchy by hand.

14 · A brand kit, checked

PartyLife already had a brand kit, so I checked it instead of building a system. Every pairing passed except terracotta on small text, at 3.7:1. So anything under 18px moved to Terracotta Deep, at 5.1:1.

15 · Six colour directions

Colour took a few passes. People are in this tool all day, so the brand had to be present without straining anyone's eyes, and it had to read as professional. Direction B, a white canvas with the brand held back, carried forward.

16 · Dark, three ways

Dark mode got the same treatment, three ways. Version two went flat, with hairlines doing the work. Version three added a canvas, chrome and surface ladder underneath, so depth carries meaning instead of decoration.

17 · Tabs and wedding colours

Tabs work like Chrome tabs, so the team can jump between weddings quickly. Each wedding's colours sit near the bottom of the left pane, so they stay in view while you work.

18 · Wired end to end

With colour settled, I applied it to the final wireframes to make the high fidelity screens. Then I wired a full working prototype with Claude, checked it over, and took it to the team.

19 · Saved for v2

The review surfaced three ideas that waited. The right pane wasn't built out the right way yet. Mobile became a PDF itinerary sent by text or email, and the stakeholders turned down a client view because it would invite more questions. Tabs, wedding colours and onboarding made it in.

20 · Thirteen motion specs

Then I specced the motion and behaviour I wanted, thirteen specs in all. Most of it couldn't be properly tested until it was code.

// Deliver · 21 to 32

Deliver

Tools

Claude
Obsidian
Linear
Cursor
Claude Code
Next.js
React
TypeScript
Lucide
Tailwind
Shadcn/UI
Supabase
Vercel

21 · Figma into a running build

I shared the Figma file with Claude Code in Cursor and asked it to build the project. Whatever didn't translate cleanly got fixed by feeding the Figma file back through, and Cursor's design mode handled the polish.

22 · Version three

These screens are the third version. I redrew them after testing the interactions in code, because running the build told me things the static file couldn't. Both themes are drawn in full. Light is the default, and dark sits behind a preference.

23 · Every wedding, one roster

Home is a roster across every wedding, with what's overdue at the top. Tasks pool across events, so no piece of work lives only inside one wedding.

24 · One library

Vendors, venues, decor and contacts live in one library that every wedding draws from. Venues fill themselves from each event, so nobody types the same venue twice, and a new wedding no longer starts from zero.

25 · Inside one wedding

Inside a wedding, everything that used to live in one person's head has a place: an overview of days out, milestones and tasks, and every vendor by booking stage.

26 · Decor, built as structure

The decor sheet was rebuilt by hand for every wedding, but its structure was right. So the tool keeps that structure: rooms first, then what goes in them, with the wedding's palette beside it.

27 · Who owns what, on setup day

Nobody knew what they owned on setup day, so coverage puts a person on every area. The itinerary runs from load in to takedown on one timeline, so takedown has a time instead of a guess.

28 · The venue, in place

The hand-drawn room plan from the notebook becomes a floor plan, with zones and placed elements. Venue rules check every placement, so an open flame indoors is flagged before setup day. These two screens are from version two.

29 · The edges, designed too

Onboarding, the first run, an empty list and a failed save were each designed, not left to chance. When something doesn't save, the tool says so on the thing that didn't, right where the retry is.

30 · Find anything, undo anything

Search reaches across every wedding at once, and change history shows who changed what, and when. Details stop going quietly out of date.

31 · The stack changed once

The first build shipped on HTML, CSS, JavaScript, Supabase and Vercel, because I could hold all of it myself. I rebuilt it on Next.js, React, TypeScript and Tailwind for better performance. Supabase and Vercel carried straight across, and the old build is still archived in the repo.

32 · Where it stands

Supabase is wired up: every core domain, behind row level security, with Google and email sign in and file storage. Several people from the same business can sign in, and each sees only their own events. The November pilot has to prove the rest: forgotten items down to zero, interruptions down to three or fewer, and sixty days of handoff lead time.

Don't introduce too many new features once you're in high fidelity: one or two at most. And run more than three iterations, because I don't know what I want until I see what I like and don't. Somewhere between three and five is where I'll land.

View live demo