A New Page Slipped Past a Feature Gate That Was Already Supposed to Cover It

A menu entry for a higher-tier tournament page was supposed to show an upgrade prompt, and one of them showed nothing at all. Every page carried a minPkg label that told the menu the lowest service level to advertise, and the label was added with a guarded line that quietly skips a page that does not exist yet. One page was created later by a separate step of the site setup, so its line found nothing, did nothing, and left that entry with no service level. There was no warning and no broken screen, only one menu item that never asked anyone to upgrade.

The pages needed to show different menu choices depending on what level of service an organization had. If a page belonged to a higher level, the menu should not invite everyone in as if the page were already available. It should show the next step instead.

That sounds straightforward. It also sounds like the beginning of a much bigger project.

My first answer was a familiar one: make a catalog of every possible feature, build a separate place to check them, and keep a table that says which organizations get which things. On paper, I had three new pieces to make before the actual menu question was even answered.

That first approach was the wrong fit. It would have created a second list of page rules next to the list the site already used. Every future change would mean remembering to update both lists. Anyone who has kept a grocery list on the refrigerator and another one in a phone knows how that ends. One list says milk. The other does not. Someone comes home without milk.

So I stopped before building it and looked at the menu itself.

The site already had a small label on every page called minPkg. The name is not important. What mattered was its job. It told the menu the lowest service level a page should advertise. If an organization did not have that level, the menu showed an upgrade prompt instead of a working link.

That was the answer sitting in plain sight.

There is a technical name for this kind of choice: feature gating. It simply means showing or holding back part of a service based on what someone has paid for. In this case, the menu already knew how to do the visible part of that job. I did not need a new catalog to teach it again.

The change became small. For each affected page, I added one guarded line that put the proper service level on that page’s existing label. Instead of building a new map of organizations and permissions, the page and its menu entry kept the same answer in the same place.

That mattered because a page and the menu item that points to it are really one promise. If the page is supposed to say, “This belongs to the next level,” the menu ought to say the same thing. Keeping those answers together is less exciting than building a new system, but it leaves fewer places for an old rule to hide.

Then one line did nothing.

Most of the page labels worked the first time. One did not. There was no warning, no broken screen, no loud message saying that something was missing. The line simply skipped over a page that was not there yet.

The reason was order. Most pages existed when the labels were added. This one was created later by a separate part of the site setup. I had tried to put the label on a page before the page existed. The guarded line was polite about it. It saw nothing, did nothing, and moved on. Later, the site created the page, but by then the chance to add its menu rule had passed.

That cost time and patience because the code looked like it should work. A single line can be easy to trust, especially when its neighbors all work. The saving grace was that this was still an experimental branch, not something people were already using. We found the quiet miss before it became a confusing menu for anyone else.

The fix was not dramatic. The same label was added after the step that created the late-arriving page. First assemble the pages. Then attach the labels that describe them. Finally, check the page that comes in late instead of assuming it followed the crowd.

There was still a separate question behind the scenes. A menu can point someone away from a page, but it cannot be the only lock on something that must not be used without the right service level. Some actions do not match one menu page neatly. Those needed their own checks, even when the visible menu and the behind-the-scenes rule were based on the same business decision.

This work did not become a finished, live way to decide access. It remained a prototype. The useful result was smaller and more honest: we found an existing piece of the site that already solved the menu problem, and we caught the one page that arrived too late for the first pass.

The minPkg label was already the one place that knew the lowest service level a page should advertise, and the whole change came down to putting the right value there, once, on each page. That is why the late-arriving page mattered more than its size suggests: the label on it was skipped, so the menu had no level for it, and the quiet miss would have been the one entry out of the whole set that never showed the upgrade prompt. The label only works if every page has it. I got that guarantee by attaching the labels after the step that creates the last page, not before.

dxdev LESSON · paste into your AI coding agent
LESSON: Look for the existing rule before building a second list of the same rule
SOURCE: dxdev.com/blog/2026-04-10_page-that-showed-up-too-late
WHAT HAPPENED: Asked to gate a set of tournament pages behind a plan tier, the first instinct was to build a new feature catalog, a separate permission table, and a new check layer from scratch. The site's menu system already had an existing per-page service-tier label that determined whether the menu showed a working link or an upgrade prompt. Reusing that existing label made the change small, one guarded line per page, instead of a new subsystem, but one page's label silently did nothing because the label-assignment step ran before that particular page existed, since it was created later by a separate part of site setup, a gap caught only because the work was still a prototype.
THE RULE: Before building a new system to enforce a business rule, check whether an existing mechanism already enforces a version of it and can be extended, since a second parallel rule-list is a second thing that can drift out of sync with the first.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any newly proposed feature-gating or permission system that duplicates a check an existing mechanism, such as a page-level service-tier label, already performs.
  2. Any setup or initialization step that assigns configuration to a set of items generated earlier in the same process, without verifying it also covers items created later in a separate, decoupled step.
  3. Any silent no-op code path, an if-not-exists skip, that fails without any warning or log line, making a missed case invisible until manually caught.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.