How I Built a Multi-Tenant Web App for a Party

Why a Birthday Invite Became a Software Decision

I needed a digital invitation for a family party. That's it. That was the whole brief.

Most people solve this in twenty minutes. You open Canva, you pick a template, you drag in a photo, you export a link. Or you pay a template service ten bucks, fill in the date and time, and throw the whole thing away the day after the event. Disposable by design.

I went a different direction, and not because I'm allergic to easy. I ended up building a multi tenant web app, a cinematic invitation site for a family party that doubles as a reusable engine for any future event. Same instinct that runs through everything I build.

Here's the choice every builder faces, whether they realize it or not: bespoke or reusable. Most people treat those as opposites. You either make something custom and beautiful that only works once, or you make something generic and flexible that feels like a form. Pick a lane.

I don't think they're opposites. I think that's a false trade made by people who never architected the thing properly in the first place.

So I built something delightful, an AI-illustrated story, a scroll-driven 3D experience, a real RSVP backend, and underneath all of it I built an engine. The party-specific stuff lives in data. The code doesn't know or care whose birthday it is.

The result: the next event isn't a new project. It's a new config file.

This is the story of how a birthday invite turned into a small piece of software, and why that decision matters far beyond a family party. Because the same call shows up in your business every time someone asks you to build something "just this once."

What a Multi-Tenant Web App Actually Means Here

Let me define the term without the jargon, because I want a CEO to get this in one read.

Multi-Tenant Engine Architecture (one engine, many tenants)

A multi tenant web app is one codebase that serves many isolated instances. Each instance, each "tenant," is driven by its own data. Think of an apartment building. One structure, shared plumbing and wiring, but every unit is separate and private. Software works the same way. One engine, many tenants, each with its own content.

I didn't build a website. I built an engine that reads a single event and renders the whole experience from it.

The single typed event config

Everything that makes this party this party lives in one configuration file. Event name. Theme. Colors. The host emails. The chapters of the story. The RSVP fields. The gift registry list.

Nothing about the event is hardcoded into the actual application logic. The code is a renderer. The config is the truth. This is the data-as-config, code-as-engine pattern, and it's the single most useful architectural habit I have.

Why typing the config matters

Here's the part most people skip. The config isn't a loose pile of JSON I can typo into oblivion. It's strongly typed.

Typed Config validation: build catches errors before shipping

That means the structure is defined and enforced. If I forget a required field, or put a number where text belongs, or misspell a property, the build catches it before anything ships. The config literally cannot silently break a tenant.

This sounds like a developer detail. It isn't. It's the difference between a reusable platform and a fragile one-off that nobody but you can touch. When the next event is just data, that data has to be safe to edit. Typing is what makes "just change the config" a sentence you can say without fear.

The payoff is plain. A second event is a new config file. Not a new site, not a new codebase, not a rebuild. New data, same engine.

The AI-Illustrated Story: A Hero's Journey in Chapters

The emotional centerpiece is an AI illustrated website experience, a chaptered storybook. You scroll through it like a picture book, scene by scene, each one illustrated in a consistent art style that ties the whole narrative together.

Generating one nice AI image is easy. Anyone can do that now. That's where most people stop, and it's why most AI art on the web looks like a random sample of disconnected pretty pictures.

The hard part, the part that actually matters, is consistency. Keeping a character recognizable across multiple scenes. Holding a single art style across every chapter so it reads as one cohesive story instead of ten unrelated images stapled together. That's the real work, and frontier image models still fight you on it.

I won't pretend it's a solved problem. It isn't. Style drift is real. You generate scene four and the lighting is off, or a detail shifts, and you have to wrangle it back into line. I have a whole process for how I actually produce this stuff, which I broke down in how I generate scene art with frontier image models. Short version: you don't just generate and pray.

Here's where the engine angle earns its keep. The story structure lives in the config, the chapters, the sequence, the beats. The art is generated to fit that structure. So a different event with a different story isn't a teardown. It's a new set of chapters in the config and a new pass of generated scene art that matches.

The narrative is data. The illustration is a process. Neither one is welded into the code.

The 3D Scroll Experience (And When 3D Is Worth It)

The story is tied together by a scroll-driven 3D web experience. As you move down the page, the scene responds. It's the kind of thing that makes someone stop and actually pay attention instead of skimming.

When 3D on the web is worth it vs a liability

Now let me be the person who tells you the truth about 3D on the web: most of the time, you do not need it.

3D is a tax. A performance tax, because it's heavier to load and render. A complexity tax, because it's harder to build, harder to maintain, and easier to break across devices. I've seen plenty of business sites bolt on a 3D hero moment that tanks their load time and converts worse than the plain version it replaced.

So when does 3D earn its place? When delight is the goal. A one-time event experience. A moment meant to be felt, not measured by conversion rate. Nobody's bouncing off a birthday invitation because it took an extra second to load. They're there because they were invited, and the experience is the whole point.

When is it a liability? On a conversion-focused storefront. On my DTC fashion brand, I would never put a heavy 3D experience between a customer and the checkout button. Every millisecond there costs real revenue. Different job, different tool.

That's the honest framework. Match the technique to the goal. Delight tolerates a little weight. Commerce does not.

And true to the architecture, even the 3D experience reads its content from the same config. The scene knows what to show because the tenant told it. So it's reusable per event, same as everything else.

The RSVP Backend and Self-Claiming Gift Registry

A pretty front end with no working backend is a toy. The thing that makes this an actual product is the plumbing nobody notices when it works.

This is a real event RSVP app, not a mailto link.

RSVP that hosts can actually use

There's a proper RSVP form. Guests respond, the data gets captured and stored, and every host gets an email confirmation when someone replies. The hosts can actually see who's coming without chasing people through text messages.

The RSVP fields themselves come from the config. One event might ask about dietary restrictions. Another might ask for a plus-one count, or a song request. The form adapts to the tenant because the fields are data, not hardcoded HTML.

A registry that prevents double-gifting

The gift registry is where the design decisions get interesting. The core problem with any registry is double-gifting, two people buying the same thing because nobody knew it was taken.

Self-claiming gift registry logic (claim-once vs shareable)

So I built self-claiming logic with two item types. Some items are claim-once: the moment someone claims it, it's locked, and nobody else can grab it. Others are shareable, for gift-card-style items where multiple people contributing makes sense and there's no "already taken" problem.

When an item gets claimed, every host gets a confirmation email. No spreadsheet, no group chat, no awkward "did anyone get the blender" conversation.

This is boring, and boring is the point. The boring backend is exactly what separates a product from a demo. And it's the same backend pattern any event tenant reuses without a single change. New event, new registry list in the config, same claim logic, same confirmation emails.

That's the reusable web platform angle made concrete. Not a slogan. Working plumbing that doesn't care whose party it is.

Why the Next Event Is Just Data

Here's the whole thing pulled together, and it's the payoff for building tenant-shaped from the very first line.

Spinning up a second event is writing a config. That's it. Branding flows from data. The story chapters flow from data. RSVP fields flow from data. The registry flows from data. The 3D scene reads from data. There is no "rebuild the site" step because there's no site to rebuild. There's an engine, and I'm feeding it a new tenant.

This directly answers the doubt every CEO has when I describe this: isn't bespoke the opposite of reusable?

No. That's the lie that keeps people paying for disposable work.

A delightful one-off, architected correctly, is a multi-tenant product. The custom feel and the reusable structure live in different layers. The experience is bespoke. The engine is generic. You don't have to choose, you have to separate the two cleanly so each can do its job.

This is exactly the move I described in build it for one, ship it to a hundred. You solve your own problem first, properly, and the architecture quietly turns it into something you could give to a hundred other people without rebuilding anything.

That's how a side project becomes something sellable without you ever planning for it to be. I built an invitation for a family party. What I actually have is an event platform that happens to have one tenant so far. The second one costs a config file and an afternoon.

The decision that made that possible wasn't a feature. It was where I put the line between data and code, made on day one, before I'd written anything worth keeping.

The Lesson Behind a Toy Project

I want to be clear that this isn't a story about a birthday party. It's a story about an instinct.

The same instinct that turns a birthday invite into a reusable engine is what turns your internal tool into a platform. It's what turns your bespoke client work into a repeatable product. It's what turns your one-off process into something with actual leverage instead of something you rebuild from scratch every time.

I build everything this way, even a family party. Across my DTC fashion brand I've shipped 15-plus AI systems, the product creation pipeline, the pricing engine across 564 products, the SEO automation behind 313 articles, and almost none of it is hardcoded. It's config-driven and reusable, because the alternative is rebuilding the same thing forever and calling it work.

So here's the uncomfortable point for anyone paying for custom software. If you're funding one-off builds that get thrown away after a single use, the problem is rarely the build. The build is fine. The problem is an architecture decision nobody made. Nobody drew the line between the part that's specific to you and the part that could serve a hundred situations just like yours.

That decision is cheap to make at the start and expensive to retrofit later. I wrote about how fast you can actually go when you build this way in the new timeline for custom software.

If any of this sounds like work you've paid for twice, it's worth a conversation.

Thinking about AI for your business?

If this resonated, let's talk. I do free 30-minute discovery calls where we look at your actual operations and find the places where AI, or just better architecture, could move the needle. No slides, no pitch, just a straight look at what you're building twice and what you should be building once.

Book a Discovery Call