Built to spread through a family WhatsApp group, not sit on a wedding website

Digital wedding invitations already existed as a category, but almost every product in it assumed a Western sharing pattern — a link posted to a wedding website, or emailed out individually. That's not how a large share of weddings actually get organized: invitations move through family and community WhatsApp groups, forwarded person to person, often by someone other than the couple getting married.

We built UnfoldInvite because we saw a genuinely different distribution shape that existing products weren't designed around, and because a self-serve consumer product with a natural viral loop — every invitation sent is a piece of marketing for the product itself — was a useful complement to Snapwit and LeadIntent's more B2B distribution. It also gave us a consumer-scale, high-traffic-spike system to build and operate, which is a different set of problems than either of our other two products face.

A couple picks a template, fills in event details, and gets a link plus a set of ready-to-forward images and video snippets sized for WhatsApp status and chat. Guests open the link to a mobile-first invitation page with RSVP, event details, and directions, without installing anything.

Templates are built with regional variation in mind rather than a single generic design — different ceremony structures, multiple languages within the same invitation, and layouts that make sense whether a couple is sharing one combined event or a sequence of ceremonies across several days. That's closer to how weddings in the markets we've focused on actually get organized than a single Western-style template would be.

The template engine is the core of the product: each design is a structured template with content slots — names, dates, venue, a photo or two — rather than a fully custom page built per couple. That constraint is deliberate. It's what makes the product self-serve and fast to launch a new invitation on, rather than requiring a designer per customer, and it's also what lets us add new templates as a content problem instead of an engineering one.

Because an invitation's traffic pattern is almost purely viral — near zero visits until it's shared into a group, then a sharp spike as that group opens it over a few hours, then a long tail through the RSVP window — we deployed on Cloudflare's edge network rather than a traditional origin server. The same reasoning applies here as it does across our other products: provisioning a server for the peak means paying for idle capacity nearly all the time, since most invitations sit quiet between the initial share spike and the wedding date itself. Serving invitation pages from the edge also matters for a more basic reason — guests are opening these links on mobile data in the middle of a family WhatsApp thread, and shaving load time matters more here than on almost anything else we've built.

Generating the forwardable images and video snippets is its own small pipeline: each template defines how its content slots map onto a set of export sizes for WhatsApp status, chat, and stories, and we render those server-side at the edge rather than asking the couple's browser to do it. That keeps rendering consistent regardless of the guest's device, and it means the assets are ready to forward within seconds of finishing the invitation — which matters when the entire point of the product is that a couple shares it the same evening they build it.

Checkout is fully self-serve through Stripe, and RSVP and guest data lives in Postgres. We kept the RSVP data model intentionally simple — name, attending status, guest count, an optional note — because the couples using this product want to glance at a dashboard between wedding tasks, not learn a guest-management system.

Our first template set was visually ambitious — heavier animation, larger images — and loaded noticeably slowly on the mid-range Android devices that make up a large share of our actual traffic, something we hadn't tested against closely enough before launch. Share-to-open conversion on that first template set came in worse than we expected, and once we profiled it, load time on exactly the devices our users carry was the obvious cause. We rebuilt the template rendering path to be lighter by default, with heavier visual options opted into rather than on by default.

We also initially under-priced the self-serve checkout relative to what customer support and template requests actually cost us per couple — a common early-product mistake, and one we corrected within the first season rather than carrying it forward.

We also underestimated how many one-off customization requests would arrive even on a self-serve product — a couple wanting a detail changed that no template exposed as a slot. Open-ended custom design work doesn't scale on a self-serve price, so rather than taking those requests one by one, we route them into a decision about whether they become a new template slot for everyone. That's slower for the couple asking, but it's the only version of the trade-off that keeps the product sustainable at the price we charge.

Running UnfoldInvite costs us mainly edge rendering for the invitation pages and shareable assets, plus Postgres storage for RSVP data — both usage-based and both cheap per invitation, since even a viral spike is a small compute footprint spread across a short burst rather than sustained load. The larger cost driver is Stripe processing fees on the self-serve checkout itself, which scale with revenue rather than traffic, so a quiet week between wedding seasons costs us close to nothing to keep running.

UnfoldInvite has run through at least one full wedding season with paying couples using it end to end, and the lighter template rework noticeably improved the share-to-open pattern we track. It's early — we're not going to dress up a first-season consumer product as more than it is — but the viral share mechanic behaves the way we designed it to, and the corrected pricing has held without another adjustment since.

If you're building anything with a viral or spiky sharing pattern — a consumer app, a referral flow, anything where load happens in bursts driven by other people's behavior rather than your own marketing calendar — the edge-first deployment approach and the lightweight-by-default rendering discipline we learned here both carry over directly. So does the instinct to treat every customization request as a product decision rather than a one-off favor.