Trust
Security
Last updated October 2, 2026
StudioSide holds your bookings, your clients’ contact details, and your money. This page says exactly how that data is protected, who else can see it, and what we have not built yet. We would rather tell you the second part than have you find it.
Every studio is separated in the database itself
The usual way to keep one customer’s data away from another’s is to be careful in the application code. We do that too, but it is not all we rely on. Every table in our database carries row-level security — a rule enforced by the database, underneath the app, that limits what you can read and change to the studio you belong to.
That rule covers much of what the app reads and writes for you. Many actions, and all the work that runs without a signed-in person — sending an email, taking a payment, the nightly jobs — use a privileged connection the rule does not apply to. There, the check that keeps each studio to its own data is written into our own code.
StudioSide staff can open a studio’s account to help with support.
Encryption
- Everything travels over HTTPS. There is no unencrypted path into StudioSide.
- Data is encrypted at rest on disk, including backups.
- Passwords are stored hashed and salted. Nobody at StudioSide can read yours, including us.
- Google Calendar refresh tokens are encrypted with their own key before they are written down, so a database copy alone does not open your calendar.
A password on its own is not enough, if you say so
Every account can turn on two-factor sign-in: as well as your password, you enter a six-digit code from an app on your phone. It is set up under Settings → Account, and you get recovery codes in case you lose the phone.
A studio owner can require it of everyone in the studio, so it is not left to each person to remember: anyone who has not set it up is sent to set it up when they open the app. If you sign in with Google, you already get whatever two-step verification your Google account uses.
Card details never touch our servers
Card numbers go from your client’s browser to Stripe directly. We never receive them, never store them, and never log them. What we keep is the amount, its status, Stripe’s reference and fees, and the type of payment — never any part of the card number.
There is a record of who changed what
Sessions, clients, invoices, payments, gear, rooms, shifts, and team roles write to an audit log as they change — what it was before, what it became, and when, and who did it when a signed-in person made the change directly. Some changes the app makes for you, such as changes to team roles, are recorded without a name. That history is kept for twelve months, and a nightly job removes anything older. Studios can’t open this history in the app yet.
What we send to other companies, and what they get
These are the outside services that help us run StudioSide. Each receives only what it needs to do its job. This is the whole list — the same one our privacy policy and data processing agreement show, because all three pages read from one file.
All studio data — sessions, clients, invoices, payments, team, and gear.
Everything the app sends or receives while you use it, plus standard server logs. Its page-view counter also runs inside the app and records the address of each page you open, which can include the ids and codes in that address.
Billing contact details, invoice amounts, the name of whoever is paying an invoice and who it is for. When a studio sets up card payments, the owner’s identity and bank details go to Stripe directly for its checks. Card numbers go straight to Stripe and never reach our servers.
The recipient’s name and email address, and whatever the message contains — an invoice, an invite, a session reminder.
For each session: the time, the client’s name and what the session is for, the room and studio address, the crew, song titles, the booked package, the session notes, the invoice number, and links back to the session, the client and the schedule in StudioSide. We only ever write into a calendar we created. We never read your events; we only look up your list of calendars to find ours, and your Google account’s email address to show which account is connected.
Your name and email address from Google when you choose to sign in with it. Google’s sign-in button loads on the sign-in page, so Google sees that visit.
The subject, message and outcome of a support message you sent us, when a StudioSide staffer turns that ticket into a general help-centre answer. A staffer reads and edits the draft before anything is published, and Google does not train its models on this.
Crash reports: what the app was doing when something broke, including the page address, and a sample of timings for pages and the requests they make, with their addresses. A report from your browser inside the app is tagged with your user id and email. We remove the email addresses and phone numbers we can recognise from the text of error reports.
For a signed-in user: your user id, email, studio name, and role. For every visitor: the address of each page opened, which can include the ids and codes in that address, and the buttons and links clicked, including the words on them. Session replays mask all text and form inputs.
The address or city you type when you set up or edit your studio, your device’s location if you tap “use my current location”, your studio’s location to draw its map, and your IP address. It is called from your browser, so it sees the request directly.
The address you type, sent through our server. If you use your current location and Mapbox isn’t set up or has no answer, your device’s coordinates, straight from your browser.
Visits to our public pages and the sign-in page. The sign-in page’s address can name the page you were heading to, including the id of a client or an invoice, or an invite code. The app’s own pages do not load it.
An encrypted notification — for example that a shift opened or a session was assigned to you — and the push address of your device.
We do not sell your data, and we do not share it with advertisers. We do not use your studio data to train AI models unless your studio’s owner turns that on in Settings, and anything we use is anonymized first.
What our own monitoring can see
Four tools help us see how StudioSide is used and fix what breaks. Each one is on the list above; this is what they can see.
- Crash reports (Sentry) say what the app was doing when something broke, and a sample of timings shows how fast pages and the requests they make run; both include the addresses involved. A report from inside the app carries your user id and email. We remove the email addresses and phone numbers we can recognise from the text of error reports.
- Product analytics (PostHog) records which pages are opened and which buttons and links are clicked, including the words on them and the page address. Its session replays mask every piece of text and every form field, so a replay shows the shape of a screen and not its contents.
- Our host (Vercel) counts page views, including inside the app. It records each page’s address, which can include the ids and codes in that address, but no names.
- Google Analytics counts visits to our public pages and the sign-in page. The app’s own pages do not load it.
Your data stays yours
A studio’s owners and managers can export its records — sessions, clients, invoices, payments, expenses, hours, gear, rooms, rates, and team — as spreadsheets, in one click, any time, without asking us. Uploaded files and photos, quotes, packages, portal requests, availability and time off, the check-in log, and the history of changes are not in the export yet. If you leave, your data stays so you can take the export with you or come back to it. An owner can close the account in Settings at any time. The studio disappears at once, and 30 days later its data is permanently deleted; signing in within those 30 days restores it. To delete everything at once, contact support.
Where it lives
StudioSide runs in the United States and your data is processed there.
What we don't have yet
StudioSide is a small, young company, and there are things larger vendors have that we do not. Saying so is the point of this page.
- We do not have a SOC 2 report. We are working toward a SOC 2 Type 2 report, and we will say so here on the day it exists, not before.
- We have not commissioned an independent penetration test.
- We do not offer a contractual uptime guarantee.
If your organisation needs any of these before it can buy, tell us — that is the signal that moves it up the list. Email hello@studioside.app.
Found a vulnerability?
Please tell us at hello@studioside.app. We will acknowledge within three working days and keep you posted until it is closed. We will not take legal action against anyone who reports a problem in good faith, gives us a reasonable chance to fix it, and does not access, change, or delete other people’s data while looking.
Machine-readable version: /.well-known/security.txt.
Questions
Anything not answered here, email hello@studioside.app. See also our privacy policy, terms, and data processing agreement.