How do you stop purchased videos from being passed around?

Not with copy protection — that is circumventable and punishes paying customers. Instead the videos sit with a specialist provider and are delivered only through short-lived, server-signed references. An address someone forwards stops working shortly afterwards. That reliably stops casual sharing without burdening the normal flow.

What does GDPR compliance actually mean for a sales platform?

Above all: that someone can actually answer a deletion request. That sounds obvious and is not — in the first version there was no path in the production system to delete a customer at all. Beyond that: processing agreements with the providers actually used, EU locations where possible, and backups that do not carry plaintext customer data to a third location.

Why a dedicated server instead of a ready-made course platform?

Because ready-made platforms take a revenue share and place themselves between the instructor and her customers. At modest course volumes the difference quickly reaches three figures a month, and the customer relationship stays where it belongs. If the maths works out differently, the ready-made platform is the better recommendation — and I say so.

Why audit a system you built yourself?

Because otherwise you never find your own blind spots. Four weeks after launch I systematically checked the running system against data loss, GDPR obligations and money flows — each finding with its impact, a confidence rating and the commit that fixes it. Three serious findings came out of it.

LiveFaszienyoga mit Melanie

A course platform with payments, protected video, and an audit against myself

Faszienyoga mit Melanie sells online courses directly to participants — with checkout, protected video delivery and customer data under the GDPR. Four weeks after launch I audited the running system and found three issues I had built myself.

Visit the project

Verified numbers

Commits: 125Source: git log, 5 Jul 2026 to 11 Aug 2026
Lines of TypeScript: 22,640Source: Repository excluding dependencies, as of 11 Aug 2026
Test files: 40Source: Repository, as of 11 Aug 2026
Documented architecture decisions: 4Source: docs/adr/ — video provider, backend, deployment, payments
Issues found and fixed in the self-audit: 3 seriousSource: docs/audit/, audit of 4 Aug 2026

Starting point

A course instructor wanted to offer her fascia yoga courses online without putting them on someone else's platform and handing over both a revenue share and the customer relationship. So what was needed was her own checkout, videos that cannot simply be passed around, and an admin area she can run herself.

Outcome

A running platform with real paying customers. Videos are delivered through short-lived signed references rather than open URLs, database backups run automatically to a second location, and the operator can answer Art. 17 GDPR deletion requests herself — which was not the case before the audit.

Why not just use a ready-made platform

Platforms exist for selling online courses. They take a revenue share and place themselves between the instructor and her customers: the customer data belongs to the platform, communication runs through it, and the price rises with success.

For a course business with modest but regular revenue that is an ongoing drain — and for an instructor, the customer relationship is the actual asset. Hence a platform of her own.

This is explicitly not a general recommendation. With unclear demand or very few sales, the ready-made platform is the cheaper answer.

The four decisions that determined everything else

Before the first line of code came four decisions, each recorded in writing with alternatives and reasoning: video provider, backend platform, deployment and payments.

The most interesting is video. Serving video yourself is technically possible and practically a bad idea — transcoding into multiple qualities, delivery to mobile connections, bandwidth costs. So: a specialist provider with a Frankfurt location.

The real question was protection. Copy protection is circumventable and punishes paying customers. The answer sits one level down: the server signs a short-lived reference for each playback. Anyone forwarding an address forwards something that stops working shortly afterwards.

Four weeks after launch: the audit against myself

On 4 August 2026 I systematically reviewed the running system — not the code I had written, but what actually happens in production, with real customer data and real money in play.

Three findings came out, all of them mine:

There was no way to delete a customer. Not a single path in the production code. The operator could not have answered an Art. 17 GDPR deletion request without me — and that is not a theoretical situation but an email that can arrive any day. Fixed, and fixed so that she can do it herself.

The backups carried plaintext customer data to a second location. The automatic database backups ran as intended — but email addresses and purchase histories sat in them unencrypted.

Price changes would have rewritten the past. Raising a course from €49 to €79 would have made already-completed sales look different retroactively. For bookkeeping and refunds that is a real problem.

Each finding is documented with impact, a confidence rating and the commit that fixes it.

Why I write this down publicly

Because it is the most honest part of this case study. You can tell it as though everything was right from the start — and then it is not believable, because nobody works that way. Or you tell how the mistakes were found.

The difference between someone who makes mistakes and someone you trust with a system is not the number of mistakes but whether they go looking. Reviewing your own system against data loss, GDPR and money flows four weeks after launch is not a given, precisely because it ends uncomfortably.

The same approach underlies the SEO project for malexfotografie.de: there too the closing audit found a mistake I had introduced myself. That is not coincidence but the method.

What is left open

User numbers and revenue development are deliberately absent — they belong to the client, not to me. What is evidenced: the platform runs, it takes money, and the operator can work it without me.

Frequently asked

How do you stop purchased videos from being passed around?: Not with copy protection — that is circumventable and punishes paying customers. Instead the videos sit with a specialist provider and are delivered only through short-lived, server-signed references. An address someone forwards stops working shortly afterwards. That reliably stops casual sharing without burdening the normal flow.
What does GDPR compliance actually mean for a sales platform?: Above all: that someone can actually answer a deletion request. That sounds obvious and is not — in the first version there was no path in the production system to delete a customer at all. Beyond that: processing agreements with the providers actually used, EU locations where possible, and backups that do not carry plaintext customer data to a third location.
Why a dedicated server instead of a ready-made course platform?: Because ready-made platforms take a revenue share and place themselves between the instructor and her customers. At modest course volumes the difference quickly reaches three figures a month, and the customer relationship stays where it belongs. If the maths works out differently, the ready-made platform is the better recommendation — and I say so.
Why audit a system you built yourself?: Because otherwise you never find your own blind spots. Four weeks after launch I systematically checked the running system against data loss, GDPR obligations and money flows — each finding with its impact, a confidence rating and the commit that fixes it. Three serious findings came out of it.

← All work