I "Vibe Coded" my Wedding Website

Overview

My wedding website started as a personal project, but it quickly became much more than that. It was something my fiancee and I would actually rely on, and it was going to be used by around 200 guests in a very real, time-sensitive way. That alone made it more serious than a typical side project.

At the same time, it became one of my clearest experiments in agentic coding. I leaned heavily on Claude Code throughout the build, using it not just for isolated snippets, but as part of a much more guided workflow. Even though a lot of the project was “vibe coded” in spirit, the quality of the result still depended on structure, direction, iteration, and careful review.

That combination is what made the project so interesting to me. It was personal, production-facing, and a genuine test of what an agentic workflow could produce when the stakes were real.

Why This Project Mattered

This project felt different from most of the websites I had built before because it was both personal and operationally important. It was not just another portfolio piece or freelance build. It was something my fiancee and I would depend on to communicate with guests, collect RSVPs, and stay organized in the lead-up to our wedding.

That raised the bar immediately. For the first time, I was building something that would be actively used by a few hundred real people within a relatively short window. Most of them would not care how the code was written, what stack I used, or how interesting the implementation was. They just needed the site to work, especially on mobile, and they needed it to be clear and easy to use.

Because of that, I treated the project much more seriously than a typical personal site. Reliability, usability, and operational support mattered just as much as design and development.

Goals of the Site

From the beginning, the site had a clear job to do. It needed to provide wedding information in a way that was simple, clear, and easy to access. Since many guests would be checking details from their phones, it also needed to work especially well on mobile.

Beyond that, the site needed to support RSVPs smoothly and give my fiancee and me a practical way to manage guest information behind the scenes. That meant building more than a public-facing website. It also meant creating admin workflows that would actually be useful during the planning process.

Communication was another major goal. The site was not just a static information page. It needed to support guest tracking, email broadcasting, and the kinds of operational tasks that come with managing a real event. In other words, it had to function more like a lightweight product than a simple wedding microsite.

My Agentic Coding Experiment

This project became one of my most serious experiments in fully embracing an agentic coding workflow. I relied heavily on Claude Code during development, but not in a random or one-shot way. The process worked because I treated context and direction as part of the system.

What interested me most was seeing how far this style of development could go when paired with real constraints. The project had real users, a clear deadline, and actual consequences if pieces of the experience were confusing or unreliable. That made it a much better testbed than a toy app or throwaway prototype.

The biggest takeaway was that agentic coding is not really about handing over the wheel. It is about shifting your role. Instead of spending all your energy typing every line manually, more of the work moves into framing the problem clearly, providing the right context, guiding implementation, evaluating outputs, and tightening the result through iteration.

How I Guided Claude Code

A big reason the workflow worked as well as it did was that I did not treat Claude Code like a magic box. I tried to be deliberate about how I guided it. That meant providing context clearly, breaking work into manageable tasks, and using structured supporting materials like skills.md to improve the quality and consistency of output.

That structure mattered a lot. The difference between getting something useful and getting something messy often came down to how well the task was framed. The better the context, the better the output. That became very obvious as the project evolved.

I also did a lot of iteration instead of accepting outputs blindly. I would review what was generated, refine the direction, break apart problems, and keep tightening things until the result felt right. In that sense, most of the quality did not come from one-shot generation. It came from guiding, reviewing, and refining the process over and over again.

Exploring Design With AI

One of the most interesting parts of the project was using AI for design exploration. Rather than asking for a single design and treating it as the answer, I used Claude Code and the frontend-design skill to generate a wide range of possible directions.

At one point, I had it generate 15 unique design directions for the site. That completely changed the design process for me. Instead of starting from one concept and trying to force it into something good, I could look across multiple strong options, identify the pieces I liked most, and combine ideas from different versions and routes.

That made the process feel less like asking AI for a solution and more like curating and refining a set of explorations. It sped up ideation, but it still depended heavily on taste, judgment, and iteration. The value was not that AI picked the design. The value was that it helped produce multiple viable starting points much faster than I could have on my own.

Core Features I Built

The final project ended up being much more than a simple information site. One of the core pieces was a custom RSVP system that let guests respond smoothly without friction. Since this was such an important part of the experience, it had to feel simple on the surface while still supporting the data and workflows happening underneath.

I also built a custom authenticated dashboard for my fiancee and me. That gave us a way to manage guest information directly, track responses, and work with the site as an operational tool rather than just a public page. On top of that, I added guest import tools and an email broadcasting system to make communication easier.

Supabase played an important role in supporting the data side of the project, especially for auth and guest management flows. All of those features pushed the website beyond what people usually imagine when they hear “wedding website.” It became a purpose-built application for managing a real event.

Building for Real Users

One of the reasons this project was so valuable was that the user group was clearly defined and very real. Around 200 guests would be using the site, and many of them would be accessing it casually from their phones. That made product thinking much more important.

When you know exactly who your users are, your priorities sharpen quickly. Developer elegance starts to matter less than clarity, responsiveness, and ease of use. I found myself thinking much more about how non-technical people would actually experience the site: how quickly they could find information, how clear the navigation felt, how simple the RSVP process was, and whether the whole experience felt smooth.

That mindset changed the project. It was not enough for the system to work technically. It had to feel effortless for people who were never going to think about the implementation at all.

Mobile-First Performance and UX

Mobile-first design was one of the most important decisions in the project because it matched how guests were most likely to use the site. I expected the majority of traffic to come from phones, so layouts, interactions, and content hierarchy all had to work with that assumption.

That influenced a lot of design and engineering choices. Pages needed to load quickly, content needed to be readable without friction, and important actions like RSVPing needed to feel smooth and obvious. I also experimented with caching strategies to improve responsiveness and reduce unnecessary waiting, especially around data-heavy or repeated interactions.

This project reinforced how important it is to optimize for the context users are actually in. A polished desktop experience is nice, but for this site, mobile usability was the real priority.

Reliability, Monitoring, and Testing

Because the site would be used actively by real people in a short, important window, I treated reliability much more seriously than I might on a casual personal project. I integrated Sentry for observability because I wanted visibility into issues if something went wrong once the site was live.

I also spent more time testing than I normally would on a purely experimental build. That included thinking through guest flows, admin workflows, edge cases, and how the site behaved under real-world usage. When the users are your family and friends, and the event matters personally, the pressure to get it right feels different.

This part of the project reminded me that even a personal build can benefit from production habits when the stakes are real. Monitoring, QA, and reliability are not just for large apps or professional client work. They matter anywhere people are counting on the system.

What This Taught Me About Agentic Coding

The biggest thing this project taught me is that agentic coding can move very fast, but quality depends heavily on guidance. AI can be extremely effective for exploration, implementation speed, and iteration, but that does not reduce the need for human judgment. If anything, it increases the importance of direction and review.

I found that the role of the developer shifts in a meaningful way. The work becomes less about manually producing every line and more about framing goals, maintaining context, evaluating output, integrating systems, and deciding what is good enough to trust. The better those inputs are, the better the results tend to be.

This project also showed me that “vibe coding” works best when there are real constraints behind it. Clear goals, active review, real users, and production expectations all helped sharpen the process. The results could be impressive, but trust still had to be earned through testing.

Challenges and Tradeoffs

The biggest challenge was that fast AI-assisted development creates a different kind of pressure. You can move quickly, but you also generate more surface area to verify. That means speed comes with a responsibility to review more carefully, not less.

There was also the challenge of combining personal importance with technical experimentation. Because it was my own wedding website, I cared about the outcome on a completely different level than I would for a typical test project. That made the project more meaningful, but it also added pressure.

On top of that, the site ended up being more complex than a typical wedding site because of the RSVP logic, admin dashboard, guest data handling, and email workflows. Design exploration with AI was powerful, but it still required decision-making and consistency work afterward. In many ways, the project was a balance between acceleration and discipline.

What I Learned

This project taught me how much context quality matters in AI-assisted development. The better the structure, the better the output. It also taught me that design iteration changes a lot when AI can generate many valid options quickly. That creates more opportunity, but it also makes curation and taste more important.

I also learned how sharply real users can focus your thinking. Once I knew a few hundred guests would actually be depending on the site, every decision became more practical. Performance, clarity, and reliability mattered more than cleverness.

More than anything, I learned that personal projects can still be some of the most demanding and meaningful builds. In some ways, this was more operationally real than many other websites I had worked on because the user group, timeline, and expectations were so clear.

What I Would Do Differently

If I were doing the project again, I would probably document the agentic workflow more deliberately as I went. A lot of what made it successful was repeatable, and capturing that process more clearly would make it easier to reuse on future projects.

I would also tighten parts of the codebase after the rapid iteration phase. Moving fast was valuable, but projects built with heavy iteration always leave room for cleanup, standardization, and making certain systems more reusable.

On the product side, I think there is also room to further refine some of the admin and guest management flows. The site worked well for its purpose, but there are always small experience improvements that only become obvious once a real workflow is in motion.

Final Thoughts

This project started as a wedding website, but it ended up becoming one of the most meaningful technical experiments I have done. It combined personal importance, real users, and a serious test of agentic coding in a way that made the whole experience feel much more substantial than a typical side project.

It showed me that an agentic workflow can produce strong results when it is guided carefully, tested properly, and held to real standards. It also reminded me that personal projects can still demand production-level thinking when the stakes are real.

In the end, it was not just a website for our wedding. It was a real product, a real workflow experiment, and one of the clearest examples I have had of how fast development can move when AI is used as an accelerator instead of a substitute for judgment.