At our wedding, each table was named after a country we had either visited or had some relation to, as a personal touch instead of classic table numbers. To complement this, I built a small static website deployed on GitHub pages to learn more about the country with Claude Sonnet 4 through Github Copilot.
Each table had small printed cards with QR codes linking to the webpage that attendees could scan and briefly view. I generated the 17 QR Codes manually for each table through Project Nayuki’s web implementation and renamed the downloaded file to the country. Thanks to them! I figured generating the code to do so would take about the same amount of time. This said, I fortunately didn’t have to ever change the URL of each page.
I then used Microsoft Publisher with Mail Merge for the country names into a table, with a “Learn more about ${country_name}” text on top, then manually inserted the QR codes (which is being deprecated, frustratingly. Microsoft suggests using Word instead, but doesn’t support a page size above 22" that would match a large seating table chart!) I did need to be careful to match the correct QR code in the folder to the right country - but only when writing this post did I think to look up if I can Mail Merge images, so I feel a bit foolish for not even checking.
I printed the cards through Office Max (about the size of business cards, on cardstock). They only offer specific cuts of paper (into 4ths, or halves), so I cut it at home along the borders of the table. They came out nice.
The site consisted of a Schedule (of the event), Story (of our relationship), and Tables index page, which listed all of our named tables based on countries we have visited. Each country-specific table webpage included photos, short text about our visit there, personal trivia about our experience, and interesting facts about the country. All pages included a short quote about marriage as well.
Development was trivial for a set of static web pages with content. Obtaining all of the content took time - collecting photos, writing descriptions and short additional text, searching for and finding all the quotes, coming up with personal trivia questions and fun facts.
I intially thought to use Hugo, since this blog runs through Hugo and I would like to learn more about it, but I could not find a theme suitable, and ran into some early issues trying to adapt and create a theme myself. So I just used vanilla JS and HTML, with no build process, just the Github Pages deployment through the main branch. The Live Server extension was good enough for this project as well.
Organizing the content and sharing it (between Android and Apple phones, to Windows) is irritating; I mainly used Gmail to send the images to myself, then downloaded them (and renamed them to a legible name), then saved the locally to /images folder in the website directory. This was another pain point. We don’t use any cloud storage solution to aggregate our photos across devices.
Since the image file names and the post names, e.g., “mexico.html” and “mexico.png”, Copilot quickly picked up on the naming conventions for the file paths whenever I started a <img> tag, which was nice. I did learn that VSCode allows me to hold shift and drag an image over from the Explorer in Markdown to generate the requisite mark-up, but the same didn’t work in HTML files.
Copilot helped write the only JS function in the site to allow for interactive expanding trivia questions, automatically formatting them to match existing site content styles. I think a simpler option in restrospect would have been the <details> HTML tag, which I didn’t know about at the time.
I would like restrictions on Copilot trying to autocomplete text for you within the HTML - it kept trying to answer the trivia questions as I typed them in, which got annoying. Same for the quotes on marriage as well.
One mistake I made was I didn’t optimize or compress any of the images. While I didn’t have any issues with loading speed at any point and we were in a metropolitan area with 5G, it is something I’ll start with next time.
I explored ImageMagick; I ran magick mogrify -resize 1200x800> -quality 85 -format webp *.jpg *.png in the images folder. It did rotate many of the images, however (apparently phone images store the rotation in metadata, rather than the actual image being rotated), so I had to re-run this and use magick mogrify -auto-orient -strip -resize 1200x800> -quality 85 -format webp *.jpg *.png instead.
A few extra steps: I did need to update the file extensions to .webp with a find and replace, but that takes almost no time with the VSCode Search functionality. I deleted the original images and also the .webp~ backup files as well that were created by default. After the conversion, I did immediately notice how much quicker the images did load. With the conversion, the entire site size was 3.9 MB, measured locally, covering ~20 pages and around 30 photos.
I’m expecting - if they haven’t already, for website builder products to adopt LLM-powered workflows enthusiastically. It is exceptionally quick to build new plausible-looking projects with Agent mode for static content like this. I imagine with the plug-and-play website components will also simplify most of the complexity that would normally hinder LLM-development.
For example, the user doesn’t have to have an LLM code an online store for them, but only insert the <OnlineRegistry \> component into the right block. Configured settings on the backend can manage authentication and security.
For this reason, I wonder if sites like The Knot and Zola can retain their niche, or what non-wedding website hosting sites like Wix, Squarespace, or Wordpress can do to gain wedding couples as clients. Of course, these wedding sites don’t only offer the website builders: the hosting, RSVP system, contact management, registries, wedding planner templates… but all of these are capabilities that other website building companies could offer on a technical level. Will wedding couples seek more personalized websites that are unique, or will the “off-the-shelf” site be sufficient?
So I suppose the wedding content, such as venue or vendor recommendations may be more important? We didn’t use any of these ‘content’ based features; it was the simple website, RSVP management, and probably brand name, that primarily drew us in.
Overall, the ability to create, deploy, and host something fun and custom like this with not many technical steps is great, and I’m curious to see how much easier it becomes in the next few years with LLM-integrations into existing solutions.
If I need something like this again, I’d like to focus on the content up front, putting it into a folder with files, then use Agent mode and see how well Claude can place and format the content while building out the structure of the site itself.