nickisnoble/hygge_quest_public

README

This is a time capsule of the app I made for my wedding in 2024.

I built it because:

Most wedding website builders suck, and none of them had the features I wanted.
It was a themed wedding, and the RSVP flow was the first impression of it guests would see.
I wanted to.

There's more on each point below, but that's the gist. But first...

Warning

There be dragons here

This was made by a nerd, for a nerdy wedding.

It has no intention of being a polished product, nor even a "good" one, past what it was made for – because it was always intended to be short lived.

There are minimal tests, the code is often strange or hastily written, and 99% of the content is written in HTML.

hygge_quest_public/app/controllers/concerns/dungeon_master/cerberus.rb

Lines 1 to 9 in 41d8ecc

    
           module DungeonMaster::Cerberus 
        
             extend ActiveSupport::Concern 
        
             included do 
        
               layout "dungeon_master" 
        
               before_action :require_user! 
        
               before_action :require_dm! 
        
             end 
        
           end

But in the end, it ended up being useful, and unique. I really like how it looked and worked, and showing it to people, they say it could be quite useful to others.

I'm sharing it with you for three reasons:

I want to show it off, even the rough bits!
In case it's useful for your own nerdy wedding. Feel free to use it as a base, and expect to rip out the parts you don't need.
To demonstrate that homecooked software can be useful, even if it's just for your friends and family, and just for a short time.

Design & functionality

Our wedding was fantasy TTRPG themed. Think Dungeons & Dragons, The Princess Bride, Game of Thrones, Zelda. We also wanted everyone to dress up and feel like they were part of our story.

Many of our guests were familiar, but some we knew would feel a little like fish out of water. We wanted to recreate and share some of the magic of playing these games (which is how we met) for people who maybe never played, and make our guests feel welcome.

So this site was a way to get the information we needed, but also start seeding "the vibes" early on.

Guilds

So in addition to the normal RSVP stuff, like food preferences, we asked people to choose a "guild".

This is somewhere between a D&D class, a Hogwarts house, or an Astrological sign – something anyone can grok immeditiately, feels somewhat authentic to themselves, but gives the feeling of being part of a larger fantasy world.

Guilds also helped with clothing, since we asked people to dress up – for folks who'd never been to renn faires or comic cons, this was a way of helping them not have to start from scratch.

You'll see in the app that there's apparatus for "looks" aka inspiration we pulled / generated for various fashion ideas, matching the colors and themes of each guild. It wasn't a costume party per se, we just wanted to do something different than regular suits and dresses.

Parties

Note

The big thing I found lacking in almost all wedding websites is a way to manage one's group of guests.

What we found was some combination of:

A guest list that's just a list, like a spreadsheet, but in a shitty CMS, and you can't control the fields.
As a guest, you put in your own name, but everyone else is listed as "plus one" or "guest", and details like allergies need to be stuffed awkwardly into one text field.
Every guest needs to have a login (because evil data extraction), and enter their own data, one person can't simply RSVP for their family.
If you want to decline the RSVP, you have to enter a ton of info anyways.

And even worse, most of these services (like Zola, etc) are designed to extract and sell not just your data, but your guests' data, to marketers. I wasn't interested in selling my guests personal info for the sake of having a "free" wedding website, with inferior features, and a basic bitch aesthetic.

For most people, when they get an RSVP in the mail, there's someone in the family who's the calendar keeper, and they want to just handle it! They know their kid can't eat gluten, the other is away at college and can't make it, and their spouse wants the steak, not the chicken.

So our app works like that:

One person can RSVP for their entire party, and it happens automatically (a party is created for them on the initial RSVP).
If they RSVP yes (for the group), they make their own choices with a large UI, so that they get very familiar with the options. Then they can add everyone else with a quick entry UI, and anyone with an email address in the system now can login themselves and make changes later if they want. ¹
If they RSVP no (for the group), we know who they are and can infer their family isn't going. They get a field to leave a note, that's it, no need to enter everyone else.

Everything on that page autosaves, and if someone tries to RSVP again, it just redirects them to the step they were on.

Actual Features

Automagic login. No inital sign-up, "it just works."
Not every guest needs to have a login. Party members can manage other members of the same party.
Staggered deadlines for waves of RSVPs, automatically locks changes for parties at deadline.
Private and shared notes for hosts for each party and guest.
Email broadcast system for hosts to send to guests, in part or in whole.
Admin view including crud for guests, the ability to send said emails, and basic stats, eg total guests, breakdown by attending, total count of each meal option, etc.
Map view, automatically drops markers based on address (uses geocoder to get lat/lng).

Unimplemented

These were features I wanted to add, but didn't have time to finish before the wedding:

A "quest" system for guests to complete before the wedding, allowing them to earn XP and achievements. (Sort of a fun way to identify things to do in Baltimore for guests arriving early, or sightseeing in the area). This was simplified to just a map view, with a few locations marked.
A full PWA experience, with photo modes, etc. (You can install the app, but all it is currently is a custom icon and caching.)

Caution

LICENSING

You'll note there's no license on this repo.

TL;DR: I didn't know what license to use for what I wanted.

You can use or learn from this code to build a site for yourself or a friend's wedding
You cannot fork this into a commercial product.
Most of the images on the site were generated with AI, and I'm not sure what license they're under. If you use this site as a template for your own, you must replace them! Said another way, feel free to use the code, but content must be replaced.
- Background images were generated with Dalle, using a custom GPT for consistency. (Feel free to use it if you'd like!)
- Fashion / character images on the guild pages were mostly generated with Lexica. (Stored in S3 anyways)
- Open Graph images were made using a combination of the above and Figma.
- The lantern / seal is not included under any license with the software. That is ours!

Technical Notes

This is a Rails app, with this general stack:

Rails 7.1
SQLite for database (see below for why!)
TailwindCSS for styling
Hotwire / Turbo / Stimulus for frontend interactivity
ActiveStorage + S3 for file uploads (minimal)
Resend for email
Passwordless for login
Leaflet for mapping, FontAwesome for icons, both client-side only
Render for hosting

SQLite?!

This is the nice thing about a wedding app: you know exactly how many guests you have, and the days when you'll have the most traffic. At maximum, this app had 120 users (though many fewer on any given day, and not everyone responds when you send out RSVPs).

SQLite is fast and easy, but better yet, it's a file that I can archive – a perfect time capsule for the data from our wedding.

Running the app

Locally

Clone the repo
$ bundle install
$ bundle exec rails db:migrate
$ bundle exec rails db:seed (You'll want to adjust the seed data to make you and your partner the hosts)
$ ./bin/dev

On Render.com

Push the repo to github
Configure a render project for it
Set the environment variables (see .env.example)
Add a disk for sqlite (see SQLite note above and start command below. This creates some limitations around deploys, but it's way cheaper than a Postgres instance)
Deploy via push!