How Folkbase works.

The short version

Most CRMs work like this: once you enter a contact’s name and details, they pass through that company’s server into its database, and from then on you reach your own data only through their program.

Folkbase inverts how traditional CRMs work. Folkbase is a web app with no backend and no database of our own. When you set up your account, the app creates a Google Spreadsheet in your Drive (or one you pick), and every contact, note, touchpoint, event, task, and list is auto-entered as a row in a tab of that spreadsheet. The app reads and writes those rows through Google’s API (authorized by you), scoped to that one file. Your browser talks to Google itself, not through Folkbase.

Because of this, you can leave Folkbase at any time and lose nothing. Your data is already in a normal spreadsheet you can open, sort, export, or script against.

There is nothing for us to leak. A breach of Folkbase’s hosting exposes static JavaScript files, not your contacts or their information.

Your spreadsheet is your database

Each record type is a tab in your sheet: Contacts, Notes, Touchpoints, Events, Tasks, Lists, and so on. Relationships between records are simply junction tabs. For example, linking a note to a contact just appends a row of [Contact ID, Note ID, Linked Date] to a Contact Notes tab. Rows carry stable IDs, and the app re-checks a row’s position right before writing, so an edit never lands on the wrong row even if the sheet was reordered.

Since “a spreadsheet over the network” sounds slow, the app keeps a short-lived cache in your browser’s IndexedDB, roughly two minutes for fast-changing data (like contacts and notes), with longer times for slow-changing data like lists. The cache lives only on your device, updating after each successful write.

Because the Google Sheet is a normal Google Drive file, everything Drive and Sheets give you applies: your revision history, any backups, other-user sharing controls, and the right to open your raw data whenever you like.

Sign-in and permissions

Sign-in is standard using Google OAuth 2.0 and its permission scopes. Below is the complete list Folkbase can ever ask for:

1. 1

   Continue with Google

   You sign in through Google’s own popup. Folkbase does not see, store, or require a password: there is never one to create.

2. 2

   Grant just what you need

   Google shows you exactly what you agree to: name, email, and access to one spreadsheet Folkbase creates in your Drive (drive.file). Not to your entire Drive, just what you create.

3. 3

   You’re in

   Your access token is held in memory only, never written to disk. Reload the page and reconnect easily through Google OAuth. See below for more details.

4. +

   More access, only when you need it

   Turning on Calendar or creating a shared workspace will ask for its own permissions in a separate popup. This feature turns on only when you choose to use them, and are never bundled into your sign-in. If you skip the feature, you can still use Folkbase’s other features, and you will never be asked for these permissions.

• Basic profile (userinfo.email, userinfo.profile): your name, email, and picture, just so the app knows who’s signed in. No Folkbase password is created or stored.
• File-level Drive access (drive.file): This scope lets an app touch only the files it creates, or that you explicitly open with it. Folkbase deliberately does not request the broad Sheets or Drive scopes. It cannot see the rest of your Drive, just the sheet it makes for you, as well as any file you hand it yourself through the Google file picker (how that works).
• Apps Script (script.projects, script.deployments): requested in a separate consent step only when you create a shared workspace (see Workspaces below). Personal use will never ask for these.
• Calendar (calendar.events.owned): an optional scope, requested in a separate consent step only if you choose to turn on calendar features. It covers calendars you own, not ones other people have shared with you.

Connecting a sheet you already own

drive.file reaches only the files Folkbase itself created. That is the point of it, and it creates one problem: a spreadsheet you already own is invisible to Folkbase, which cannot list your Drive or go find it for you.

Most apps solve this by asking for the wide permission instead, letting them see every spreadsheet you have, and then drawing you a list to choose from. Folkbase refuses that scope, so something else has to do the finding.

That something is Google’s own file picker. When you click Choose from Drive, the window listing your spreadsheets is served and drawn by Google, inside a frame this app cannot read into. Google can show you that list because Google already knows what is in your Drive. Folkbase still does not. You pick one file, and the only thing that crosses back into Folkbase’s code is that file’s ID, one short string. Not its contents, and nothing about the files sitting beside it. Google then extends the permission to cover that single file, because you clicked it.

You meet this in three places: connecting an existing sheet during setup, joining a shared workspace, and importing rows from a spreadsheet into a tracker.

Joining a workspace takes two grants, not one. The owner sharing the file grants you, the person, the same as sharing any document. Picking it in the picker grants the app. Both are needed, which is why the join flow ends by asking you to pick the sheet that was just shared with you.

What this bounds is what Folkbase can reach, not what a compromised browser could do with what you have already connected. Widening the permission is the part that stays out of reach: there is no path to it that does not route through a consent screen served by Google, on Google’s own domain, that you have to click. More on that limit below.

Where your access token lives

When you sign in, Google issues a short-lived access token, only as the credential the app uses to call Google’s APIs. Folkbase holds that token only in memory; it is never written to localStorage, cookies, or disk. A storage-scraping browser extension, or an attack that snapshots your browser’s stored data, finds nothing to steal.

When you reload the page there is no saved token to restore, so the app will show a one-click Reconnect screen over silently holding long-lived credentials. Tokens expire on their own regardless.

A limit found in every web app: in-memory custody defeats the common “read the browser’s storage” attack class, not a fully compromised browser. A malicious extension injecting scripts into a running page could still act as you. Closing that gap would require a server-side token broker, reintroducing the exact middleman Folkbase exists to avoid.

Personal mode: Direct browser-to-Google

For a personal workspace, the pipeline is as short as it can be: your browser calls the Google Sheets API directly, authorized by your own drive.file token, against your own spreadsheet. There is no proxy and no relay, and nothing deployed anywhere. Loading your contacts is your browser asking Google for rows (and, for example, saving a note is your browser appending one).

Workspaces: Server that runs in your Google account

Shared workspaces need enforcement, something personal mode doesn’t require. If five people share one sheet, rules like “private notes stay private” and “members can’t change roles” cannot be enforced by client-side JavaScript, which anyone can bypass in their own browser. A server has to check permissions before touching the data.

Folkbase is different, in that when you create a workspace, the app deploys a small Google Apps Script web app into your own Google account. Google’s serverless runtime runs as you, the sheet’s owner. Every workspace read and write goes through that script, checking membership and note visibility before it ever touches the sheet. The point is that even this “server” is not on Folkbase: it runs in the workspace owner’s account, its code is open in the owner’s Apps Script editor for anyone who wants to read it, and it only ever talks to that workspace’s sheet. Workspace operations never fall back to direct spreadsheet calls, as that would skip the membership checks.

As Folkbase improves, the app keeps that script current through a versioned self-update seen within the app: when the owner signs in and a newer version exists, Folkbase uploads the new source to their own deployment. This does not give us access, as the update travels through the owner’s session, like everything else.

What Folkbase’s servers actually see

The complete infrastructure Folkbase operates on:

• Static hosting (Cloudflare Pages): serves the app’s files. Standard web-hosting logs, with no contact data in them, because your data never transits our origin.
• Billing (Cloudflare + Stripe, paid workspace plans only): stores who has an active subscription. Payment details live with Stripe, and your CRM data is nowhere near any of this.
• Feedback: early-access requests, contact-form messages, and bug reports you directly submit.
• Beta cohort (Cloudflare): one line recording that your Google account signed in while the early-access beta was open, written the first time you sign in and never updated afterward. It exists so the promise on Pricing, that beta users keep the paid features free, can actually be honored later. It holds an account ID and a date. No email, no name, nothing from your sheet.

There is no analytics pipeline sitting on your contact data, because there is no path through which your contact data reaches us.

The trade-offs

Every web architecture is a trade. Google Sheets is not a real database: there are no server-side queries or joins, so the app fetches tabs and does the relational work in your browser (softened by caching). That is comfortably fast at personal-CRM scale (thousands of rows) and it would be the wrong design for millions.

Availability is based on Google: if Sheets is down, Folkbase is down. The workspace pattern of deploying code into your own account is uncommon, but it is the only way we know to get server-side permission checks without operating a server that holds everyone’s data, the exact thing this design exists to avoid.

If there are any other questions you want answered, please contact me. The contact page goes to a human, and the Privacy Policy covers the same ground in plain language.