One Plan Label, Three Items, and a 10-Entry Customer Paying for 200

A customer with 10 entries who only wanted a custom domain had to pay for room for 200 entries. Our plan label bundled three separate things behind one price: a custom domain, a registration tool, and room for 200 entries. The screen showed a single slider, and the price on it read as the cost of a big event. Only one of the three items was tied to event size.

What was inside the label

A custom domain is a website address with an organization’s own name. Add the registration tool and the room for 200 entries and you have the whole plan. The label on the screen told a much simpler story than the price did. We had accepted it because it sounded sensible: bigger event, bigger price. That sentence feels settled until you pull the box apart and find three different things packed inside.

A 200-entry event is real work. Over one weekend, people check in and a crowd of registrations can arrive at once. That is a burst of work, not a permanent condition. An organization might run one 200-entry weekend a year, then spend the other 11 months using none of the three things bundled into that top price.

The same knot hurt smaller customers in the other direction. The 10-entry customer wanting a domain had to buy event capacity it would never need. The old slider treated two different sentences as if they meant the same thing: “We need more room for our event” and “We want this feature all year.” One is like renting extra chairs for a family reunion. The other is like deciding to keep a dining table in the house every day.

We briefly considered charging only by entry count. That would have made the unused-capacity problem less painful, but it would also have blurred the line between ordinary access to the platform and the unusual demands of an event weekend. A single simple price can still hide what the buyer gets for the months between events.

The separate pricing page that had to go

The first version we built did not work. We made a separate pricing page, which looked clean because it could explain the new choices in one place. The trouble came when it had to lead into payment. It could not carry the information the existing payment flow already held about what someone was buying without copying too much of the behavior that was already there.

That cost time. We had to reverse the separate page and bring the event choices into the membership path that was already there. The hard part was making one payment flow handle a change to an ongoing membership and a one-time event purchase without losing track of either. The first version had also skipped some entry situations, so those needed explicit tests before the new path could be trusted.

Two layers

The answer became two separate layers. Membership covered access to ongoing features. An event bundle covered one event. The membership did not stack a mysterious discount on top of another limit. Instead, it decided which event bundles someone could choose. That was the rule underneath the screen: the ceiling is the gate.

In ordinary words, the ongoing plan answered, “What can we use throughout the year?” The event choice answered, “What do we need for this particular weekend?” Keeping those answers separate made the next step easier to understand. A person could outgrow an event size without being told they also had to buy unrelated features. They could choose an ongoing feature without pretending they needed room for 200 entries.

We wrote the decision down on April 10, 2026, while it was still a prototype. The prices and bundle names from that work were decisions for that moment. The useful part was the shape of the choice.

What broke 12 days later

The change taught a second lesson 12 days later. A related part of the service got changes to its page pieces but did not get the visual materials those pieces needed. This was a regression, which simply means a change made one thing worse somewhere else. The pricing idea still held. But the work had touched more than the page where people chose a plan, and the checking had not covered all of it.

So when a change reaches into membership, event choices, and payment, we now have two questions to answer: “Does the new picker work?” and “What else shares pieces with this?” A new lock on your front door is not much comfort if, while installing it, you loosen the hinges on the side door.

What we are watching

None of this means the new model is settled forever. The decision record named a few reasons to revisit it: if entry plans convert poorly, if higher plans are rarely used, or if people keep getting confused by the bundle picker.

If the picker ever drives people back toward the top plan just to get a domain, the two layers have collapsed into one again, and a customer with 10 entries is paying for room for 200.

dxdev LESSON · paste into your AI coding agent
LESSON: A bundled price is only honest if it separates 'all year' from 'this one weekend'
SOURCE: dxdev.com/everyday-ai/200-team-plan-was-not-a-200
WHAT HAPPENED: A 200-entry pricing tier bundled a custom domain, a registration tool, and event capacity into one price, so customers paid year-round for features they only needed during a single event weekend, while smaller customers who wanted only a custom domain had to buy event capacity they would never use. A first attempt built a separate pricing page that could not cleanly feed the existing payment flow, so the fix instead folded event-bundle choices into the existing membership path, splitting "ongoing membership" from "one-time event bundle" into two layers, with membership deciding which event bundles were available.
THE RULE: Separate what a customer uses all year from what they need only for one busy period, and don't bundle them into a single price or tier that hides which is which.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any pricing tier or plan that bundles an ongoing-access feature with a one-time or seasonal-capacity feature under a single price, without separating them into distinct purchasable layers.
  2. Any new pricing or checkout flow built on a separate page that doesn't reuse the existing payment flow's data model, risking duplicated state or a disconnect at the point of payment.
  3. Any change to membership or plan logic that touches shared pieces, such as payment or event choice, without checking what else depends on those same pieces.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.