Version 0.4
13 changesFixed4 October 2026
Beta signup link on public remix pages opens the signup form
On a public remix page, both 'Sign in to join' and 'Sign up as beta tester' opened the sign-in form, so new visitors still had to find the signup tab themselves.
- The /auth page now accepts a 'mode' search parameter ('signup' or 'signin') that preselects the right form.
- The 'Sign up as beta tester' link on public remix detail pages passes mode=signup, landing visitors directly on the account creation form with the redirect back to the remix preserved.
- Invite links and plain sign-in links are unaffected.
What this means for you: New visitors who want to join a remix land straight on the signup form instead of the sign-in form.
Security4 October 2026
Safer uploads, invitations and confirmation links
A round of server-side hardening: uploaded files are measured by their real stored size, file checks can never delete someone else's file, invitation notes can no longer carry links, and confirmation emails only link back to TeamStems.
- Storage limits are now checked against the actual size of the stored file, not the size the browser reports.
- Only the project owner can register source files, and only files under their own upload folder that are not already registered.
- Submission files must sit in the uploader's own folder for that project before they are checked or registered.
- Personal messages in project invitations are limited to 300 characters and may not contain links or email addresses.
- Confirmation and sign-in links only redirect to TeamStems addresses; anything else falls back to the default page.
What this means for you: Nothing changes for normal use; misuse of uploads and invitations is blocked on the server.
New21 September 2026Highlight
Sign up as beta tester without an invite
Visitors who found a public remix used to hit a dead end: TeamStems was invite-only. Anyone can now create a beta tester account with email confirmation; the account stays locked until an admin approves it.
- The sign-in page offers 'Sign up as beta tester' when no invite link is used; public remix pages link to it next to 'Sign in to join'.
- The account is created unconfirmed, a confirmation email is sent (the account is rolled back if that mail fails) and the Terms/Privacy acceptance is recorded.
- A beta application row is stored as 'pending'; admins get an in-app notification and review applications in the new Admin > Beta testers tab (approve / reject).
- Until approved, the server refuses joining public remixes, starting projects and requesting creator access. Accounts created through invites are unaffected.
- Pending testers see a banner on their dashboard explaining they are waiting for approval; on approval they get a notification.
What this means for you: Interested remixers can sign up straight from a public remix page and get in once an admin approves them.
Fixed20 September 2026
Saving a full-track public preview works for MP3 sources again
Owners who ticked 'Let visitors hear the full track' got 'That snippet is unexpectedly large' whenever their preview track was an ordinary MP3, so the full-track option could not be saved at all.
- The public snippet is always re-encoded at 192 kbps in the browser. For a 128-160 kbps source MP3 that render is larger than the original file, while the server capped a full-track upload at the original file's size.
- createSnippetUploadUrl now receives whether the save is a full track plus the rendered length, and sizes a full-track upload against that length at our own render bitrate (the source size is only a floor).
- Region snippets keep their strict ceiling based on the admin setting 'public_preview_max_seconds'.
What this means for you: Released songs can be published with the whole track as the public preview, whatever the bitrate of the source file.
New19 September 2026Highlight
Owners pick the exact snippet visitors may hear
The public remix page used to stream the whole reference track, which is a problem when the original song has not been released yet. Owners now drag a region on the waveform, and only that region is rendered into a separate MP3 that the public page plays.
- Project settings > Public listing shows a waveform region picker for the chosen preview track, with an audition button and a live region label.
- The selected region is rendered to a 192 kbps MP3 in the owner's browser (Web Audio + LAME), with short fades, and uploaded to a new private 'project-previews' bucket.
- The region length is validated again on the server against the admin setting 'public_preview_max_seconds' (default 30, range 5-600), and the stored file is checked for real MP3 bytes and a sane size.
- An explicit 'Let visitors hear the full track' switch exists for released songs; it is off by default.
- The public preview link is signed from the snippet path only, so the full reference track can no longer be reached from the public page, not even through developer tools.
- Projects cannot go public until a snippet has been rendered; the publishing checklist now asks for it.
What this means for you: Unreleased tracks stay protected: visitors hear a short teaser, and the full song and stems stay behind joining the project.
New18 September 2026Highlight
Public remix projects with an open overview page
TeamStems steps outside the invite-only bubble for the first time: a project owner can put a remix project on a public page at /remixes, where anyone — account or not — can see the artwork, read what the artist is after, play the preview and see how much time is left. The stems themselves stay exactly as protected as before. A project is private by default and only becomes public when the owner meets every requirement and flips the switch.
- A new public overview page at /remixes lists every open public remix project, sorted by deadline ascending, so the most urgent (and short flash remixes) sit on top.
- Each card shows the hero artwork, title, artist, genre, BPM, key, a live deadline countdown and an inline waveform player for the preview track.
- A public detail page at /remixes/<project> adds the description, the artist's instructions, the track details and the join flow, with its own page title and share metadata.
- Requirements before a project may go public: a deadline that lies in the future and inside the admin window, a hero image (JPG, PNG or WebP up to 5 MB), an MP3 preview track and the project being open. The owner sees this as a live checklist in the project settings.
- The deadline is stored as an exact date, not as a number of months, so a one-week flash remix and a three-month campaign both work; the admin setting 'Public remix deadline window' only caps how far ahead the date may be (92 days by default, adjustable between 7 and 365).
- The preview must be a real MP3. An uncompressed WAV would cost enormous bandwidth once visitors start streaming it, so a WAV or AIFF dropped into the preview field is converted to a 192 kbps MP3 by the creator's own browser before upload; only the small MP3 travels over the line.
- Access control for remixers is unchanged in spirit and explicit in practice: visitors can only listen and read, joining requires a signed-in account, the owner approves each remixer unless they switch on 'Auto-approve remixers' (off by default), and the project agreement must still be accepted before a single stem can be downloaded.
- Public data is served through a narrow database view that only exposes safe columns; invite tokens, agreement text and owner identities are not part of it, and the hero artwork lives in a private bucket served through short-lived links.
What this means for you: Artists can now open a remix project to the world and collect remixers from outside their own contact list, while every stem stays behind an account, an approval and a signed agreement.
New18 September 2026Highlight
AI generated hero artwork for public remixes (admins)
A public remix project needs a hero image, and not every artist has cover art lying around. Admins can now describe the artwork they want in a sentence and have it generated by AI straight inside the project settings, instead of hunting for a picture first.
- The 'Public listing' block in the project settings shows a 'Generate with AI' field for users with admin rights; everyone else keeps the normal upload button.
- The prompt sent to the model combines the admin's description with the project's own details (title, artist, genre) and fixed art direction: landscape 16:9, cinematic lighting, and explicitly no text, logos or watermarks.
- The description is capped at 500 characters and must be at least a few words; empty or oversized input is refused before any AI call is made.
- The generated image is stored in the same private artwork bucket as an uploaded hero, is shown through a short-lived signed link, and replaces (and deletes) the previous hero image.
- Generation happens server-side with the platform AI key; the key never reaches the browser. Rate limit and out-of-credit answers are surfaced as plain messages instead of a silent failure.
What this means for you: Admins can publish a remix project with proper artwork in seconds, by describing the cover they have in mind instead of uploading a file.
Improved18 September 2026
Pick an existing reference track as the public preview
Most projects already have a reference mix uploaded. Instead of uploading that same file a second time as the public preview, owners can now simply point at it.
- The 'Preview track' block in the project settings lists the project's reference tracks that qualify as a preview, each with a 'Use' button.
- Only reference-category files are listed, and only when they are real MP3s of at most 30 MB — WAV, AIFF and stem files never appear, so the streaming preview stays small.
- Selecting a track reuses the existing stored file; nothing is copied or re-uploaded, and the public readiness checklist updates immediately.
- Uploading a new preview (including the in-browser WAV to MP3 conversion) keeps working exactly as before.
What this means for you: Owners can reuse the reference mix they already uploaded as the public preview with one click, instead of uploading it again.
Improved18 September 2026
The AI artwork description is remembered
Generating cover art is rarely a one-shot job. The description an admin typed is now stored with the project, so it reappears in the field and can be tweaked and re-run instead of retyped from scratch.
- A new field on the project keeps the last description that was used to generate the hero image.
- Opening the public listing settings pre-fills the AI field with that stored description.
- Uploading a hero image by hand clears the stored description, so the field never suggests a prompt that does not match the visible artwork.
What this means for you: Admins can refine their artwork description step by step, because the last one they used is always still there.
Improved18 September 2026
Remix cards show a short excerpt of the project
The open remix overview showed artwork, metadata and a preview player, but nothing about what the project actually asks for. Each card now carries a short excerpt of the project's own words.
- A new pure helper builds the excerpt: it prefers the project description and falls back to the brief/instructions when no description was filled in.
- Whitespace and line breaks are collapsed, and longer texts are cut at around 220 characters on a word boundary with a trailing ellipsis, so cards keep an even height.
- Projects without any description or brief simply show no excerpt instead of an empty paragraph.
What this means for you: Visitors can tell at a glance what each open remix project is about, before opening the detail page.
Fixed18 September 2026
Remix pages know you are signed in, and the detail page opens again
Two problems on the public remix pages: the header always offered 'Sign in', even for signed-in members, and 'View remix & stems' did nothing.
- The public page chrome now reads the active session and shows a 'Dashboard' link instead of 'Sign in' when someone is already signed in; the slot stays blank for a moment while the session is read, so nothing flickers between the two states.
- A shared useSignedIn hook replaces the duplicated session-listening logic, so the header stays in sync when someone signs in or out in another tab.
- The remix overview moved from routes/remixes.tsx to routes/remixes.index.tsx. As a plain sibling of remixes.$projectId.tsx it acted as a layout parent without an <Outlet />, which silently swallowed the detail page and left the click with no visible effect.
- A route-file test guards that arrangement so the detail page cannot be shadowed again.
What this means for you: Signed-in visitors see a Dashboard link on the public remix pages, and 'View remix & stems' opens the project again.
Improved18 September 2026
Project workspace shows the public cover artwork
The cover artwork uploaded or AI-generated for the public remix listing was only visible on the public pages. It now also appears inside the private project workspace, under the details of the project.
- The project loader signs the artwork from its private storage bucket for one hour and returns it alongside the other project details.
- The Details panel on the project overview shows the image below the deadline counter, with a small 'Public cover artwork' caption.
- Projects without cover artwork are unchanged: no placeholder and no empty frame.
What this means for you: Owners and participants see the project's cover artwork right in the project workspace.
Improved18 September 2026
Public preview player says the full track needs joining
The preview player on a public remix page can carry a short teaser instead of the finished song, for instance when the original has not been released yet. The page now says so explicitly.
- A line under the public preview player explains that this is a preview only and that joining the project unlocks the full track and the stems.
- The preview track itself stays a deliberate owner choice: an existing MP3 reference track can be reused as the public preview, or a separate short teaser can be uploaded.
What this means for you: Visitors understand that what they hear is a preview and that joining gives them the full track and stems.
Version 0.3
21 changesNew18 September 2026Highlight
Weekly beta digest for members
Administrators can compose a weekly newsletter about how the platform is growing: an AI writes a first draft from the real facts, the editor rewrites it freely and sends it after a preview and a test mail.
- The draft is written from the changelog of that week plus the platform numbers, never from invented material.
- Live preview in the real email styling, a test mail to yourself, and sending with a confirmation showing the exact number of recipients.
- Earlier editions are kept, so the same week cannot be mailed twice.
- Members can switch the digest off in their profile; it is on by default.
What this means for you: Beta members hear every week what the platform can do that it could not do before.
Improved18 September 2026
A changelog that ships with the app
Every change is documented in the application itself, so production always has the full, detailed release history available as the source for the weekly digest.
- Entries carry a date, version, category, a full description, detailed bullets and the member-facing impact.
- The digest screen shows which changes fall inside the current week and hands them to the AI writer.
- Changes that shipped earlier remain available as release highlights.
What this means for you: Newsletters are based on what really shipped, not on someone's memory.
Improved18 September 2026
Digest can open with a fresh explanation of what TeamStems is
The digest generator gained an option to let the AI open the newsletter with a section that explains what TeamStems actually does — reworded every week so it never reads like a copy-paste, and ideal for members who just joined.
- A checkbox 'Explain what TeamStems is' in the admin digest screen switches the section on; it is off by default.
- The AI receives a fixed set of accurate facts (invite-only beta, stems, submissions, in-browser playback, per-project terms, creator access) and rewrites them in its own words under the heading 'New to TeamStems?'.
- Because the facts are supplied and rewriting is required, the explanation stays accurate while the wording stays fresh.
What this means for you: New beta members see a friendly recap of what the platform is for, right at the top of the weekly mail.
Improved18 September 2026
Digest can close with a complete feature overview
The digest generator gained a second option: let the AI close the newsletter with 'Everything TeamStems can do' — a compact, bulleted total picture of the platform, grouped by capability and ordered from the core flow outward.
- A checkbox 'Add a complete feature overview' in the admin digest screen switches the section on; it is off by default.
- The overview is built from a curated, factual feature list grouped into Remix projects, Inviting remixers, Sharing and downloading files, Remixing and feedback, Staying informed, and Platform and safety.
- The AI compresses each feature to one short line and keeps the group order, so the result reads as one clear total picture: create remix projects, invite remixers, upload versions, and everything around it.
What this means for you: Members — especially newer ones — see the full range of what the platform offers in one quick scan.
Improved18 September 2026
Digest explainer now mentions the long-term vision
When the 'Explain what TeamStems is' option is on, the AI also tells readers where the beta is heading: a public, openly accessible collaboration platform — not just for remixes, but also for mixing and mastering projects, vocal recordings and producer collaborations.
- ABOUT_TEAMSTEMS_FACTS gained a ninth fact stating the long-term goal: a public collaboration platform for remixes, mixing/mastering projects, vocal recordings and producer collaborations.
- The prompt rule for the 'New to TeamStems?' section now instructs the AI to include the vision, so new members understand the beta is building toward something bigger.
- The explanation still stays accurate: the vision is framed as the long-term goal, while the current state remains an invite-only beta focused on remix projects.
What this means for you: New members reading the weekly digest learn not only what TeamStems does today, but where it is going — so they can picture the bigger platform they are helping test.
Improved18 September 2026
Weekly digest only goes to confirmed, real members
The recipient list for the weekly beta digest is now filtered to registered accounts with a confirmed email address, excluding internal seed/test accounts. People with an outstanding invitation were already excluded because they have no account yet, and that stays true.
- New pure helpers in src/lib/digest.ts: isEligibleDigestRecipient and digestRecipientEmails, plus DIGEST_EXCLUDED_EMAIL_DOMAINS (teamstems.test, example.com).
- A recipient must satisfy three conditions: profiles.email_digest = true, a non-null email_confirmed_at on the auth account, and an address outside the excluded internal domains.
- src/lib/digest.functions.ts gained a shared resolveRecipients(admin) helper so the count shown in the admin Digest tab and the actual send use exactly the same selection — the confirmation dialog can no longer promise a different number than what is mailed.
- Pending project invites and pending platform invites are structurally excluded: no account, no profile, no digest.
What this means for you: The number shown before sending the newsletter now matches the real audience: only members who signed up, confirmed their email and kept the digest switched on. Invited people who never completed signup no longer count and never receive the newsletter.
Fixed18 September 2026
Waitlist email field no longer collapses on phones
On the public landing page the email field of the waitlist form shrank to a sliver on small screens, while the button next to it kept its full height. The field now matches the button at 48 pixels tall on every screen size.
- Cause: in the stacked mobile layout the field used flex-1, which sets a zero flex-basis along the vertical axis and overrode its fixed height, collapsing it to the line height of about 20 pixels.
- Fix in src/routes/index.tsx: the field is full width on mobile and only becomes a flexible column from the small breakpoint upward, so its height is respected everywhere.
- Verified in a real browser at 390x844: the input and the Notify me button are both 48 pixels tall.
What this means for you: Signing up for the waitlist from a phone is comfortable again: the email box is as tall and tappable as the button next to it.
New18 September 2026Highlight
Public changelog page at /changelog
The full release history that already shipped inside the application is now readable by anyone at teamstems.com/changelog, presented as a timeline grouped per release with category labels and a plain-language note on what each change means for members.
- New route src/routes/changelog.tsx with its own page title, description and social sharing metadata.
- Entries are grouped per release (newest release first, newest change first inside a release) through a new pure helper changelogByVersion in src/lib/changelog.ts.
- Each change shows its date, a colour-coded category label (feature, improvement, fix, security, legal), the full description, the detail bullets and a highlighted 'What this means for you' line.
- A filter row lets visitors show everything or narrow down to one category; highlighted changes carry a small marker.
- The page is linked from the footer of the landing page and the footer inside the app, next to Terms and Privacy.
What this means for you: Members and visitors can see at a glance how fast the beta is moving and exactly what shipped in each release, without waiting for the weekly newsletter.
Improved18 September 2026Highlight
Public architecture and development principles
The public changelog now includes a dedicated Architecture section that explains not only which technology powers TeamStems, but how the product is divided into layers, how access and private files are protected, how background work supports growth, and how the platform intends to move towards greater digital sovereignty over time.
- The technology overview names the production foundation — React, TanStack Start, TypeScript, Tailwind CSS and Lovable Cloud — and visualises the flow from the product interface through validated server functions and reusable domain rules to data and private file storage.
- The security section documents deny-by-default access, server-side authorisation, row-level data policies, private audio storage and short-lived signed links rather than relying on browser state or public file addresses.
- The scalability section describes indexed data access, narrowly loaded views, independent background processes for ZIP files, reminders, retention and inspection, shared archive jobs and the role of automated regression tests.
- The sovereignty section sets an honest long-term direction around portable TypeScript, SQL and web standards, data exportability and replaceable service boundaries. It deliberately presents sovereignty as an incremental goal rather than claiming infrastructure independence that does not yet exist.
- Agentic development is named as a core construction method: AI agents broaden the available expertise across design, engineering, security, testing and documentation, while human direction, final editorial judgement, explicit architecture rules, tests and the production changelog preserve the quality bar.
- Architecture and Release history now have direct section links at the top of the page, and the architecture layout adapts from a four-stage flow on wide screens to a readable stacked view on phones.
What this means for you: Members and visitors can inspect the thinking behind TeamStems as well as its feature history, including how quality is protected while AI agents help build the platform.
Security18 September 2026
Uploaded files are now inspected on the server as well
Until now the check that an uploaded file really is audio, MIDI or a project file ran only in the browser, which meant it could be skipped by calling the upload endpoints directly. The same inspection now runs again on the server, reading the real first bytes from storage before a file is registered and becomes downloadable for other members. In addition, draft agreement clauses are no longer readable by members.
- New pure helpers in src/lib/file-inspection.ts: BLOCKED_UPLOAD_EXTENSIONS (a deny list of program and script formats), isExecutableHead (Windows PE, ELF, Mach-O and shebang scripts) and checkUploadedFile, which combines the name check, the executable check and the existing magic-byte comparison.
- New src/lib/file-verify.server.ts reads the first 64 bytes of the stored object through a short-lived signed link, applies checkUploadedFile, and deletes the object from storage when it fails, so a rejected upload never becomes a row.
- registerSourceAsset in src/lib/files.functions.ts and both createSubmission and addSubmissionVersion in src/lib/submissions.functions.ts now run this verification before any database row is written.
- Exotic DAW project formats without a known signature stay allowed, so real studio work is not blocked.
- Database migration 0012 changes the read policy on agreement_clauses from USING (true) to USING (is_active = true), so unpublished or draft clauses are no longer visible to signed-in members; admin management keeps working through the service-role admin queries.
- Regression tests cover the new upload gate and both changes in src/lib/file-inspection.test.ts and src/lib/security-regression.test.ts.
What this means for you: Files you download from a project are checked twice before they reach you, so a program disguised as a stem cannot be slipped into a project, and only published agreement points are visible.
Improved18 September 2026
Architecture moved to its own tab on the changelog page
The architecture deep-dive used to sit at the very top of the changelog page, pushing the release history below the fold. It now lives behind a second 'Under the hood' tab, so the release timeline is the first thing you see. A teasing callout at the bottom of the release list — 'Wanna know what's under the hood, and how we build software?' — invites the curious to switch tabs.
- The changelog page now uses the existing Tabs component (src/components/ui/tabs.tsx) with two tabs: 'Release history' (default) and 'Under the hood'.
- The anchor-based nav bar (#architecture / #releases) was removed; tabs replace it.
- Release history is the default tab so new and returning visitors immediately see what shipped.
- A bordered teaser callout with a wrench icon sits at the bottom of the release list and switches to the Architecture tab on click.
- The architecture content itself (layers grid, four pillars, agentic-development callout) is unchanged — just moved into the second tab.
What this means for you: When you open the changelog you land straight on the release history. If you're curious about the tech behind TeamStems, a callout at the bottom of the list takes you to the architecture deep-dive.
Improved18 September 2026
Architecture page speaks in a personal voice
The architecture section now reads as written by one person: I explain that I bring over 20 years of experience as a software developer, that I run TeamStems as a small business building it in the off-hours, and that agentic development combined with my own experience gives me a breadth of expertise I could never reach alone. The agentic-development callout, the section intro and a closing note are all in the first person, and the page closes with a personal greeting from Rob at Spring Morning Software.
- AGENTIC_DEVELOPMENT in src/lib/architecture.ts rewritten from 'we' to 'I': title, body and assurance now use the first person and mention the small-business, off-hours context.
- The architecture tab intro on the changelog page now opens with 'I'm building TeamStems to be a durable music collaboration platform'.
- A personal closing card was added at the end of the architecture tab, thanking the reader and signing off as Rob, Spring Morning Software.
- Test assertions for 'Agentic development', 'Human direction' and 'automated tests' remain satisfied.
What this means for you: The architecture page feels like it's written by a person, not a company. You learn who's behind TeamStems, that it's a side project built with care, and that agentic development widens the expertise rather than replacing human judgement.
Fixed18 September 2026
Big-archive progress checks now keep a steady five-second pace
While a large ZIP was being prepared in the background, the source files page checked the progress continuously instead of once every five seconds. Each status reply replaced the job state with a freshly built object, which restarted the polling effect and immediately fired the next request, so the browser chained calls at network speed for as long as the tab stayed open. The polling effect now keys on the job id alone and updates state functionally, so the five-second interval actually paces the checks.
- src/components/project/SourceFilesTab.tsx derives a stable pollingJobId (null once downloads are ready or the job failed) and uses it as the only state dependency of the polling effect.
- setZipJob now takes a functional updater guarded on the job id, so a late response can never overwrite state belonging to another job.
- getZipJobStatus runs several database queries plus signed-URL creation per part; pacing the poller cuts that load from hundreds of calls per minute to twelve.
What this means for you: Waiting for a big download no longer makes the app sluggish or risks running into rate limits — the progress indicator updates calmly every few seconds while the archive is built.
Improved18 September 2026
Architecture page gains a visual layer diagram
The Under the hood tab on the changelog page now opens with an illustration of the four TeamStems architecture layers — product interface, validated server functions, domain rules and access control, and data with private file storage — connected by waveform lines in the studio look of the platform.
- The diagram (src/assets/architecture-diagram.jpg) mirrors ARCHITECTURE_LAYERS from src/lib/architecture.ts so the visual and the written layers always tell the same story.
- A caption explains the request flow: every request travels down through validation and access rules before it reaches data or files.
- The image loads lazily below the written layer list, so the release history tab stays fast.
What this means for you: Curious members can see at a glance how TeamStems is put together, instead of reading a wall of text.
Improved18 September 2026
Architecture page grounds digital sovereignty in the Netherlands and the EU
The digital-sovereignty pillar on the Under the hood tab now states explicitly that TeamStems is based in the Netherlands and the EU, that I am aware of the wider world and its politics, and that the goal is to shield members from all of that so they can simply make music. Two supporting points were added: European data-protection and privacy law shape how member data is handled today, and the platform absorbs the complexity of where things run and how data moves so members can focus on remixing and collaborating.
- ARCHITECTURE_PILLARS in src/lib/architecture.ts: the 'A path to digital sovereignty' summary now opens with the Netherlands and EU context and the intent to keep members out of world politics.
- Two new pillar points cover European data-protection law as the starting point for sovereignty, and the member-facing goal of absorbing infrastructure complexity.
- The existing points on portable technology, data ownership and deliberate adoption remain.
What this means for you: Members know TeamStems is run from the Netherlands with European privacy law in mind, and that the platform is built so world events don't get in the way of making music.
New17 September 2026
Reminders for unanswered invitations
An invitation that stays untouched now gets a follow-up automatically, for both project invitations and personal platform invitations.
- A first reminder after 2 days, a second after 5 days.
- The day-2 mail says the link is still valid; the day-5 mail says it expires soon.
- Revoked, expired and already used invitations are skipped.
- Each reminder is recorded, so nobody receives the same one twice.
What this means for you: Invitations that got buried in a mailbox resurface by themselves.
Legal17 September 2026
Terms and privacy policy version 2
Both documents were rewritten to describe the platform as it works today, and new accounts accept the new version.
- Describes invite-only registration, creator access, storage limits and automatic clean-up.
- Describes file and archive inspection and the project agreement between owner and participants.
- Describes email preferences and the rights members have over their data.
- Dutch law and GDPR, effective 17 September 2026, with the previous version visible in the history.
What this means for you: The rules match what the platform actually does.
New12 September 2026Highlight
Platform invitations, separate from project invitations
Administrators can invite people to the platform itself, without giving them access to any project.
- Personal invitation: one email address, usable once, with an expiry date and revocable.
- General beta invitation: a shared link with an expiry date, a maximum number of uses and visible usage.
- Both can be revoked at any moment.
- Someone who joins this way lands on the normal dashboard, with no project membership and no creator access.
- Every field in the admin form has a heading and an explanation, including the 30-day default validity.
What this means for you: New beta testers can be invited without first attaching them to a project.
New11 September 2026
Automatic clean-up of finished projects
Beta projects are cleaned up on a fixed schedule so storage does not grow without end, with warnings to the owner long before anything disappears.
- Source files are removed 60 days after a project closes.
- Submission files are removed 90 days after a project closes.
- A non-administrator beta project is removed in full at most 180 days after it was created, including files, submissions, comments, participants and agreements.
- The owner is warned 30 and 7 days before final removal.
- Projects owned by administrators are exempt from the 180-day rule.
- A daily job performs the clean-up.
What this means for you: Old projects tidy themselves up, and you are warned in time to save your work.
New10 September 2026Highlight
Creator access: request the right to start your own projects
Everyone now sees 'Start a project'. Members without creator access get an explanation and can request it; administrators approve or decline, and approved creators use the normal remix project flow.
- Request states: none, pending, approved, declined.
- Creator access is an entitlement, not a role, so it can later come from a subscription without rebuilding anything.
- The request screen shows exactly what you get once approved instead of raw numbers.
- Administrators can override the limits per creator.
What this means for you: Starting your own remix project is no longer reserved for administrators.
New10 September 2026
Beta limits on projects and storage
Beta creators work inside clear, centrally configured limits, with a warning well before anything is blocked.
- One active project at a time; draft and open count, closed and archived do not.
- 25 GB of storage per creator, 10 GB per project and 5 GB per file.
- At about 80% of the storage limit a warning appears; at 100% only new uploads are blocked.
- Participants and invitees are not limited.
- Administrators have no limits and can raise them per creator.
What this means for you: You always know how much room you have before an upload is refused.