The Law Inside Our Code

When we made Premium purchasable, we assumed the legal part was a few pages of text in the footer. That was wrong. Some duties cannot be written into a text at all, because they dictate how a feature has to be built.

Four examples where that became particularly clear. Up front, so it is clear what this is: a description of our implementation, not legal advice. The rules below are German law, which is where AlphaCloud operates.

The cancellation button that may not have a login

Section 312k of the German Civil Code requires contracts concluded online to offer a directly reachable way to cancel. That produces requirements you cannot add afterwards in wording:

• The page has to work without signing in
• It has to sit in the footer of every page
• It needs two steps: enter, then confirm through an unambiguously labelled button
• A confirmation of receipt in text form has to go out

The last point drives the architecture. A cancellation is a unilateral declaration and takes effect on receipt. So it has to be logged and confirmed always, whoever it came from.

The form may never reject you

This is where the obvious approach nearly cost us a mistake.

The obvious approach: only accept the cancellation if the server ID and email match an active subscription. Sounds reasonable, and is wrong twice over.

First, it would lock out a genuine customer who mistypes their email or gives a different address. Their cancellation would not have been received, the subscription renews, and they hold evidence that they tried.

Second, and this is the more unpleasant part: the error message itself would be an answer. Anyone who gets back "no subscription found" learns that this server does not pay. A Discord server ID is not a secret, any member can read it. The form would become a tool for probing other people's servers.

The solution separates two things that feel like one:

	Condition
Receipt of the declaration	unconditional, always logged and confirmed
Execution of the cancellation	only when the submitted email matches the buyer on file

Everything else lands in a queue and is reviewed by a human. That is permissible because section 312k(2) explicitly allows asking for identifying details. Only a login in front of it is forbidden.

For the same reason the public response may only name the end date once identity is confirmed. Otherwise the confirmation becomes an oracle again.

The withdrawal that deliberately has a login

Right next to it sits a feature we built the opposite way: withdrawal with a pro-rata refund lives behind a sign-in.

That is not a contradiction. Section 312k covers cancellation, not withdrawal, and there is no duty to offer an online withdrawal form at all as long as the informal route stays open. The difference is the consequence: a cancellation acts on the future, a refund moves money now, and it cannot be pulled back.

Three rules that follow, which we do not soften:

No mandatory reason. Section 355(1) grants withdrawal expressly without giving reasons. The field is optional and has to stay optional, however tempting a required one would be for the statistics.

After 14 days only the automated route is declined, never the declaration. The period extends to up to twelve months and fourteen days if the customer was not properly informed. A blanket "too late" could therefore be wrong.

The protection against paying twice is pessimistic. The marker is set before the refund runs. If the refund then fails, the marker stays and a human takes over. Paying out twice is the only outcome that cannot be healed.

A Discord DM is not a durable medium

Section 312f(3) requires a contract confirmation on a durable medium, and it has to reproduce the consent that was given.

We first sent a Discord direct message, because that is the channel our customers are in anyway. That does not satisfy it. A DM lives on a platform we do not control, and it is neither storable nor unalterable in the sense the provision means.

So an email was added, and with it an uncomfortable dependency: if the mail credentials are not set, sending only writes a warning to the log and the duty is unmet. A statutory duty hanging off an environment variable is a state worth being aware of.

No VAT, and that has to read the same everywhere

AlphaCloud is a small business under section 19 of the German VAT Act. Prices are final prices, VAT is never shown.

That sounds like a footnote and is in truth a consistency task across many places: the pricing page, the checkout dialog, the terms, the privacy policy, the invoice footer and the configuration at the payment provider all have to say the same thing. We had an "excluding VAT" sitting there for a long time that was simply wrong.

And the AI

Since August 2026 the transparency obligations of the European AI Act apply in full. Anybody talking to an AI system has to be able to recognise that, at the latest on first interaction.

The most important sentence for us from that review: a legal page in the footer probably does not satisfy it. The disclosure has to happen where the interaction happens, so in the Discord message itself. That is why our AI ticket support introduces itself unprompted and has a visible button to switch it off. Our detailed assessment is on AI transparency.

The common thread

All four examples have the same shape: the duty looked like a text and was in truth a requirement on the structure. A login in the wrong place, an error message that reveals too much, a confirmation in the wrong channel, an ordering that allows a double payout.

So we now read legal text like a specification, and we check in the other direction too: does the code really do what our terms say? On exactly that question we found two genuine divergences, and there is a separate article about those.