Team-Page Ordering Is a Release Decision

A new Legal Counsel profile landed at the bottom of the team page yesterday. Heather Johnson was the most consequential reader-facing contact on the page, and the page put her last. The fix shipped thirty-four minutes later as v4.4.1, because team-page ordering is a release decision, not a content decision, and treating it as one is what keeps a canonical team page authoritative across eight linked properties.

How should team pages be ordered?

Team-page ordering should put the highest-value reader-facing contact first, after the founder. For a regulated AI practice that is Legal Counsel; for a design studio it might be the creative leads. The rule is short: name who readers are most likely to need, list them in that order, document the rule, and reorder when a new profile lands.

What shipped and what did not

The intent-solutions-landing repo (the source of truth for the company team surface at intentsolutions.io/about/#team) shipped v4.4.0 at 18:49 CDT. The PR added seven team photos, a new team.json roster, a HeatherJohnson.astro profile page, and an updated footer link. The original reviewer caught the ordering at 19:18, while the v4.4.0 deploy was still propagating through the cache. The reviewer did not flag the order as “wrong.” They flagged it as “wrong for the audience the page is about to serve.” That distinction is what the rest of this post defends. The roster looked like this:

[
  { "name": "Jeremy Longshore", "role": "Founder" },
  { "name": "Opeyemi Adeyemi", "role": "Operations" },
  { "name": "Pablo Hernandez", "role": "Engineering" },
  { "name": "Max Sheahan", "role": "Education" },
  { "name": "Tim Yates", "role": "AI Engineering" },
  { "name": "Tolulope Bakare", "role": "Engineering" },
  { "name": "Heather Johnson", "role": "Legal Counsel" }
]

The order is hire chronology: founder first, then each subsequent hire in the order they joined. Heather was the most recent hire, so she landed at the bottom. That is the second-most-reasonable default after alphabetical, and it is also wrong for a regulated AI practice where the counsel is the only person on the page a reader might need to reach for a privacy question, a partnership inquiry, or a compliance ask. Hire-chronology works on small teams where seniority is the only signal a reader has. Once a reader needs to find one specific person, it works against them.

v4.4.1 reordered the file thirty-four minutes later:

[
  { "name": "Jeremy Longshore", "role": "Founder" },
  { "name": "Heather Johnson", "role": "Legal Counsel" },
  { "name": "Opeyemi Adeyemi", "role": "Operations" },
  { "name": "Pablo Hernandez", "role": "Engineering" },
  { "name": "Max Sheahan", "role": "Education" },
  { "name": "Tim Yates", "role": "AI Engineering" },
  { "name": "Tolulope Bakare", "role": "Engineering" }
]

The diff is six lines moved up. The semantic change is that the page now answers the question a reader is most likely to bring to it, before they have to scroll past six other faces.

Why not the obvious approach?

Two reasonable defaults existed. The first was alphabetical, which we considered and rejected as a draft. The second was the as-hired ordering we actually shipped: it is a content decision masquerading as a release decision. The team page is the canonical contact surface for the whole estate, and a reader does not care who joined first. They care who can answer their question.

The third option, leaving the order to whoever maintains the page next, is the one that drifts. Within three months, someone adds a contractor. Then a summer intern. Then the intern moves up but stays where they are. The team page stops being authoritative and starts being a snapshot.

We chose the role-priority ordering with an explicit rule: after the founder, the page lists people in the order a reader is most likely to need them. Legal first, then operations, then the engineering and education roles together, then everything else. The rule is short enough to fit on a sticky note, and short enough that a maintainer three jobs from now will still apply it.

The role-priority rule is not universal. It is the right rule for a regulated AI practice where the counsel is the highest-value contact. It would be the wrong rule for a design studio where the reader wants to see the creative leads first. The point is not that role-priority is the answer. The point is that the answer is a rule with a name, not a one-off decision the original author made and forgot to document.

The 30-minute footer sweep

The same moment v4.4.0 landed, eight repos each picked up a new “Our team” footer link pointing at intentsolutions.io/about/#team. The sweep window was 18:59 to 19:29 CDT, roughly thirty minutes. Six of those repos are public landing surfaces (intent-demos, omarchy, diagnostic-pro, startaitools, hustle, claude-code-plugins). The seventh is intent-solutions-landing itself, whose team.json is the source of truth. The eighth is now-lms, which also renders its own team profile and shipped the CI gate.

The footer change per repo was mechanical. Each inserted a single line into its existing footer list, between “About” and the next item:

<li><a href="https://intentsolutions.io/about/#team">Our team</a></li>

The insertions are byte-different per repo because each footer is a different framework (site/index.html for the static HTML sites, Footer.tsx for diagnostic-pro, layouts/partials/footer.html for the Hugo build, src/app/(public)/page.tsx for the Next.js hustle app, marketplace/src/layouts/BaseLayout.astro for the Astro marketplace). The pattern is identical. Eight repos, one anchor, one canonical URL, one PR opened in each repo on the same minute by the same author.

The mechanics matter because they explain why the ordering hotfix had to ship in the same hour. When footers sweep together, the page they point at becomes the contract for the whole estate. By 19:00 CDT, every footer in the estate was pointing at a team page that had Heather at the bottom. The hotfix is not a content correction. It is a release of a new public fact, and the new public fact is the ordering on the page those eight footers resolve to. Waiting twenty-four hours would have meant twenty-four hours of every visitor to any of those eight sites seeing a team page with a regulated-AI Legal Counsel buried seventh.

The rollback path was open if v4.4.1 had broken the build: revert the team.json diff, cut v4.4.2, redeploy. Eight footers would have re-resolved to the v4.4.0 ordering for the duration of the rollback. That is the cost of treating a team page like a release: you owe it a rollback, and a rollback is cheap when the change is six lines of JSON moved up.

The alternative, batching the hotfix into the next deploy window, was the original instinct. Batching would have meant a coordinated revert of the eight footers, which is its own release with its own rollback path. The hotfix was cheaper than the batch. That is the math that decides whether something ships same-day or waits.

The CI gate: check_estate_bar.py

Once eight repos link to one URL, that URL becomes load-bearing in a way a single-site URL never is. A rename to /team/ or a layout shift that breaks the #team anchor would silently rot every footer in the estate. The now-lms repo shipped scripts/check_estate_bar.py in the same hour, a 79-line Python check that hits the canonical URL and verifies the anchor still resolves to a non-empty team roster. The gate is intentionally minimal. It does not parse the ordering. It does not check the photo count. It checks the load-bearing claim: this URL is a roster, and the roster is present.

def main() -> int:
    target = os.environ.get("ESTATE_TEAM_URL", DEFAULT_URL)
    r = requests.get(target, timeout=10, headers={"User-Agent": "check-estate-bar/1"})
    r.raise_for_status()
    soup = BeautifulSoup(r.text, "html.parser")
    anchor = soup.find(id="team")
    if anchor is None:
        print(f"FAIL: {target} has no #team anchor", file=sys.stderr)
        return 1
    members = anchor.find_all(attrs={"data-team-member": True})
    if len(members) < 1:
        print(f"FAIL: {target} #team has no roster", file=sys.stderr)
        return 1
    print(f"PASS: {target} #team has {len(members)} members")
    return 0

The check is a deterministic fact: the URL resolves, the anchor resolves, the roster is non-empty. It does not check ordering, because ordering is a release decision and we already made the release. It checks that the page is still authoritative. That is the gate’s job.

The check is wired into now-lms CI as a required step. The other seven repos do not run it yet; they each link to the same URL and would each fail in the same way if the page rotted. Wiring them all is the next bead.

What this looks like at three months

Without the CI gate, the page drifts. A volunteer contributor renames the anchor for SEO. A designer moves the roster into a tabbed component. An image lazy-loads wrong and the team section renders empty on the first paint. None of those changes break the page locally. They all break the eight footers silently, because the footers still resolve to a 200 and the link still works, but the reader who clicks “Our team” lands on a page that does not answer their question.

We have lived this pattern before on the same estate. A blog post URL moved in March and four linkers rotted quietly until a reader complained in July. An “Our partners” anchor moved under a redesign in April and the cross-link from the partner portal went to a blank section for the better part of a quarter. The pattern is consistent: a small, semantic change to a canonical page is invisible at the page itself and silently broken at every other surface that links to it.

The CI gate catches two of those three failure modes. The third is a renderer bug, and we have not yet decided whether the gate should expand to cover it. For now, the gate is a presence check, not a quality check. That is the right scope for a 79-line script. Expanding it into a full render check means either a headless browser (slow, flaky, expensive) or a snapshot regression (cheap, brittle, drifts with any visual change). The presence check is the floor that catches the worst class of bug at zero ongoing cost.

The other thing a CI gate does is give the next maintainer permission to push back. Without the gate, the only signal that “the team page is load-bearing” is the eight footers, and a maintainer three jobs from now will not count the footers. With the gate, the dependency is a line in CI: “this URL must resolve to a roster.” That is a contract someone can read, and contracts outlive institutional memory.

What “estate anchor” actually means

An estate anchor is a URL that other properties depend on as a contract rather than as a reference. A reference is a link a reader clicks if they are curious. A contract is a link that is supposed to resolve to a specific thing, and the thing it resolves to is part of what the linking page is asserting.

The footer sweep turned intentsolutions.io/about/#team from a reference into a contract. Before the sweep, the page was a page. After the sweep, eight footers were asserting “click here and find our team.” The assertion is the contract. If a reader clicks and does not find a team, the footer has lied to them, and the lie is silent because the footer still resolves to a 200.

Most estates cross the reference-to-contract line without noticing. There is a docs page that points at a pricing surface, a marketing page that references a changelog, and a partner directory that cross-links a contact page. Each link is small. In aggregate, each is a contract. The CI gate is the moment a team acknowledges the contract exists.

The cost of acknowledging the contract is small. The check is 79 lines. The wiring is one line per repo. The maintenance is one URL to remember. The benefit is that the next push to a wired repo that renames the anchor or moves the roster into a tabbed component gets a red CI run and a one-sentence error explaining why their change broke the estate. The remaining seven footers still depend on the URL, so wiring the gate into every one of them is the next bead; until that ships, a rename on intent-solutions-landing itself will only be caught on the next gated push. That is enough to make the right decision the easy one.

The next time a similar pattern comes up on the estate (a new partner joins the directory, a new pricing tier appears, a new compliance doc publishes) the discipline is already there. Same-day fix if the canonical surface changes. CI gate before the third link points at it. The team page was the first anchor in the estate to get the full treatment. The pattern is now load-bearing for every anchor that comes after it.

That is the lesson. A team page is a page. A team page that eight footers depend on is a contract. The cost of treating it like one is one extra script and one extra hour.

Also shipped

The rest of the day’s work that does not fit the team-page finding:

• now-lms (#125) shipped the estate-bar check plus the matching team profile rendering for Heather, with the same ordering rule as the canonical surface.
• intent-os shipped the whiteglove distribution packet (3516 lines, nine print PDFs) and the matching ownership verification records.
• hustle v3.3.7 and startaitools v1.21.14 auto-bumped on the same day as the team-link fix landing in each repo.
• omarchy refreshed its public plugin facts from the GitHub API (generated content only, no semantic change).

The discipline, generalized

The team page is one canonical surface among several on this estate. The partner directory is another. The pricing page is a third. The published-changelog index is a fourth. Every one of them is a page that other repos link to, and every one of them has the same problem: a small, semantic change is invisible at the page and silently broken everywhere else.

The team-page fix generalizes to a rule: when a single canonical surface becomes load-bearing across the estate, treat every edit to it as a release. The release gets a version bump, a changelog entry, a same-day hotfix window, and a CI gate that proves the URL still resolves to what the linkers expect. None of that is novel. It is the same discipline every API publishes under. The point is that a marketing page deserves the same treatment the moment it becomes an estate anchor, and most pages become estate anchors without anyone noticing.

The reason this matters for a team page specifically is that the failure mode is invisible to the team and visible only to the reader. The team sees the page render correctly in their browser. The reader sees a page where the person they came for is seventh. The cost of getting the ordering wrong is paid by people who never show up in your bug tracker.

Use this

• Treat team-page ordering as a release decision. Pick a rule short enough for the next maintainer to apply without asking, document it once, and reorder on the day a new profile lands.
• When you turn a single-site URL into an estate anchor, ship a deterministic check that the URL still resolves to the thing eight footers expect. 79 lines of Python is enough for the first gate.
• Order the canonical team page by the question a reader is most likely to bring, not by hire date and not by alphabet. The page is a contact surface, not a roster. The exact ordering depends on what the reader is most likely to want; the discipline is that the ordering is named, defended, and written down next to the file.

FAQ

Why should team-page ordering be treated as a release decision?

A team page becomes load-bearing the moment multiple footer links point at it. Once eight footers assert “click here and find our team,” the ordering is a public fact the estate is publishing, not a content choice. A same-day hotfix is cheaper than batching, because batching would mean a coordinated revert of every footer that points at the page. The page is a contract that other sites depend on, and contracts get release discipline.

What is an estate anchor?

An estate anchor is a URL that other properties depend on as a contract rather than as a reference. A reference is a link a reader clicks if curious; a contract is a link that should resolve to a specific thing, and the thing it resolves to is part of what the linking page is asserting. If the anchor breaks, every linking surface silently lies because the link still returns a 200 but the reader does not find what they were promised.

How do you keep a team page authoritative across multiple sites?

Ship a deterministic CI gate that hits the canonical URL and verifies the anchor still resolves to a non-empty roster. The check_estate_bar.py gate is 79 lines of Python and runs as a required CI step in now-lms. Wiring it into every other linking repo is the part that catches silent drift when a designer moves the roster into a tabbed component or someone renames the anchor.

Related Posts

• Use the Primitive, Not the Patch (the same-day-sweep discipline, applied to a security primitive rather than a team page).
• Scope Federated Tailscale Trust to Auth Keys (federating one identity surface across the same eight-repo footprint, with the same anchor-page release posture).
• Pin the Installer and Add a Renewer (a named rule plus a CI gate that catches silent drift, the same shape as check_estate_bar.py).