Dritto ("we", "us") is a job-search tool that curates roles, scores your fit, and helps you tailor applications. This policy explains what we collect, why, and the choices you have. We designed Dritto to hold your career data carefully — telling you the truth about your odds is the whole product, and that only works if you trust us with the inputs.
Information we collect
- Account. Your email address, used for passwordless sign-in.
- Career profile. Your résumé, work history, skills, education, target roles, and the preferences that drive your filters (comp floor, seniority, locations, tools you won't use, companies to avoid).
- Experience bank. The accomplishment bullets you write or that we extract from your résumé and interviews — the source of truth we tailor from.
- Applications & outcomes. The roles you save, the packages you generate, your pipeline stages, and interview rounds you log.
- LinkedIn connections (optional). If you upload your own LinkedIn connections export, we store the names, employers, and titles it contains to surface warm intros. This is your data export; it includes information about third parties in your network.
- Gmail (optional). If you connect Gmail, we request read-only access to detect application status updates. We store an access token securely and read only what's needed to surface pipeline changes; you can disconnect at any time.
- Usage & technical. Basic logs needed to operate and secure the service.
- Product analytics. This feature is disclosed here before it is switched on, and it operates only once we deliberately enable it — a step held behind checks we set for ourselves about deletion and retention, and one we take separately from publishing this policy. Publishing this policy does not enable it, and neither does your acknowledging it. When enabled, we record a fixed list of fourteen events, each one noting that something happened and never what it contained: your account became active; you confirmed your preferences; you requested results; results came back; results were useful for the first time; you opened, saved or dismissed a role; an ATS score was queued, became ready, failed, or was superseded by a newer one before it finished; you started an application; you marked one submitted. Each carries counts, durations, true/false flags and fixed categories: how many target titles you set, how long a search took, how many rows came back, an ATS fit number, which plan you are on. No free text of any kind — no résumé or bullet content, no job titles, descriptions or URLs, no company names, no search queries, no preference text, no model prompts or responses, and no email address.
- The two references inside those events, and how they differ. Where an event has to point at something we send a one-way keyed digest rather than the thing itself, and the two are not equivalent. The posting reference is computed from the job's address alone, so it is the same value for everyone who sees that posting — which is what lets us ask whether a role is widely opened and rarely applied to, and which also means PostHog could tell that two accounts looked at the same posting without being able to tell which posting it is. The generation reference includes your account, so it is yours alone and not comparable with anyone else's. Neither can be turned back into a URL, a company or any text.
- Terms & Privacy acceptance. The record of which versions of these documents you agreed to and when: your account id, the two version dates, and a timestamp. No content. We keep it while your account exists and delete it with your account.
- Waitlist details, before you have an account. Your first name, last name and email address when you join the waitlist. If you choose to answer the optional questions about your job search, we also store what you selected from fixed lists: where you are in your search, your career stage, the role families you are targeting, your timing, and the challenges you picked. They are multiple-choice only — there is no free-text box — and answering them is optional, so skipping them does not affect your place in line. When signup-source attribution is enabled, if a waitlist submission arrives through an approved source-specific link or code, such as our permanent Postcard link, and your entry does not already have a source, we store that source and the time it was recorded. That can be when your entry is first created, or on a later waitlist submission using that address. Once a source is recorded, a later link or code does not replace it. We do not infer a source from earlier activity, we do not attach scan details to your waitlist entry, and we never add a source to an existing entry except from a waitlist submission using that address. The source identifies the approved link or code presented with that submission; it does not confirm that you attended an event.
How we use your information
- To source and gate roles against your preferences, and to explain each decision with the exact line from the posting.
- To estimate your ATS fit and to generate tailored résumés, cover letters, and interview prep — always anchored to what you actually provided.
- To operate your tracker and, if connected, reflect email-derived status changes.
- To secure the service, prevent abuse, and improve the product.
- To understand how people actually move through Dritto — where the product loses people between signing up and a first useful result, whether receiving an ATS score changes what someone does next, and whether people come back — so that we fix what is broken rather than what we assume is broken.
- To tailor your first experience of Dritto, and to decide the order we send waitlist invitations, using the optional job-search answers you chose to give us before signing up.
- When signup-source attribution is enabled, to understand which approved links or codes are presented with waitlist submissions. If we later group these source records by an event name or date window, the grouping is an estimate based on when the source was recorded — not when the person first joined, and not confirmation that anyone attended an event.
AI processing
We use Anthropic's Claude models to extract, score, and generate. Your inputs are sent to Anthropic to produce these outputs. Dritto is built on an anti-fabrication rule — the models are instructed never to invent a tool, metric, or claim you didn't provide — but you are responsible for reviewing any generated document before you submit it.
Service providers (subprocessors)
We share data only as needed with the providers that run the service, and only what each one needs to do its job:
- Anthropic — AI processing. Receives the inputs needed to produce a given output, as described above.
- Supabase — database and authentication. Holds your account and career data, and sends your passwordless sign-in emails.
- Vercel — hosting. Serves the app and runs its server code.
- Apify — public job-listing sourcing. Receives the search parameters used to find postings, not your profile or your bullets. We also read listings directly from public job boards, which receive no information about you.
- Stripe — payments. If you subscribe or make a purchase, Stripe receives your email address and an account identifier, and you enter your payment details with Stripe directly. We never receive or store your card number. Stripe keeps its own record of any payment you make, under its own privacy policy and legal obligations, and deleting your Dritto account does not delete Stripe's record.
- Resend — email delivery. Receives the recipient address and message contents for the mail we send, such as waitlist invitations and the feedback you submit to us (sent with your address so we can reply). Your sign-in emails go through Supabase, not Resend.
- Sentry — error monitoring. Receives diagnostic reports when something fails: what broke, where, and the identifier of the account the failure happened to, so that one person hitting the same fault twelve times is distinguishable from twelve people hitting it once. Email addresses are masked and long values truncated before anything is sent, and IP addresses, cookies and request headers are not collected.
- PostHog — product analytics. We have created the dashboards that display this data, so PostHog holds those definitions; the events themselves are sent only while the feature is enabled, and no analytics event or account identifier is sent at any time when it is not. When enabled, it receives the fourteen events described above and, with each one, the identifier of your account — the same identifier our own database uses — so that one person doing something five times is distinguishable from five people doing it once. That identifier is persistent and it is personal data, and we would rather say so than call it anonymous. PostHog does not receive your email address, your name, your résumé or bullet content, any job or company you looked at, or anything you typed. We also switch off two things PostHog would otherwise do: your IP address is not sent, and location lookup from it is disabled. Analytics is off entirely in our development and preview environments, so only real production use is recorded.
- Google — only if you connect Gmail, and only for the read-only access described above.
We do not sell your personal information, and we do not use it for advertising.
How applications are sent
Dritto surfaces roles and helps you prepare, but you apply through each employer's own careers site (their real applicant-tracking system). We never submit applications on your behalf through aggregators.
Data retention
We keep your data while your account is active. You can delete your career data or your entire account, after which we remove it from active systems within a reasonable period, subject to backups and any legal obligations.
Something else outlives your account. If you redeem the beta discount, we keep a one-way fingerprint of your email address — a digest, not the address, and nothing else: no name, no account id, no date, no record of what you bought. It exists so that a one-per-person offer cannot be claimed twice by deleting an account and signing up again with the same address, and deleting your account does not remove it, because removing it would remove the only reason it exists. We are not going to call it anonymous: it is a lookup key for your address, so somebody holding a list of candidate addresses could test them against it. If you ask us to erase your data we delete it, and that removes the limit for you as well. No row exists for you unless you chose to redeem.
Payment notifications, if you start a beta-offer checkout. When you start or complete a beta-offer checkout, Stripe sends us notifications about it. For each one we keep Stripe's identifier for that notification, what kind of notification it was and whether we finished processing it, linked to your account, so that the same notification is never applied twice. We are not going to call it anonymous: Stripe's records can connect that identifier to your payment. These records are deleted when your account is deleted. If you ask us to erase your data while keeping your account, we delete them, and a later notification about the same checkout is not recorded again; if a payment or notification is still being processed when you ask, a member of our team completes the erasure by hand once it has settled, rather than anything doing it automatically. Error reports we create from this version on do not record these identifiers; we have not inspected older logs held by our hosting and error-monitoring providers, so we make no statement about what those contain. Stripe keeps its own records of your payment under its own policy, and deleting your data here does not delete Stripe's records. While your account exists, we have not set a period after which these records are deleted automatically. None exists for you unless you started a beta-offer checkout.
Waitlist entries are separate, and we want to be exact about it. Your waitlist row — name, email, and any optional answers you gave — is kept until you ask us to remove it. It is not tied to an account: joining Dritto does not remove it, and deleting your account does not remove it either. Email hello@drit.to from the address you signed up with and we will delete the entry, those answers, and any signup source recorded against it. The completion link we email you expires after 30 days.
Product analytics, specifically, while it is enabled. We have checked this project's PostHog setting and it currently reports events remaining queryable for about twelve months. We are deliberately not turning that into a promise that they are erased then: it is a query-window setting, it can change with our plan, and we would rather state what we verified than imply a deletion guarantee we have not obtained in writing. When you delete your account we stop sending any further analytics for you immediately, and we then ask PostHog to delete both your analytics profile and its events. That request is asynchronous on their side, so we treat the deletion as incomplete until PostHog confirms it rather than when we ask, and we keep a record that the request is outstanding until they do.
Your rights
There is no in-product opt-out for analytics, and we are not going to imply otherwise. While the feature is enabled, the fourteen events above are recorded for every signed-in account, and there is no switch in the product to turn them off for yourself. Account deletion removes them as described above. That is not the only thing available to you — the rights in the next paragraph, including access and objection where they apply to you, are exercised by emailing us, and we will act on them. If this trade-off is wrong for you, tell us; we would rather hear it than find out later.
Depending on where you live (e.g., GDPR in the EU/UK, CCPA/CPRA in California), you may have the right to access, export, correct, or delete your personal data, and to withdraw consent for optional features like Gmail. To exercise these, contact us at hello@drit.to. You can also export your data or delete your account at any time from your profile. If you are on the waitlist and have no account yet, there is no profile to use — email us and we will handle it.
Security
Data is encrypted in transit. Every user's records are isolated at the database level so one account cannot read another's. Sensitive credentials such as Gmail tokens are held server-side and never exposed to the browser. No system is perfectly secure, but we take reasonable measures appropriate to the sensitivity of career data.
About the connections you upload
If you upload your LinkedIn connections, you confirm it is your own official data export and that you use it only to reach people in your network appropriately. You are the controller of that network data; we process it on your behalf to show warm-intro paths.
Children
Dritto is for working-age adults and is not directed to anyone under 16.
International transfers
Our providers may process data in the United States and other countries. Where required, we rely on appropriate safeguards for those transfers.
Changes
We'll update this policy as the product evolves and note the date above. If we change how we handle your data, we'll tell you before the change takes effect. Corrections are different: if we find this page has understated what we already do — a provider we were using but hadn't named, for example — we publish the correction as soon as we have it, because leaving you with a description we know to be incomplete serves you worse than a few days' notice would. Nothing about how your data is handled changes in that case; what changes is that you can now see it. Either way, you'll be asked to review and accept the updated policy.
What changed in this version
This version, effective October 22, 2026 (revision 2), is a same-day revision of the policy published earlier on the same date. It changes one thing: the identifiers of payment notifications, kept if you start a beta-offer checkout, are now linked to your account and deleted when your account is deleted, you can ask for them to be erased while keeping your account, and our new error reports do not record them. That is a change in how we handle your data, which is why you are asked to acknowledge this version even if you acknowledged the earlier text today.
The version published earlier the same day added the beta-discount fingerprint, kept if you redeem the beta offer, and the payment-notification identifiers, and said that Stripe keeps its own record of any payment you make. Neither record is created for you unless you choose to redeem the offer or start a checkout.
An earlier version added the signup-source disclosure above. When signup-source attribution is enabled, a waitlist submission that arrives through an approved link or code — such as our permanent Postcard link — records that source and the time we recorded it, and only on an entry that does not already have one. Nothing we already hold is re-read or sent anywhere new, no existing entry gains a source except from a later waitlist submission using that address, and the form that can record one says so where you fill it in. That is prospective collection held behind an activation gate: this disclosure is published and verified before the feature is switched on, and this policy becoming effective is not what switches it on.
An earlier version added the product-analytics disclosure above — a fixed set of fourteen events shared with PostHog together with your account identifier whenever that feature is enabled. That was a change in how we handle your data rather than a correction of something we were already doing, which is why it was published in advance of the collection rather than after it.
The order these things happen in, because it is easy to misread. This policy is effective from October 22, 2026 (revision 2), and when this version publishes you are asked once to agree to the Terms and acknowledge this policy before continuing in the app. That acknowledgement is an acknowledgement, not a consent to analytics and not a consent to redeem or buy anything, and it does not enable anything — neither analytics nor signup-source attribution nor the beta offer. Each is enabled separately and deliberately — after this policy is live, and after the checks we set for ourselves are complete — so the disclosure always precedes the collection and never the other way round. Your career data — your résumé, bullets, preferences and applications — is not affected by any of them: none of it is sent to PostHog, none of it is used to infer a signup source, and none of it starts being used in a new way. Under that earlier disclosure, what begins to be recorded once analytics is enabled is a fixed set of events about product actions, and your account identifier, which we already hold, begins to be shared with a processor that has never had it — the part that made it a change rather than a correction. There is no in-product opt-out for analytics; account deletion removes those events, and the rights described above remain available by contacting us.
Contact
Questions or requests: hello@drit.to.