Why a Custom Domain Cost the Same as 200-Group Capacity

The top tier of our legacy event pricing read, on screen, as “the 200-group plan.” It was a custom domain, a registration tool, and 200-group capacity, all bundled into one number and keyed off a single group-count slider. An org that ran one 200-group weekend a year sat on that price for the other eleven months, when they touched none of the three things they were paying for.

We worked through the prototype on the client-facing web platform we run and recorded the architecture decision on 2026-04-10.

What the slider actually hid

The old model had a defensible surface logic: more groups, higher tier, bigger event costs more. Underneath it, three things were tangled together that had no business sharing an axis.

The event itself, 200 groups checking in over a weekend and the registration crush, is a one-time operational burst. The slider charged for it as a permanent monthly state. Feature access (custom domain, registration tool, newsletter) had nothing to do with group count, but it rode the same number. A ten-group customer that wanted a custom domain had to buy capacity it would never use to get it. And because features and capacity moved together, there was no legible next step. Outgrowing the event size and wanting a custom domain were the same upgrade button.

A purely per-group model was the other obvious option. It would reduce the feeling of paying for unused capacity, but it would also make the relationship between ongoing platform access and occasional event operations less explicit. We recorded that as a tradeoff and did not treat either model as universally correct.

Two layers and one rule

The redesign used two layers: a recurring membership that governed feature access and a per-event bundle that covered an individual event. The specific prices and bundle names were prototype decisions from that period. They are not a current public price list.

Two layers alone could have produced an unreadable grid of separate caps on event count, group count, storage, and feature flags. What kept it simple was one constraint: membership eligibility determines which event bundles are available. The selection rule stays visible, and every combination does not turn into its own quota check.

The ceiling is the gate.

The wrong turn in the prototype

The design emerged through a prototype path that kept the live checkout unchanged while the new flow was built and reviewed. Our first attempt was a standalone pricing page. We built it, then reversed it, because it could not share checkout state without duplicating too much behavior.

The work that mattered came after that, in small visible changes: introduce the bundle model, make eligibility visible, connect the event flow to the existing membership path, and record the architecture decision. The riskiest piece was reconciling a recurring-membership adjustment with a one-time event cart inside the existing checkout flow. That needed explicit tests for the account states the prototype had initially ignored.

What the same commit broke, twelve days later

The redesign also exposed a shared-view regression. A related package surface received markup changes without the corresponding presentation assets. That did not invalidate the pricing decision. It did show that a cross-cutting change needs a broader verification map than the feature it was built to improve.

The decision record names the conditions that would justify reopening the model: weak conversion at entry tiers, low use of higher tiers, and repeated confusion around the bundle picker. Those are hypotheses to measure after release. They do not show the model is settled forever.

What I would check first

When one price bundles feature access and event capacity, look at whether customers pay all year for something they use for a single weekend. Separating recurring access from one-time event capacity, and letting membership eligibility decide which event bundles are available, kept the choices readable for us. Treat the model as a hypothesis, and measure entry-tier conversion, higher-tier use and bundle-picker confusion once it ships.

Related

• Don’t Build a Paywall, Reuse the Gate You Already Have: the feature-gate layer that supports membership-eligibility rules
• The Pricing Rewrite Only Got Real When We Wrote the Gates: how the prototype met checkout, account-state, and entitlement constraints

dxdev LESSON - paste into your AI coding agent
LESSON: The ceiling is the gate: collapse a cap matrix with one cross-layer rule
SOURCE: dxdev.com/blog/bundle-ceiling-saas-pricing-decouple-subscription-from-per-event
WHAT HAPPENED: A SaaS product had two genuinely different cost drivers (recurring platform access and one-time operational events) forced onto a single pricing axis. Splitting them into two separate layers initially threatened to create an unreadable N-dimensional cap matrix. The fix was a single cross-layer constraint: the subscription tier dictates which per-event options are available. One rule replaced the entire cap matrix and made the upgrade path legible.
THE RULE: When two cost drivers are different concepts, keep them on separate axes and let one axis gate the other rather than merging them or expanding them into a full cross-product of caps.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any place where two independent cost or access dimensions (recurring vs one-time, feature tier vs usage tier) are collapsed onto a single numeric scale or slider.
  2. Any pricing or access-control logic that implements a cap matrix (explicit checks against combinations of plan level AND usage level AND feature flags all in the same conditional block).
  3. Any upgrade flow where moving along one dimension (e.g., event size) forces an upgrade on an unrelated dimension (e.g., feature tier), coupling concepts that should be independent.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.