The card said Flash UI. The product had been called Uigen since January (spec 029-uigen-rebrand, a rename that had happened six months before the card existed on the page). The card had pulled its name from the repo README, which hadn’t caught up. One correction call.
Then, the same hour, the supermarket card came down. The Medusa headless build described on it wasn’t the supermarket project. It was a different Medusa build in progress. That was the wrong card. The actual supermarket work is a separate thing, for a named retail brand. That brand stays unnamed. So the work appears on the portfolio as “Supermarket E-commerce Refresh” — the kind of work, not the client.
Two corrections. One hour. One pointing at a product rebrand, one pointing at a client naming constraint. Both were fixable. Both had the same cause: the card names were doing something they couldn’t sustain.
What a branded card name is actually doing
A card that uses a product or client name is taking on an implicit maintenance contract. The card stays accurate as long as the product name stays the same and as long as the client relationship permits public naming. Neither condition is guaranteed indefinitely.
Product names change. Flash UI became Uigen in January; the card shipped with the old name because the README hadn’t updated. No automated mechanism catches a six-month-old rebrand against portfolio content. The mechanism is me noticing it months later.
Client relationships shift. The supermarket work is real, significant, completed, but the brand is one I can’t name publicly. That’s not a quality question; it’s a relationship structure, and relationship structures change. A card whose accuracy depends on a third party’s decisions about public naming is not a card that ages well.
Both failure modes produce the same result: I find out something is wrong from a correction call, not from a scheduled review.
The entity policy
Every card on /work now uses a general category name. The kind of work, not the product or client name.
“Uigen” might rebrand again. “Supermarket E-commerce Refresh” describes what the work actually was: a headless commerce build, a retail domain, a project at the intersection of frontend and commerce infrastructure. That description is accurate whether or not the client brand is named, whether or not the product has updated its brand a second time. A visitor reading the card understands what kind of project it was. They don’t need the trading name to decide whether I’ve done similar work.
This convention exists in every agency deck for a reason. “Fortune 500 healthcare client” is the standard move because branded names on portfolio content require indefinite third-party maintenance. The entity policy is the same logic, made explicit.
The tradeoff is direct. “Uigen” carries more signal in certain circles than a category description does. A named retail brand would be more immediately persuasive than “Supermarket E-commerce Refresh.” That’s a real cost. It’s worth taking to have a portfolio section that doesn’t require correction calls triggered by naming decisions I don’t control.
Filling the thin spot
The section was thin. Reviewing it through an employer persona, I found the gap: not enough dates, not enough range, no sense of where the work started or how far back it went. The visible work skewed recent.
Four cards were added, covering twelve years of web development work. All four were general-named from the start: sector, scope, type of deliverable. Not “[Client name] CMS Migration.” Not “[Agency name] E-commerce Build.” Category descriptions that stay accurate without depending on anything outside my control.
Starting with the entity policy as a constraint produces different cards than applying it retroactively. Retroactively, it produced two corrections and a withdrawn card in the same hour. From the start, it produces cards that don’t need correcting, because nothing in the name can expire.
The panel flag cleared.
Visitor-facing categories
The /work groups had been organised around the internal build narrative: how the content system categorises work by its construction. Standalone tools. Platforms. Sites. Accurate internally; not useful to a visitor.
A visitor arriving from a job listing or a referral isn’t asking whether a project was a standalone tool or a platform. They’re asking what kind of work. Four visitor-facing categories replaced the internal taxonomy, keeping the same cards under a different organising principle. The WORK navigation dropdown reflects the change.
The entity policy and the category reorganisation are the same correction at two levels. Card names answer “what is this project?” accurately; group names answer “where do I look?” usefully. Both were wrong; both are now fixed.
The maintenance model
Branded names require monitoring. General names don’t.
Whether a product has rebranded, whether a client relationship still permits public naming, whether a project name still appears on the client’s own site: none of these are questions I need to revisit when the card says “Supermarket E-commerce Refresh.” The work doesn’t change retroactively. The description of it doesn’t expire.
Editorial maintenance still applies. Scope descriptions need to stay accurate, dates need to be correct, and groups need to keep matching what visitors are trying to find. Those are expected. What’s no longer expected is a correction triggered by a third party’s decisions six months after the card shipped.
The two corrections in the same hour were the point at which the policy became explicit. Some earlier cards had already applied it; it wasn’t consistently enforced. It is now. The next product rebrand or relationship shift won’t produce a card that needs withdrawing. The work either appears under a name that ages well, or it doesn’t appear at all.
