What FUUEL collects today, written in plain language.
A short, current-state description of the data this site actually handles — an anonymous per-page beacon, a waitlist email, and contact-form messages — how it is used, where it lives, and how to ask for it back.
What we collect
Three surfaces, listed in full.
Each surface below lists every field actually stored. Nothing extra, nothing inferred, nothing collected silently in the background.
Visitor beacon
The only client-side state this site keeps.
On your first page load, the browser mints a random UUID and stores it under localStorage["polsia_vid"]. Every subsequent load reads that same value and fires one GET /api/beacon/pixel request, capped at a single 1×1 image pixel. No other storage — no cookies, no IndexedDB, no Service Worker state.
What is stored
- One anonymous identifier — a random UUID — under
polsia_vid. - That’s it. The identifier carries no name, email, IP, or fingerprint.
What is NOT done with it
- Not joined to your name or email — they are written to different surfaces.
- Not shared with any third party.
- Not used to identify a real person; it stays an aggregate counter.
Reset
Clear your browser's localStorage for this origin and the next page load mints a fresh UUID. There is no server-side list of visitors keyed to any identifier.
Waitlist submissions
What happens when you join the waitlist.
Two fields — your email address (required) and your name (optional) — submitted through POST /api/waitlist. The row is keyed by timestamp and the email is unique — repeating the same email is a no-op that returns 409 and writes nothing new.
What is stored
- Email address — required; the address you signed up with.
- Name — optional; blank unless you filled it in.
- Submission timestamp — when the row was created.
What is NOT done with it
- The email is not sold, rented, or shared with any third party.
- The waitlist is not added to a general marketing list or newsletter.
- It is not used for retargeting, ad audiences, or product recommendations.
Removal
Write to fuuel@polsia.app and the row is removed by hand. There is no self-serve account portal or settings link — removal is operator-driven.
Contact-form submissions
What happens when you send a message through the contact form.
Three fields — name, email, message — submitted through POST /api/contact. All three are required.
What is stored
- Name — required; used to address the reply.
- Email address — required; used to reply.
- Message body — required; the message itself.
- Submission timestamp — when the row was created.
Where it goes
The submission is stored in a Postgres database row keyed by timestamp and is also delivered, best-effort, to fuuel@polsia.app. The delivery goes through the Polsia email proxy so the operator can reply from the inbox.
What is NOT done with it
- It is not exported, not shared with third parties, not added to any other list.
- It is not used for marketing or retargeting.
Removal
Held long enough to reply and to support a follow-up thread. Write to fuuel@polsia.app and the row is removed by hand.
How we use it
One purpose per surface, nothing else.
The same shape as the per-surface prose above, summed. Each surface has a single narrow use; no surface is reused for anything beyond its declared purpose.
How and where it’s stored
Two databases in one stack, one operator inbox in another.
Submissions live as Postgres rows, one table per surface, keyed by createdAt. Each successful POST also triggers a best-effort notification to the operator through the Polsia email proxy.
At rest
- Waitlist rows in
Lead(Postgres tablelead): id, email, name, createdAt. - Contact rows in
ContactMessage: id, name, email, message, createdAt. - Database URL is injected at deploy time with sslmode=require; transport is TLS.
Notifications
- Waitlist signup — operator receives a one-line note: the address and a UTC timestamp.
- Contact form — operator receives the name, email, and the message body.
- These notifications also count as data you have submitted — they live in the operator inbox in addition to the Postgres row, for as long as the inbox keeps them.
Transports
- This site is served over HTTPS — the deploy origin is TLS.
- Notifications are sent over HTTPS to the Polsia email proxy; replies follow the same path.
- The Postgres connection used by the app is configured for TLS at deploy time.
What we don’t do
Four lines that say plainly what is not happening.
If any of these change, this page is rewritten before the change ships.
Your choices
Ask for your row back, change the email, or clear the beacon.
There is no in-app settings panel today — no accounts, no preferences page. Removal and edits are handled by the operator on request.
Remove a waitlist entry
Write to fuuel@polsia.app from the address that signed up, ask for removal, and the row is deleted within a reasonable handling window.
Remove a contact-form submission
Write to fuuel@polsia.app, reference the message, and ask for it to be removed. The row is deleted; previously delivered operator-inbox copies are purged on the same request.
Reset the beacon
Clear localStorage for this origin and the next page load mints a fresh UUID. The beacon carries no personal data, so there is nothing server-side to remove.
A question about this page.
If any line above reads wrong, write to fuuel@polsia.app — corrections land here, and the page is updated.
Effective date. This page applies from the date it was published and until it is updated.
Updates. As the product moves from waitlist to live Subscribe, this page is updated to describe what is then collectible, how billing data is handled, and where the new surfaces route data. The most recent change is reflected in the language above, not in a dated changelog — read the whole page.