Article

When ‘We Can’t Support That’ Becomes Its Own Kind of Shame

Two careful institutional answers left an intimacy-education project with the same practical question: what can we safely build when permission remains uncertain?

We asked a platform, plainly and in writing, before we built anything. We described the service in detail: consent-forward, communication-focused, no explicit content, built on lived relationship experience offered humbly rather than clinically. We wanted a clear answer, not a guess we’d find out about after the fact.

A quiet desk with an open laptop and notebook at dusk.

The first reply was careful and direct.

That was fair. Not boilerplate. Not a form rejection. Someone actually reading the proposal and saying that “close enough to the line” was the problem, regardless of what the service actually contained. The initial support exchange itself was quick and friendly. No judgment in the tone. The internal council took about a week between that first reply and the final decision. When the answer came, it was equally plain:

No specific clause was cited in either reply we received. The language stayed at proximity. That absence of a concrete explanation is part of the point, though it does not tell us everything about the platform's internal decision.

Around the same time we had almost the identical conversation with our payment processor about our own standalone site. We weren’t asking them to host anything. We were asking them to confirm, in writing, that a support model already running through our existing account (informational, age-verified, adults-only, explicitly not for sexual gratification) was covered before we built anything further on top of it. The answer took twenty-five minutes of “let me check with my team,” and landed here:

No cited violation. No specific clause. Just a category, “adult lifestyle / sexual-wellness education community,” handed sideways to a sales team for a supportability decision. The account stayed enabled throughout the conversation. Nobody told us it had been revoked or flagged for a violation. Account status never changed; what changed was our confidence that this new project could safely depend on it.

What sits hardest is the earlier email:

We had understood that as reassurance about the existing account. It was not, as the later conversation made clear, a promise that every future service would be supported. The distinction is understandable on paper. It still leaves a small project deciding what it can risk building.

Here is how it felt to us, laid side by side. Two unrelated institutions met a non-explicit project about intimacy and consent with uncertainty or refusal. Neither said the conversation was wrong. Neither pointed us to a specific harm or violation. The platform declined; the processor deferred a supportability decision. We cannot know their full internal reasoning, but we did learn that transparency from us did not guarantee a clear answer from them.

If we had to pick the single sentence that nails “discretion instead of violation,” it is the platform’s own: a service that “sits close enough to that line that I am not going to give you an off-the-cuff yes or no.” They never said it broke anything. They said proximity itself was the problem.

It is more than the absence of a direct Terms of Service violation. It is a grey area in which the answer can be no without our knowing exactly what would have made it yes.

That distinction, discretion instead of violation, matters less than it sounds like it should when you are deciding what to build. We asked before we built. We were honest about the content. We got one careful, respectful no and one answer that left supportability to another team. Different outcomes, same practical question: how much of our future can rest on a permission we cannot clearly confirm?

Do that enough times, across enough institutions, and the lesson stops being about terms of service or restricted business categories. It becomes about which parts of being human are allowed to be discussed and supported in daylight, and which parts have to go build their own room somewhere else, funded and hosted on their own terms, because no one else’s discretion will extend that far.

We don’t think the answer is resentment toward companies managing real risk at scale. We think the answer is what we were already doing. Orgasmaphoria exists because the room needs to exist somewhere, built on our own infrastructure, under our own terms, even if it means no institutional shortcut and no borrowed audience. Two honest, careful “no”s in a row didn’t change that. They just confirmed, plainly, why the room we are building ourselves still has to exist.

The practical cost was time. Weeks spent asking the right way, in writing, before building anything, only to end up exactly where we could have started: on our own site, under our own terms. Not money lost. Not reach lost. But designing around an uncertain answer is still work. It means building a route that can survive a future no, keeping promises to readers narrower than a platform's promises to us, and accepting that independence can be expensive even before a bill arrives.

The decision to keep building is a quiet, powerful moment of choice. This project is personal. It is not going to make us rich. It is not going to reach many people. It is simply going to exist for us.

We also watched search impressions climb during the first three weeks after launch and then fall close to zero. Our diagnostic tools did not show a clear issue. That is frustrating, but it is not evidence of a hidden flag or a verdict on the subject. Search visibility changes for many reasons, and we do not know which one applies here. The uncertainty feels familiar; it is not proof that the same decision was made a third time.

None of that changes the work. It only clarifies the conditions under which the work has to happen.

Finish & rate
Written byAmanda & PeterFor Orgasmaphoria

Member conversation

Comments

Comment policy →

Comments are available to signed-in Voyeur members and above.

Sign in