Folkbase is in early-access beta. See Terms of Service for more information.
Folkbase records one extra thing about your account during the early-access beta. The first time you sign in while it is open, your Google account ID and the date are written to Cloudflare’s key-value storage. It exists only so the promise that beta users keep the paid features free can be honored later. It holds nothing else, it is never changed after it is written, and no new records are created once the beta window closes. Billing and payments explains it in full.
Where your data lives
Everything you put into Folkbase (contacts, notes, touchpoints, tasks, lists, and trackers) is written to a Google Sheet called Folkbase - [Your Name] in your own Google Drive. There is no Folkbase database and no company server storing your contacts. The app reads and writes to your Folkbase-connected sheet in a personal workspace mode. Shared workspaces will add another sheet, owned by whoever created the workspace (see Sharing and workspaces).
Because it’s a normal Google Sheet in your Drive, you can open it directly, make a copy, or delete it whenever you like. Deleting the sheet will delete your data. It is recommended you do not touch the Sheet while using it with Folkbase, as it may affect app usage.
To keep Folkbase fast, the app will cache a copy of your data in your own browser (IndexedDB and localStorage) on your device. This cache never leaves your machine, and is not sent anywhere. Between visits, the browser also remembers your basic sign-in identity so the app can pick up where you left off. Your Google access token itself is held only in memory, and is never written to disk. On a shared computer, clearing your browser’s site data for folkbase.pages.dev removes all of it.
For the contacts and records you enter, you decide what to collect and why. In data-protection terms: you control the information, and Folkbase simply provides the tool that reads and writes to your own Google Sheet. The only data Folkbase itself centrally holds is the small set described below: an early-access email (if you submit one); any contact-form message or bug report that you choose to send; a minimal billing record, if you pay for a plan; and, during the beta, a note that your account signed in while the beta was open (see Billing and payments). We treat that data as our own responsibility, and explain your rights over it in Your rights and requests.
What Folkbase can access
Folkbase asks for the narrowest Google permissions it can. It should not request broad access to your Google Sheets or to your Drive as a whole, unless Google demands otherwise (and it is out of Folkbase’s control).
- Your basic profile (
userinfo.email,userinfo.profile): name, email, and profile picture. This is so the app knows who you are, and no password is needed, created, or stored. - Google Drive file-level access (
drive.file): this scope lets an app see only the files it creates or that you explicitly open with it. Folkbase uses it to create and read the Folkbase - [Your Name] sheet it makes for you, plus any file you deliberately choose. It cannot see anything else in your Drive. Both loading and saving your data happen through one specific file. - Google Apps Script (
script.projects,script.deployments): requested only if you create a shared workspace as a separate approval during the workspace setup. It lets Folkbase set up a small script in the workspace creator’s own Google account. It reads and saves that workspace’s sheet and goes through the script, which is Folkbase checking the workspace membership before serving data. Folkbase keeps the script up to date as the app improves, and it only ever talks to that workspace’s sheet. Your personal workspace never uses these permissions. Personal reads and saves go straight from your browser to Google’s Sheets API using the file-level Drive permission(s) noted above. - Google Calendar (
calendar.events.owned): optional and approved as a separate step. Further described below.
Calendar
Folkbase requests Google Calendar access only if you turn on calendar features, which you approve as a separate step. The access is read and write (the calendar.events.owned scope), so Folkbase can both pull in past meetings you choose to import and add events to your calendar: for example, sending calendar invites for an event you create in Folkbase. The .owned part matters: it covers calendars you own, not calendars that other people have merely shared with you. Folkbase only touches events you ask it to, and it marks the ones it creates with a machine-readable tag so the app can recognize its own events later. The tag is not a label you’ll see in Google Calendar. You can revoke this access at any time from your Google Account.
Folkbase never emails your attendees behind your back. Sending a calendar invitation is always something you ask for, and the app tells you exactly who will be emailed before it sends anything. When an invitation does go out, Google sends it from your own account, the same as if you had added a guest in Google Calendar yourself. Folkbase does not send email and has no mail server of its own.
Editing an event in Folkbase is deliberately quiet. Saving a change updates the title, time, place, and description on your Google Calendar, and it stops there: nobody is emailed, and the guest list is left exactly as it was. That second part matters because adding someone as a guest can make an event appear on their calendar even when no email is sent, so Folkbase only ever changes who is invited when you explicitly ask it to send invitations. Deleting an event removes it from your Google Calendar without notifying anyone.
How we use Google data (Limited Use)
Folkbase’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We use Google user data only to provide and improve Folkbase’s features for you. We do not sell it, we do not transfer it to third parties (except as needed to operate the app for you), and we never use it for advertising or to build profiles for purposes unrelated to using Folkbase.
Billing and payments
If you upgrade to a paid plan, payment is handled by Stripe, Folkbase’s payment processor. Your card details go directly to Stripe, never seen or stored by Folkbase. Stripe also handles receipts and, as a payment processor, keeps the billing records it is legally required to keep. As of early-access beta, there is no payment option.
To know which account has paid, Folkbase keeps a small billing record of its own: a link between your Google account ID and your Stripe customer ID, plus your plan status. That record lives in Cloudflare’s key-value storage (the infrastructure that hosts Folkbase) and contains no contacts, sheet data, or card details. It is covered by the same access-and-deletion rights described in Your rights and requests.
Folkbase has also promised that people who use it during the early-access beta keep the paid features free, permanently (see Pricing). Keeping that promise means knowing which accounts were here, so the first time you sign in during the beta, Folkbase writes one line to the same Cloudflare key-value storage: your Google account ID and the date, and nothing else. No email address, no name, no contacts, no sheet data. It is written once and never updated, and no new lines are recorded after the beta window closes. It is covered by the same access-and-deletion rights as the billing record, with one honest caveat: asking us to delete it also removes the proof of your permanent free access.
Early-access requests and contact messages
If you submit your email address through the early-access form on the Folkbase website, we store that email solely to contact you regarding a Folkbase invitation and any necessary beta updates. This is the same for responses sent through the contact form: your name, email, and message are stored only so we can read and answer them. Submissions don’t go to a company database or a third-party server: they land in a private Google Sheet controlled by Folkbase’s operator (delivered there by a lightweight Google Apps Script collector). They are kept until you ask us to delete it. There is no fixed retention period during the beta. Your data isn’t sold, shared, or used for advertising. You can ask us to delete it any time by emailing ElliottZelenak@gmail.com.
Beta bug reports
If you send a bug report, the message you write is sent to the project owner so the issue can be reproduced, along with the page you were on, basic browser information, the app version, the email address of the account you’re signed in with for follow-up (shown in the form before you send), and the name of your active workspace if you’re in one. Bug reports do not include your contacts or the contents of your sheet. Similar to submitting contact messages to Folkbase, bug reports are stored in a private Google Sheet controlled by Folkbase’s operator (via a small Apps Script collector), not in a server database, and are kept until you ask us to delete them.
Analytics and error reporting
On the public marketing pages (like this one, the homepage, and the help pages), Folkbase uses Umami, a privacy-focused analytics service, to count page views. Umami is cookieless, does not fingerprint or follow you across other sites, and shows us only aggregate numbers: which pages are visited, roughly where from, and on what kind of device. It is never loaded inside the signed-in app. Once you’re using Folkbase, nothing on our end tracks your activity, and no analytics service ever sees your contacts or Sheet data.
The beta build does not send automated error or crash reports. There is no error-reporting service wired into the version you use. If that ever changes, only technical diagnostics will be sent (such as a stack trace and the page where an error occurred), never your contact data. Should there be any changes to this, we would update this page first, likely attached to a new message on the Updates page.
Hosting and infrastructure
As of early-access beta, the Folkbase site and app are served by Cloudflare Pages. Like any web host, Cloudflare sees standard request metadata (such as your IP address and browser type) when it delivers pages to you. Your Folkbase data does not pass through it, as the app talks to Google’s APIs directly from your browser. Cloudflare also stores the small billing record described in Billing and payments. Pages load their fonts from Google Fonts, which likewise sees a standard font request from your browser.
Taking your data with you
You’re never locked in. Use Data → Export inside the app for clean CSV files of your contacts, notes, touchpoints, and tasks, or simply open the underlying Google Sheet. To remove everything, delete that sheet from your Drive.
If you want to remove every trace of Folkbase, the full checklist is:
- Delete the Folkbase - [Your Name] sheet (and its Folkbase folder) from your Google Drive.
- If you created shared workspaces, delete their sheets too. Data you added to someone else’s workspace lives in their sheet. Remove it from inside the workspace or ask the owner (see Sharing and workspaces).
- Only if you created a shared workspace: a small Apps Script project was set up in your Google account during workspace creation. You can optionally remove it at script.google.com. If you only used a personal workspace, or joined someone else’s, there is no script project to delete.
- Revoke Folkbase’s access to your Google account at myaccount.google.com/connections.
- Any calendar events Folkbase created stay on your Google Calendar (they’re yours, not ours). Delete them there if you don’t want them.
- Clear your browser’s site data for folkbase.pages.dev to remove the local cache.
- If you submitted your email, sent a bug report or contact message, or paid for a plan, email ElliottZelenak@gmail.com to delete what we hold (see Your rights and requests).
Your rights and requests
Depending on where you live, privacy laws such as the GDPR and CCPA give you rights to access, correct, or delete personal data, and to know that it isn’t sold. Folkbase is built so most of this stays in your hands. How a request works depends on which kind of data it concerns:
- Your own contacts and records. These live entirely in the Folkbase - [Your Name] sheet in your Google Drive. Folkbase holds no copy. You can view, edit, or export everything from inside the app at any time. You can also delete it all by deleting that sheet. No request to us is needed.
- If you’re someone a Folkbase user added as a contact. Your details were entered by an individual user into their own private sheet, which we cannot see or search across users. The person who controls that information is the user who added you, so a request to access or delete it should go to them. Folkbase has no central database of contacts to search on your behalf, and we have no technical way or right to reach into a user’s private Drive.
- The data we do hold (early-access email, contact messages, bug reports, billing record, beta sign-in note). If you submitted your email for early access, wrote to us through the contact form, sent a bug report, paid for a plan, or signed in during the early-access beta (all described in Billing and payments), you may ask to show what we have or delete it. Email ElliottZelenak@gmail.com, and we’ll respond within 30 days. We never sell this data or use it for advertising. Stripe retains the billing records it must keep as a payment processor, under its own policy.
Legal bases (GDPR)
If you’re in the EU/EEA or UK, the GDPR asks us to name a legal basis for the small amount of data Folkbase itself processes:
- Early-access emails: consent. You typed your email into the form, and you can withdraw that consent at any time by asking us to delete it.
- Contact messages and bug reports: legitimate interest. You chose to send them, and our interest is limited to answering you and fixing the product.
- The billing record: performance of a contract. We can’t provide a paid plan without knowing which account paid.
- The beta sign-in note: performance of a contract. We promised beta users permanent free access to the paid features, and we can’t honor that without knowing which accounts were here.
Your own contacts and records aren’t on this list because Folkbase does not process them as a controller at all. This data lives in your Google account, and you decide what to collect and why (see Where your data lives).
Where data is processed
Folkbase’s operator and the services it relies on (currently: Google, Cloudflare, and Stripe) are based in the United States, so the small amount of data Folkbase holds (early-access emails, contact messages, bug reports, the billing record, and the beta sign-in note) is processed in the US. If you’re in the EU/EEA or UK, that counts as an international transfer: Google, Cloudflare, and Stripe each publish their own GDPR transfer commitments (such as participation in the EU-US Data Privacy Framework and standard contractual clauses) under their own terms. Your contacts and records live in your Google account under your own agreement with Google, wherever Google stores them for you.
Processors at a glance
The complete list of services that touch any data connected to Folkbase:
- Google: sign-in, the Sheets and Drive files that hold your data, optional Calendar access, and the fonts these pages load.
- Cloudflare: currently serves the site and app, and stores the minimal billing record and the beta sign-in note (see Billing and payments).
- Stripe: processes payments. Your card details go to Stripe directly and never touch Folkbase.
- Umami: cookieless page-view counts on the public marketing pages only, never inside the signed-in app.
How we announce changes
When this policy changes in substance, the “Last updated” date at the bottom of this page will be updated. For a change that would meaningfully expand what we collect or how we use it, this will be said so prominently on this page and (where we have a way to reach you) by email to the people affected before a substantive change takes effect. A cosmetic or wording-only change that alters no factual claim or substantive material in the app will not change the date.
You may also check the Updates tab for more information (and plainspeak text regarding policy changes). Any changes to the Updates tab will be signed by the corresponding and respective PGP keys.
Last updated: July 27, 2026