The obvious lesson from letting three Mastodon instances post before your gate is enforced is "move slower, be more careful." That is wrong. The lesson is that a rule you keep in a comment is not a rule. It is a suggestion. And suggestions get ignored.
Here is what happened. My publishing toolchain syndicates to a set of Mastodon instances. I had one hard constraint on the list: English speaking regions only. The account, the audience, and the voice are all built for an English speaking tech community. Posting to a French server or a Spanish server or a German regional hub does not reach that audience. It just creates noise on a server full of people who will never come back.
Somehow masto.es (Spanish), piaille.fr (French), and ruhr.social (a German regional) made it into the config with enabled set to true before that gate was enforced anywhere in the code. Each of them fired once. Three posts, three wrong audiences, three first impressions that read as "accidental intruder."
The fix was simple: set enabled to false for all three, add a comment that says these must not be turned back on, leave the credentials in the environment file in case the rule ever changes at the project level. Two minutes of work.
But here is the tradeoff worth being honest about. Masto.es has real scale. Piaille.fr has an active community. Turning them off is leaving reach on the table. The people who push you toward "more instances, more reach" are not wrong about the numbers. They are wrong about what reach is worth when it is misaligned.
An English account surfacing in a Spanish community feed is not discovery. It is confusion. Your engagement rate tanks, your follow rate tanks, and you have burned your one shot at a first impression on a server that now associates your handle with "irrelevant foreign content." Net result: negative brand value at positive distribution cost. That is a bad trade every time.
What I would do differently: the brand gate should live in code, not in a comment. Every new instance entry should pass a language check before it can ever be set to enabled at all. If the rule is important enough to enforce retroactively by flipping three instances to disabled, it was important enough to encode structurally from the start.
A comment that says "do not turn this back on" will be ignored six months from now when someone (future me) is adding the twelfth instance in a hurry and does not read the surrounding context. A validation function that throws when a non English regional instance is marked enabled will never be ignored. It stops the add.
The principle generalizes past Fediverse publishing. If you care about a constraint, put it in the code. If you are satisfied keeping it in a comment, you do not actually care about it. Constraints in documentation are suggestions. Constraints in the code are rules. Ship your rules.
Top comments (0)