Vow & How

The Brief

Planning a wedding means juggling spreadsheets, half a dozen apps, and a constant stream of guest questions. On top of that, most couples want a wedding website for guests to RSVP, view the schedule, and share photos. I ran into this planning my own wedding and could not find a tool that did both properly, so I built one.

Vow & How gives couples a single admin dashboard to manage their whole wedding, plus a guest-facing website on their own subdomain that pulls from the same data. Guests, RSVPs, budget, vendors, seating, timeline, registry, and song requests all live in one place.

The Challenge

Two things had to be true for this to be worth building. First, the admin side needed to actually replace the spreadsheet mess, not add another tab to it. Second, the guest side needed to hold up on the wedding day itself, when hundreds of people might hit it at once from mobile networks to upload photos and check the schedule.

The second part is where most DIY wedding sites fall over. A quiet planning tool is easy. A guest site that stays fast while eighty people upload photos at the same reception is a different problem.

The Approach

I built it as a multi-tenant SaaS from the start, not a per-couple bespoke site. Each couple signs up and gets an automatically provisioned subdomain ({couple}.vowandhow.com) that serves their guest site, with the option to point a custom domain at it later. All couples share one application, one database, and one deployment. That decision shaped everything else.

The stack is a React frontend and a Laravel API-only backend, MySQL for the data, Cloudflare in front for DNS and DDoS protection, and Coolify managing deployment on a VPS. Wildcard DNS handles the multi-tenancy. AWS S3 stores guest photo uploads, and AWS Lambda handles the heavier one-off jobs like generating zip archives of all photos on demand.

The rule I kept coming back to was: keep the application server out of the hot path on the wedding day. Anything guests do at scale should route through infrastructure that was built to handle it, not through my Laravel app.

The Build

Couples get an admin dashboard covering the full planning workflow: guest list management, RSVP tracking, budget, vendor contacts, seating plans, timeline, registry, and Spotify-integrated song requests. On top of that, they get a live guest-facing website on their subdomain, styled from templates and pulling from the same underlying data.

Billing is subscription-based across three tiers (Starter, Premium, Ultimate), gated by feature access rather than usage caps.

Custom domain support means couples on the higher tiers can white-label the guest site to their own URL, with the platform handling the routing transparently.

Key Technical Decisions

A few decisions are worth calling out because they materially affect how the platform performs on the day it actually matters.

Presigned S3 uploads for guest photos. When a guest uploads a photo from their phone, the file goes straight from their browser to S3 using a short-lived presigned URL. The Laravel app is only involved in issuing the URL and recording the resulting object reference. This means the application server never touches image bytes, and hundreds of guests can upload simultaneously without any load on the app itself. On the wedding day this was the difference between a working platform and a crashed one.

Lambda-based zip generation with caching. Couples eventually want to download all their photos. Doing this in the Laravel app for a wedding with several hundred images would either time out or hammer memory. Instead, “download all photos” triggers a Lambda job that streams the photos from S3, builds the zip, and stores the result back in S3 for delivery. The first run costs roughly $2 in Lambda time. Subsequent downloads are served from the cached zip and are instant. Cost stays low, users get a fast experience.

Per-tenant data isolation across the schema. Around 17 tables hold couple-scoped data. Every query is scoped by the current tenant at the query level, and the routing layer resolves the tenant from the subdomain before any controller runs. This keeps the multi-tenant model simple to reason about and closes off the class of bugs where one couple’s data could accidentally leak into another’s dashboard.

Wildcard DNS with automatic subdomain provisioning. New signups get a working subdomain immediately, without me touching DNS or the couple waiting for propagation. Custom domains layer on top of this once a couple chooses to point their own URL at the platform.

The Result

Vow & How ran my own wedding in production in April 2026 as themartinwedding.co.za. Eighty guests used the RSVP flow, browsed the schedule and details on their phones through the reception, and uploaded around 650 photos live during the day. The application server stayed quiet throughout, because by design it was not in the upload path.

The platform is live and open for signups. Early users, mostly wedding guests interacting with the RSVP and photo upload flows, described it as easy to use with no explanation needed, which is the strongest thing you can hear about software that has to work on someone’s wedding day.