Why Each Pricing Tier Is a Separate Code Module, Not a Feature Flag
Vows by Surihana offers multiple product tiers — I've seen "elegant," "luxury," "premium," and "squad" as distinct modules in the codebase. I want to talk through the architectural choice of building tiers as separate modules rather than a single codebase with feature flags gating access.
The two approaches
The common pattern for tiered products is one codebase, with feature flags or subscription checks gating which UI and logic paths a given user can access. It's simpler to maintain in one sense — one deploy, one set of components, conditional rendering based on tier.
Vows instead structures each tier as its own module — for example, the "elegant" tier has its own invitation-engine, rsvp-system, guest-links, event-display, and sender-profiles files, distinct from whatever the other tiers implement for the same concerns. "Squad" — the wedding-party coordination tier — has its own dedicated squad-system module entirely.
Why separate modules, given the added overhead
I can't claim certainty about every reason behind this specific architectural choice without more direct confirmation, but based on the observable structure, a few real advantages stand out. Separate modules mean a change to the luxury tier's RSVP flow can't accidentally break the elegant tier's — there's no shared conditional logic where a tier-specific edge case has to be reasoned about against every other tier simultaneously. It also means a tier can be retired, or majorly redesigned, without touching code that other tiers depend on.
The real cost is duplication — if all four tiers need a bug fix to, say, how RSVP counts are calculated, that fix potentially needs to be applied four separate times rather than once. This is a genuine tradeoff, and I think it's the right one specifically for a product where the tiers are meant to feel meaningfully different from each other (a "squad" coordination tool is a different problem from a "luxury" tier's presentation logic) rather than the same core product with cosmetic differences.
When I'd choose the other approach
If the tiers here were primarily differentiated by things like storage limits or a handful of gated UI elements — the more typical "free vs. pro" pattern — I think a single codebase with feature flags would be the better call; the products aren't different enough to justify separate modules. The module-per-tier approach earns its complexity specifically when the tiers represent genuinely different feature sets and user needs, not just different access levels to the same feature set.
Curious how others have drawn this line — at what point does tier differentiation become significant enough to justify separate modules over flags within one codebase?
Top comments (0)