Privacy

What is stored

Everything here is something you typed or something computed from it. The application does not buy, import or infer data about you.

jobs

The applications you add: company, role, status, salary, notes and the job description.

job_status_history

Every status change on an application, so the pipeline can show how long each stage took.

events

Calendar entries you create — interviews, deadlines and reminders.

activity_log

Notes and activity you record against an application.

contacts

People you add: name, role, and whatever contact details you enter.

application_contacts

Which contacts are linked to which application.

resumes

CVs you write in the editor, including their content and their section structure.

resume_snapshots

Version snapshots of those CVs, so an earlier draft can be restored.

application_documents

Links between an application and the CV version sent with it.

user_preferences

Your settings, such as default currency.

user_profiles

Your professional profile, if you build one in Settings from your LinkedIn profile address: name, headline, summary, work history, education and whatever else that public page carries. Only the public page is read, only when you ask for it, and it is removable from the same screen.

analytics_cache

Computed results of your own analytics, stored so the charts do not recalculate on every visit.

demo_accounts

The identifiers of the public read-only demo accounts. It holds no data belonging to you.

Your email address and password are held by Supabase Auth, not in any of the tables above. Passwords are stored only as a bcrypt hash; this application never sees the password itself.

Where it is stored

In a Postgres database hosted by Supabase, together with the authentication service that holds your login. None of it is copied to any other service.

This page does not state a hosting region, because stating one that later turns out to be wrong would be worse than saying nothing.

Analytics and third parties

This site counts page views using Vercel Web Analytics. It records which pages are visited, and where visits came from in the broadest sense — it sets no cookies, assigns no identifier, and does not follow you between sites or between visits. That is why there is no cookie banner: there is nothing to consent to.

It is not linked to your account. Nothing you type, and no row belonging to you, is sent to it.

There is no advertising network, no session recorder, no cross-site tracking pixel, and no data broker. Vercel and Supabase — the two companies that host this application — receive nothing beyond what running it requires.

One further service is involved only when you add an application. Some job boards will not serve their postings to a server, so the address you paste is sent to Firecrawl, which fetches that public page and returns it to be read. They receive the posting’s web address and nothing else — not your account, not your CV, and nothing about your other applications. If you never add an application from a link, they are never contacted.

Building your profile in Settings works the same way, through a different company. Apify reads the public LinkedIn profile whose address you paste and returns what is on it. They receive that address and nothing else. Only the public page is read — the same page anyone not signed in to LinkedIn would see — and only when you press the button. If you never build a profile, they are never contacted.

AI is used in exactly three places, and nowhere else: tidying and summarising a job description, filling in a new application from a link you paste, and tailoring a CV when you press the button that says so. Each one sends only the text it is acting on — the posting, or the CV you are editing — to a language model, and every one of them is something you start. Nothing is sent in the background, your applications are never sent as a set, and no model is asked anything on a screen you are only reading. Where a model proposes a value, it is checked against the source text before it is shown, and anything it made up is dropped and reported rather than saved.

Who can read it

You, and no other user. Row-level security is enabled on every table listed above, and every policy scopes rows to the signed-in user id — so a request for someone else's row returns nothing rather than being filtered out afterwards by the interface. The rule is enforced by the database, which means it holds even if a bug in this application asks for the wrong thing.

The demo pages are the one exception, and they contain no real data: every figure there is invented, and the demo accounts are read-only.

The people who operate the Supabase project can read the database, as is true of any hosted application. This project is open source, so the policies making those claims can be read rather than taken on trust.

Deleting your account

There is a delete control in Settings. It calls a database function named delete_own_account, which removes your authentication record; every table above is keyed to it and cascades, so your rows go with it.

It is immediate and it cannot be undone. There is no grace period and no archived copy kept on purpose — backups taken before the deletion expire on their own schedule.