The wedding app, part 2: forking our wedding into a product

Four days into building our own wedding app, I wrote a new design spec with one sentence that reframed everything: the guest features are the product. Other couples want the guestbook, the live album, the slideshow wall. They don’t want to hire me. So on June 10 the repo was forked into what became ur Special Day: the same app, sold as a $99 one-time purchase per wedding.

The first decision was a guardrail: our own wedding’s site and database are frozen and untouchable. The product runs on a completely separate Supabase project. Whatever happens to the business, nothing can corrupt the thing 50+ real guests will use in August.

The pitch image for the product’s live wall: guests upload, the venue screen updates.

What multi-tenancy actually changed

The original hardcoded everything in data files. The product replaces that with a weddings table and a slug in the URL — /w/your-names — resolved by a small context module every page shares. Each wedding gets its own theme (four palettes), hero photo, and content, edited by the couple themselves through a magic-link editor. Checkout runs through Lemon Squeezy; a webhook provisions the wedding and emails the link. No accounts, no passwords, no dashboard to learn.

The magic-link editor. Couples set names, date, theme and photos themselves — no account, no dashboard to learn.

The fork also removed features. Seating charts, the schedule, bingo, photo quests, check-ins — all stripped out of the product at cutover (one commit deletes 370 lines of their dead CSS). They’re on the roadmap as a premium tier to port back once demand proves itself, which means the product currently ships a subset of my own wedding’s app. I find that ordering healthy: the paid tier is pre-tested on the most demanding client I have, us.

The security week

Before marketing it to strangers I ran a security review and wrote an eight-gap remediation plan, then executed it: photo storage moved from a public bucket to signed URLs, guest posts gated behind a CAPTCHA and server-side inserts, webhook auth switched to HMAC with constant-time comparison, rate limiting backed by Redis. The plan document itself instructs the agents executing it which sub-skill to use per task. Plans written for machine execution read differently — every task has a verification step, because “done” has to be checkable by something that can’t nod.

Since then it’s grown the unglamorous parts of a real product: a moderation dashboard, terms and privacy pages, transactional email from its own domain, and programmatic SEO landing pages generated by script. The original app got none of that and needed none of it. Same code lineage, two different lives.