Our 200-Team Plan Label Was Actually Three Different Purchases Bundled Into One Price

The 200-team plan bundled three separate things (a custom domain, a registration tool, and room for 200 teams) behind one price, so a 10-team league that wanted only the domain had to pay for event capacity it would never use. The screen showed a single slider, and the price on it read as the cost of a big tournament. In fact only one of the three items was tied to tournament size, and that item is a burst of work over one weekend, not something an organization needs all year.

It was not.

I read what was actually inside it: a custom domain, which is a website address with an organization’s own name, a registration tool, and room for 200 teams. The label on the screen had told a much simpler story than the price itself. I had accepted the label because it sounded sensible. Bigger tournament, bigger price. That is the kind of sentence that feels settled until you pull the box apart and find three different things packed inside.

A 200-team event is real work. Over one weekend, people check in, brackets fill up, and a crowd of registrations can arrive at once. But that is a burst of work, not a permanent condition. An organization might run one 200-team 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. A 10-team league that wanted only a custom domain had to buy event capacity it would never need. The old slider treated two different sentences as if they meant the same thing: “I need more room for my event” and “I want this feature all year.” They are not the same request. 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.

I briefly considered charging only by team count. That would have made the unused-capacity problem less painful. It also would have blurred the line between ordinary access to the platform and the unusual demands of a tournament weekend. A simple price is not automatically an honest price if it hides what the buyer is getting for the months between events.

The first version I built did not work. I 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. I had to reverse the separate page and bring the event choices into the membership path that was already there. The hard part was not putting a few bundles on a screen. It was making one payment flow handle a change to an ongoing membership and a one-time tournament purchase without losing track of either. The first version had also skipped some account situations, so those needed explicit tests before the new path could be trusted.

The answer became two separate layers. Membership covered access to ongoing features. An event bundle covered one tournament. 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 I use throughout the year?” The event choice answered, “What do I 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 teams.

I wrote the decision down on April 10, 2026, while it was still a prototype. That matters because the prices and bundle names from that work were decisions for that moment, not a public promise carved in stone. The useful part was the shape of the choice, not a claim that one set of prices would work forever.

The change also 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.

That was a useful correction to my own picture of the job. When a change reaches into membership, event choices, and payment, the right question is not only, “Does the new picker work?” It is also, “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.

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. Those are things to watch after release, not proof that the answer is already right.

The 200-team price was never one price. It was three things (a custom domain, a registration tool, and room for 200 teams) sold as one, and only the last of them is a weekend-sized burst of work. The rule that came out of the rebuild, that the ceiling is the gate, exists so a 10-team league can keep its custom domain all year without renting room for 200 teams it will never field. If the new picker ever drives people back toward the top plan just to get a domain, the two layers have collapsed into one again.

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/blog/2026-04-10_200-team-plan-was-not-a-200
WHAT HAPPENED: A 200-team 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 tournament 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.