Skip to content →

Wedding Website

On July 7, 2012, I asked my then-girlfriend-now-wife to marry me. As we planned our wedding over the course of the next ten months or so, we decided to build our own website. It would of course be something that would be deeply personal, but we also wanted something that would be functional.


We wanted a place to show off some of the pictures taken by our wonderful photographer Emily, to present some information about who we were as a couple and how we met, and to function as a digital RSVP and guest communication system (so that we wouldn’t have to worry about managing paper invitations). And, as I had been itching to do some sort of software development project, it would be a fantastic learning experience and the first major web project I had undertaken since Xhibitr.

Like with Xhibitr, this site was built using the web framework Django and the jQuery Javascript library. Unlike with Xhibitr, this time, I hosted the site on my new WebFaction server (something which resulted in a lot of painful, tedious migration work from my last host).

For the design, we picked a fairly simple, but elegant layout: a combination of white with a few flourishes of color fitting the peach theme we had wanted for our wedding, and some light touches like hover-over effects for the menu items and a heart-shaped breadcrumb system to show the user which webpage they were currently on:

For the mini-photo slideshows, I used a fantastic pre-built tool called BXslider (I had begun building one myself but didn’t feel like reinventing someone’s already awesome wheel) which included a nice cross-fade transition (and a ton of other features).

As I mentioned above, the backend was built using Django. This made it easier to keep all the sites consistent (by using Django templates and template inheritance) and it also let me set up a very basic login system which revolved around giving each invited guest a unique codeword.

I also created a system of “secret” URLs which would allow guests to bypass this authentication flow. Then, using Django’s email functionality, I sent an email to each invited guest with both their codeword and “secret” URL … and waited.

Upon logging in for the first time, a user would be faced with an interactive RSVP form (built using basic jQuery), which would prompt the guest to enter food preferences for themselves and their guest(s):

After completing the form, the server would show (and email) a note confirming the guests and their food selection, as well as inviting the guest to browse through the additional information that only logged in invitees could see (detailed logistics information, information on the block of hotel rooms, etc.)

While this approach to setting up the website was clearly more complicated than just hosting a pre-templated website on TheKnot or another wedding hosting service, there were significant benefits to building our website in this way. It let us add a personal touch, letting us “suggest” guests if we knew who a person’s significant other/spouse was and provide specific information only to the relevant guests (i.e. the wedding party seeing wedding party-specific scheduling items). By leveraging Django’s administrative console, this approach also made it possible to track, in real time, who had “opened” the invitations, who had completed them, who was coming, and what food needed to be prepared. It also dramatically simplified communication with guests, allowing us to send emails to specific groups programmatically (i.e. all members of the wedding party bringing a guest, all invitees who have opened the RSVP but have yet to submit their answer, etc.).

The result was a website ( which not only let us express our identity as a couple, but played a key functional role in our wedding planning, and let me flex my developer muscles once more :-).

If I had a little more time/if I ever revisit this codebase, I’d probably build a few additional pieces:

  • Mobile-optimization: With so much of the world visiting websites on their tablets and smartphones, adding a bit of responsive web design would probably have been a smart idea
  • A more general purpose email form: I built a very crude system to send emails and invitations to guests which required me to hardcode the email messages being sent.
  • Ability for guests to edit their food selection after submission: This omission was due to time constraints around building something which worked as fluidly as my RSVP submission form.

All in all, I was very happy with the result and the experience picked up from doing it.

%d bloggers like this: