How Folkbase works.

The short version

Most CRMs work like this: you type a contact's name, it travels to the company's servers, and it lives in their database. From then on, you reach your own data through them.

Folkbase inverts that. It is a static web app — plain files served from a CDN — with no backend and no database of ours. When you set up, the app creates a Google Spreadsheet in your own Drive (or you pick one), and every contact, note, touchpoint, event, task, and list is a row in a tab of that spreadsheet. The app reads and writes those rows through Google's APIs, authorized by you, scoped to that one file. Your browser talks to Google; we're not in the middle.

What that buys you: you can leave at any time and lose nothing, because your data is already in a normal spreadsheet you can open, sort, export, or script against. And there is nothing for us to leak — a breach of Folkbase's hosting exposes static JavaScript files, not your contacts.

Your spreadsheet is the database

Each kind of record is a tab in your sheet: Contacts, Notes, Touchpoints, Events, Tasks, Lists, and so on. Relationships between records are junction tabs — for example, linking a note to a contact just appends a row of [Note ID, Contact 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 underneath it.

"A spreadsheet over the network" sounds slow, so the app keeps a short-lived cache in your browser's IndexedDB — roughly two minutes for fast-changing data like contacts and notes, longer for slow-changing data like lists. The cache lives on your device only and updates optimistically after each successful write. That's why the app feels immediate even though the source of truth is a Google Sheet.

Because the sheet is a normal Drive file, everything Drive already gives you applies: revision history, backups, sharing controls, and the right to open the raw data whenever you like.

Sign-in and permissions

Sign-in is standard Google OAuth 2.0. The permission scopes tell the real story of what an app can do, so here is the complete list Folkbase can ever ask for:

• Basic profile (userinfo.email, userinfo.profile) — your name, email, and picture, so the app knows who's signed in. No password is created or stored.
• File-level Drive access (drive.file) — the important one. This scope lets an app touch only the files it created or that you explicitly opened with it. Folkbase deliberately does not request the broad Sheets or Drive scopes, so it cannot see the rest of your Drive — just the sheet it makes for you, plus any file you hand it through the Google file picker.
• Calendar (calendar.events) — optional, and requested in a separate consent step only if you turn on calendar features.
• Apps Script (script.projects, script.deployments) — requested in a separate consent step only when you create a shared workspace; see Workspaces below. Personal use never asks for these.

The pattern is incremental consent: you're asked for a permission at the moment you use the feature that needs it, never as an up-front bundle.

Where your access token lives

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

The visible cost of that choice is deliberate: when you reload the page there is no saved token to restore, so the app shows a one-click Reconnect screen instead of silently holding long-lived credentials. Tokens expire on their own within about an hour regardless.

The honest limit: 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 — that is true of every web app, and closing it would require a server-side token broker, which would reintroduce exactly the middleman Folkbase exists to avoid.

Personal mode: browser to Google, directly

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. No proxy, no relay, nothing deployed anywhere. Loading your contacts is your browser asking Google for rows; saving a note is your browser appending one.

Workspaces: a server that runs in your account

Shared workspaces need something personal mode doesn't: enforcement. 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, because anyone can bypass their own browser. Somewhere, a server has to check permissions before touching the data.

Folkbase's answer is unusual: when you create a workspace, the app deploys a small Google Apps Script web app into your own Google account — Google's serverless runtime, running as you, the sheet's owner. Every workspace read and write goes through that script, which checks membership and note visibility before it touches the sheet. The point is that this "server" is also not ours: 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, because that would skip the membership checks.

As Folkbase improves, the app keeps that script current through a versioned self-update: when the owner signs in and a newer version exists, the app uploads the new source to their own deployment. Nothing about this gives us access — the update travels through the owner's session, like everything else.

What Folkbase's servers actually see

The complete inventory of infrastructure we operate:

• Static hosting (Cloudflare Pages) — serves the app's files. Standard web-hosting logs; no contact data, 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; your CRM data is nowhere near any of it.
• Feedback — early-access requests, contact-form messages, and bug reports you explicitly submit.

That's the whole list. 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 architecture is a trade, and this one is no exception. 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 Google's: if Sheets is down, Folkbase is down. And 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, which was the thing to avoid in the first place.

If any of this raises a question we haven't answered, write to us — the contact page goes to a human, and the Privacy Policy covers the same ground in plain language.