Removing a feature took one pass. Retiring it took two.

Four pieces stayed on purpose.

• A guard in the payment webhook. The retired prices still exist at the payment provider. Without the guard, a subscription on one of them would fall through to a default and silently grant a paid plan.
• Part of the billing module. Freelancer billing still depends on it, so it was cut down, not deleted.
• A branch in the review form. The database still records reviews from hires made through the board, and the page shouldn't contradict the database.
• Old job-board notifications. They're user data. They stay stored, and they're filtered out when read, everywhere they're listed or counted.

The nine retired addresses redirect instead of returning an error, because old notifications still link to four of them.

The second pass was the database. The obvious move was to drop the board's tables and functions. Almost everything a drop would buy could be had with a revoke instead: take away permission to call the functions and leave them where they are. A revoke is undone by one grant. A drop isn't undone at all.

One function mattered most, the one that hired an applicant. It wrote into another account's data. Until that pass it was held shut only by a chain of conditions: no poster plan, so no job post, so no application, so nothing to hire. That's a state of the data, not a permission. After the revoke, no role can call it at all, and it still exists.

So on 1 August the revoke shipped, and the drop was designed and parked, behind four named conditions and a backup that has been restored in a test. Nothing was deleted.

Retiring a feature means following it into billing, stored data, permissions and old links. Where two changes buy the same protection, the one that can be undone ships first.