What Is Vowframes?

The wider system starts with one wedding link. It tells people where to go, when to arrive, which events they can see, how to respond, where the couple is registered, and where photographs will appear later. Every guest should understand it on the phone in their hand.

Vowframes is the wedding platform I am building for that job. A couple or planner creates one wedding site, adds the events around the wedding, invites the right people, collects their responses, and manages the moving parts from a private admin area.

The public site still has to feel like a keepsake. Guests should see a wedding, not the software used to organize it.

One wedding can contain many guest lists

Indian weddings rarely have one ceremony and one universal invitation.

A family may invite everyone to the wedding and reception, close friends to the sangeet, and a smaller group to the mehendi or haldi. Some guests arrive as individuals. Others belong to a family invite with several members and different attendance plans.

Vowframes models the wedding as a set of events under one shared site. The couple can decide which invite groups see each event. A guest opening an invite-only link sees the schedule meant for them instead of the complete internal plan.

This gives the couple one place to manage the wedding without exposing every event to every visitor.

Guests respond once

The RSVP flow brings all eligible events into one form. One RSVP for a Multi-Event Wedding explains why the underlying model changed.

A guest who is invited to three events can answer for those three events in one pass. They do not have to open three forms or repeat their name and details. Family groups can respond for their members while the couple still receives event-level attendance data.

The admin area then turns those responses into useful views: who has replied, who is attending each event, which groups are pending, and where the couple needs to follow up.

This replaces a common wedding workflow built from spreadsheets, WhatsApp messages, and memory.

The site carries the wedding’s identity

Vowframes has a template system with several distinct wedding-site designs. A couple chooses a starting point, adds their names, story, photographs, event details, venue links, and welcome text, then previews the result before publishing.

The templates share the same wedding data and guest flows. Their typography, composition, photography, and section rhythm can change. Switching a template preserves the couple’s content.

The guest experience stays mobile-first. Venue details need to be readable in a car. RSVP controls need comfortable tap targets. Older relatives should not need instructions to find the schedule.

The couple gets an operating view

The private wedding admin includes the less glamorous work behind the public site:

• event and schedule management;
• invite groups and guest members;
• RSVP summaries and event-level responses;
• story, welcome, venue, and homepage content;
• template selection and publishing;
• registry details and wishlist items;
• gallery uploads and processing;
• plan, billing, and invoice management.

The registry supports direct payment details rather than processing the gift through Vowframes. This keeps the relationship between the guest and the couple clear while giving the couple a presentable place to explain what they prefer.

The gallery supports private wedding-photo browsing and downloads. The underlying photo pipeline can create image variants and organize detected faces. Guest-facing selfie search is still planned work, so I do not present it as a finished feature yet.

Vowframes serves couples, guests, and planners

Couples need a wedding site they can manage without learning web publishing. Guests need fast answers and a short RSVP path. Planners need to keep several weddings separate while using the same operational tools.

Host-based tenancy gives each wedding its own address and keeps its guests, events, responses, registry, and media separate. The platform host handles signup and wedding selection. Each wedding host carries its own public site and admin area.

The architecture matters because privacy is part of the product. An invite-only schedule should stay invite-only. A guest session from one wedding should not bleed into another.

What Vowframes is trying to replace

Wedding information usually spreads across invitation cards, phone calls, WhatsApp groups, spreadsheets, map links, payment messages, and photo folders. The couple or family becomes the human integration layer between all of them.

Vowframes puts the schedule, invitation rules, responses, registry, and photographs behind one link. The couple still has work to do, but they no longer have to reconcile five versions of the wedding across cards, chats, forms, and spreadsheets.

Building with AI: I define the tenant, invitation, privacy, and template contracts; AI writes much of the route and component implementation. It can produce a polished page while preserving the wrong template identity or presenting planned behavior as live. Exhaustive template dispatch, invite-scoped queries, real marketing captures, and current-versus-planned copy checks keep the generated surface tied to the product that exists.

How the routes hold together

The route structure reflects the three audiences. The platform host handles account and wedding selection. Tenant hosts resolve the wedding before serving public pages or admin APIs. Invite codes narrow the guest-facing event set. TenantPageRouter and TenantLayoutRoot keep the same wedding data while template-specific section renderers change composition.

Ivory Bloom tested that boundary across the home, events, event detail, gallery, registry, profile, and RSVP pages. A renderer bug initially applied pure-elegance-template to the Ivory Bloom demo, proving that the preview path had bypassed the normal layout dispatch. The fix moved template identity back into the manifest-driven route.

I checked every shared route on desktop and mobile. The marketing gallery then received real template captures so the card represented the product a couple would actually open.

On the backend, I exercised shared Redis throttles, invite-related unverified users, and OAuth-verified users as distinct account paths.

One wedding record can now serve those different views without mixing tenants or exposing private events. Host resolution, invite-scoped queries, exhaustive template dispatch, and route-level browser review remain the checks whenever a shared guest component changes.