Security

Last updated 18 September 2026 · SFProto is a product of Cloud Mavericks Pty Ltd · ABN 92 628 083 974 · ACN 628 083 974, Melbourne, Victoria, Australia

Plain English: your work is stored in the United States by Supabase and served by Vercel, protected by row-level security so only your account can read it. Two people at Cloud Mavericks can reach the database, and only to help you, investigate abuse or answer the law. Our AI provider does not train on your requests. We have no SOC 2, no Australian region and no SSO yet, and we say so.

Where your work is kept

Your account, projects, pages, conversations, share links and uploaded wireframes are stored by Supabase in its US East region (United States): the database, file storage and sign-in.
Our server functions run on Vercel in Washington, D.C. (United States). Nothing is stored there beyond ordinary request logs.
There is no Australian or European region yet. If your organisation needs one, tell us; it is on the list below of what does not exist yet.

Who else touches it

Supabase: database, file storage and sign-in codes.
Vercel: hosting, server functions and cookieless page-view analytics.
Google (Gemini API): builds and changes prototypes and drafts process flows from what you type and the wireframes you attach.
Resend: sends sign-in codes, share invitations, access-request confirmations and our own notifications.
Stripe: payments, once billing opens. Stripe holds card details; we never see them.
The Privacy Policy lists the same providers and is updated before anyone is added.

What the AI provider keeps

Requests go to Google’s Gemini API on a paid tier. Under Google’s terms for that tier, your requests and pages are not used to train or improve Google’s models.
Google keeps limited logs for abuse monitoring under its own terms. That is the only copy of a request outside SFProto, and it is Google’s to keep for its stated period.
Wireframes are uploaded to Gemini’s file service for one request and deleted by us as soon as the reply arrives.
We never use your work to train anything, and we run no model of our own.

In transit and at rest

Every page, API call and email link is served over HTTPS (TLS). There is no unencrypted path into SFProto.
Supabase encrypts the database and file storage at rest, and Vercel encrypts its logs; both publish their own security documentation.
Secrets (API keys, the service role) live only in server environment variables and never reach the browser.

Who can see your work, and when

Every table carries row-level security: a signed-in person can read and change only rows their own account owns. Shared pages are read through a separate path that checks the link’s settings first.
The server’s administrative key is used only by our own server functions, for things a person’s own session cannot do: sending a share code, saving an access request, checking the service-wide AI ceiling.
Two people at Cloud Mavericks are Super Admins of SFProto. The admin console shows them account email addresses, who has signed in, AI usage counts and the feedback you send. It does not show them your prototypes, conversations or uploads.
The same two people can reach the database directly through the Supabase dashboard. They do so only to help you when you ask, to investigate an abuse report or a security incident, or when the law requires it; never to look through customer work, and never for consulting work. The Terms of Service say the same in their confidentiality clause.
Nobody else at Cloud Mavericks, including its consulting staff, has any access to SFProto’s database, storage or admin console.

Sign-in

There are no passwords. You sign in with a 6-digit code emailed to you, which Supabase issues, rate limits and expires; only invited addresses can request one while SFProto is invite-only.
Sign-in codes and the session cookie are handled by Supabase Auth; we never see a code.
There is no multi-factor sign-in beyond the emailed code, and no single sign-on. Both are on the list of what does not exist yet.

Keeping the service safe and available

AI use is limited per account by month and by hour, and the whole service has a daily spending ceiling with a kill switch, so one account or one bad day cannot take SFProto down.
The Request access form, share-code requests and feedback are rate limited by address and by connection; the connection is kept only as a salted hash.
Uploaded wireframes are private to the account that uploaded them and are checked to be that account’s own files before the AI sees them.

Export and deletion

Account → Download my data gives you everything in your account as one JSON file, at any time.
Account → Delete my account removes your projects, pages, conversations, uploads, share links, feedback and AI usage rows from our live systems straight away. Backup copies roll off within 30 days and are never restored for ordinary use.

Reporting a vulnerability or an incident

Email support@sfproto.com. Tell us what you found and how to reproduce it, and give us reasonable time to fix it before telling anyone else. We will reply within two business days (Melbourne time) and tell you what we did.
If we learn of an incident that affects your account or your work, we will email the address on your account with what happened, what was affected and what we did about it.
Do not test SFProto’s security without our written permission; the Acceptable Use Policy explains why.

Agreements

A data processing agreement is available on request for organisations that need one; email support@sfproto.com.
The Terms of Service carry a confidentiality clause covering everything you put into SFProto.

What does not exist yet

No SOC 2, ISO 27001 or other third-party audit report, and no independent penetration test report yet.
No Australian or European data region: everything is in the United States.
No single sign-on (SAML or OIDC) and no multi-factor sign-in beyond the emailed code.
No customer-facing audit log of who opened what.
We will update this page when any of these changes, and we would rather say so here than let you assume otherwise.