Privacy Policy

Bidador is quote follow-up software for residential contractors. It connects to a mailbox you already own, finds the estimates you have sent from it, tracks whether customers replied, sends the follow-ups you have configured, and reads the replies so the ones needing a decision reach you.

This policy explains what information Bidador collects, why, who it is shared with, how long it is kept, and how to remove it. It covers the Bidador website at bidador.com and the Bidador application. It does not cover the mail providers, search engines or other websites you reach from here, each of which has its own policy.

Bidador is sold to businesses for business use. It is not directed at consumers and is not intended for personal or household mailboxes.

When you create an account and use the product, Bidador stores:

• Account details — your name, your email address, and a password. Passwords are stored only as a scrypt hash; Bidador never holds your password and cannot recover it.
• Business details — your business name, time zone and currency, and the answers you give during onboarding.
• Your settings — the follow-up sequences you write (subject lines, message wording and timing), your sending hours, and whether automation is paused.
• Your decisions — the outcomes you record on a quote, your confirmations and edits in the review queue, corrections you make to a reply classification, and the feedback you give on a BidGuard recommendation. These are stored because they are what makes the product yours rather than generic.
• Your acceptance of these documents — the date and time you accepted, the version of the Terms of Service and of this Privacy Policy you were shown, and the address the request came from where we can vouch for one. Kept so that what you agreed to, and when, is a matter of record. We add a row each time you accept rather than overwriting the last one.
• Anything you send us — support requests and the messages you write to us.

Connecting a Gmail mailbox is optional, and nothing below happens until you complete Google’s own consent screen. Bidador requests exactly three scopes and no others:

• gmail.readonly — to find the estimates you have already sent, to read the replies on those threads, and to download the PDF or text attachments on a message that looks like an estimate, because the total is often in the document rather than in the body. Bidador cannot modify, label, archive, mark as read, or delete anything in your mailbox with this scope.
• gmail.send — to send the follow-ups your own sequence has scheduled, from your address, as a reply in the original thread.
• userinfo.email — to know which mailbox address you connected, so a follow-up leaves from the address the estimate was sent from.

What Bidador reads

Bidador searches your sent mail for candidate estimates and reads those messages, including their body text, their subject, the sender and recipient names and addresses, the date, the Gmail thread and message identifiers, and the names, types and sizes of any attachments. When a thread is identified as an estimate conversation, Bidador also reads later messages on that thread, including customer replies. After the first scan, Bidador uses Gmail’s history API to see only what changed rather than re-listing your mailbox.

Most of what is read is discarded immediately. Mail that is not an estimate conversation is scored locally and dropped; drafts, spam and trash are excluded from detection.

What Bidador stores

• The estimate itself — customer name and email address, the project, the amount, the date it was sent, and its status.
• The messages on that estimate thread, stored as text with quoted history, signatures and boilerplate stripped out at ingestion. HTML mail is converted to text; nothing from a mailbox is ever stored or rendered as markup.
• Attachment metadata — filename, type and size — and, for an attachment Bidador opened, the text extracted from it. Readable attachments on a candidate estimate are opened, subject to a size limit and a cap on how many one message may cost; anything skipped is said out loud on the quote rather than silently half-read. The file itself is parsed in memory and the bytes are discarded once the text is out; the record notes when.
• A processing ledger row for every message Bidador has examined, accepted or rejected: the Gmail message and thread identifiers, a content hash, the date, the decision, and the version of the logic that reached it. This is what stops Bidador re-downloading and re-reading the same mail on every later scan.
• Your Google OAuth access and refresh tokens, encrypted with AES-256-GCM before they are written. They are never returned to a browser, never written to a log, and are readable only by the part of the server that talks to Gmail.

Bidador does not store mail from threads it has not identified as estimate conversations, does not access your contacts or your calendar, and writes nothing back into your mailbox except a follow-up your own sequence asked it to send. It applies no labels, archives nothing, and changes nothing’s read state.

Bidador’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

In particular, and specifically for Gmail data:

• Google user data is used only to provide and improve the features described in this policy — finding your estimates, following them up, and reading the replies.
• Google user data is never used for advertising, and is never sold, rented or licensed to anyone.
• Google user data is not used to develop, improve or train generalized or non-personalized artificial intelligence or machine learning models. Where content is sent to an AI provider, it is sent to obtain a result for that one request and for no other purpose — see AI processing.
• Google user data is transferred only to the service providers listed below, only as needed to operate the features you asked for, and only under terms consistent with this policy.
• Humans do not read your Google user data, except with your explicit permission (for example, when you ask us to investigate a specific problem), where necessary for security, or where required by law.

• Session records — when you sign in, Bidador stores a row holding a hash of your session cookie, the browser’s user-agent string, the time, and an IP address where our infrastructure can vouch for one. Where the address cannot be established reliably, it is stored as empty rather than as a value nobody set.
• An audit trail — mailbox connections and disconnections, quote outcomes, review decisions, classification corrections and similar account actions, with who did them and when.
• Security counters — rate-limit counts for sign-in, sign-up, password reset, mailbox connection and a handful of other actions, and a record of when a password reset or verification link was requested.
• Operational records — background job rows, sync progress, AI usage counts and timings, and delivery records for the transactional email we send you.
• Server logs. Bidador’s own application logs drop fields named for content or credentials rather than truncating them, replace email addresses with a stable fingerprint, and redact anything shaped like a token. Message bodies, model prompts and access tokens are not written to them. Our hosting and network providers keep their own request logs, which include IP addresses.

Bidador runs no analytics product and no advertising pixels, and does not build a profile of you across other websites. The only third-party scripts on its pages are Paddle’s, for billing — see service providers.

• To detect the estimates in your sent mail and reconstruct their history.
• To schedule and send the follow-ups you have configured, from your own mailbox.
• To read replies and decide which ones need you — and to stop a scheduled follow-up the moment a customer, or you, has replied.
• To produce your reports, your recovery board and your BidGuard recommendations from your own history.
• To send you transactional email: address verification, password resets, security notices such as a new sign-in or a disconnected mailbox, and trial notices.
• To keep the service secure and working — rate limiting, abuse prevention, debugging, and the audit trail.
• To answer your support requests.
• To bill you, if and when paid subscriptions are enabled on your account — see service providers.
• To comply with law.

Bidador uses a third-party AI provider for the judgements deterministic code cannot settle. The active provider today is Fireworks AI. We will update this page before moving to a different one.

Not every message is sent to a model

Content reaches an AI provider only after cheaper steps have failed to settle a case. A Gmail search narrows the candidates; the processing ledger drops anything already examined; local rules score the subject, body, recipients and attachment names; and PDF totals are extracted locally. Most messages — including everything rejected as not an estimate — are settled by those steps and are never sent anywhere.

What is sent when a model is used

• For estimate detection and extraction: the message subject, a trimmed excerpt of the message body (quoted history and signatures already removed, capped at roughly 1,200–1,500 characters), attachment filenames, selected sections of text extracted from an attached PDF, the customer’s email address, the date, and the totals local parsing already found.
• For reply classification: the newest customer message only (trimmed, capped at roughly 2,000 characters), plus three fields already stored about the quote — the project title, the amount, and how many days ago it was sent. The preceding message is included only when the reply cannot stand alone, such as a bare “yes, that one”.
• For a suggested reply draft you have asked for: the customer’s first name, the project, your name and business name, and a short excerpt of their last message.

Whole mailboxes, whole threads and whole documents are not sent. An input that exceeds the size limits is refused rather than truncated, and the case goes to your review queue instead.

What comes back, and what is kept

The provider returns a structured result — a classification, a confidence, a short reason, extracted fields. That result is stored against the quote, and cached against your organization keyed by the task, the logic version, the model and a hash of the content. The cache is what stops the same message being read twice: identical content is answered from the stored result rather than sent again, and a message is re-processed only when its content changes, when the analysis version is deliberately raised, after a failure, or when you explicitly ask for a rebuild. A cached answer is never shared between organizations, even for byte-identical mail.

What AI is not allowed to do

Bidador will not quote a price, offer a discount, negotiate, change scope, promise availability or a start date, or accept contract terms — and this is enforced by code independently of what a model returns, then checked again immediately before any message is sent. A message that would do any of those is held back and shown to you. Suggested reply drafts are suggestions: they are shown to you to review, edit and send yourself, and are never sent on your behalf. Automated follow-ups are rendered from the templates you wrote, not from model output.

BidGuard

BidGuard reads your own stored history — past inquiries, the quotes that followed them, and the outcomes you recorded — and produces a recommendation about how much estimating effort a new request deserves, together with the counts it is based on. It is deterministic: it sends nothing to an AI provider. It advises; it does not reject, hide, close, discount or reply to anything on its own, and it makes no binding decision. The recommendations it made and what happened afterwards are stored, so advice can be checked against outcomes.

Bidador does not sell your information, does not rent or license it, and does not share it for advertising. Your data is never used to serve another customer of ours: every record is scoped to your organization at the data layer.

It is shared in four situations:

• With service providers who process it on our behalf to run the service, listed below.
• With the recipients you send to. A follow-up goes to your customer, through your own mailbox, from your address.
• Where the law requires it — a valid legal request, or to establish, exercise or defend legal claims.
• In a business transfer. If Bidador is acquired or merged, account data may transfer with it, subject to this policy or to a successor policy you are told about first.

These are the third parties that actually process data for Bidador today:

• Railway — application hosting, the background worker, and the managed PostgreSQL database where everything described here is stored.
• Cloudflare — DNS and network delivery for bidador.com. Requests to the site pass through it, including their IP addresses.
• Google — your own mail provider, when you connect a Gmail mailbox. Bidador reads and sends through Google’s APIs under the scopes you granted.
• Fireworks AI — AI inference for the judgements described above. It receives the message excerpts and extracted fields named in that section, which can include Gmail-derived content.
• Resend — delivery of transactional email from Bidador to you: verification, password reset, security and trial notices. It receives your email address and the content of those messages. It is not used to send mail to your customers; that goes through your own mailbox.
• Paddle — payments, as Merchant of Record. Paddle collects and holds the payment details directly: Bidador does not receive or store card numbers, and keeps only opaque references to your Paddle customer and subscription, its plan and its status. If a renewal payment fails, Paddle retries it automatically and emails you a link to its customer portal, where you can update your payment details; that happens on Paddle’s side, and Bidador’s pages do not show payment-recovery prompts. For billing, pages on bidador.com, including public ones, load Paddle’s scripts, which send Paddle information about your browser, your device and your visit to the page, including your IP address. On a signed-in page those scripts are also given the customer reference Paddle already holds for your account. Paddle handles that information under its own privacy policy.

A package existing in the codebase is not the same as a service receiving data. The list above is the set that actually does.

Bidador sets no advertising or analytics cookies. It sets two, both strictly necessary:

• A session cookie holding an opaque token, set HttpOnly, SameSite=Lax and Secure, and carrying the browser-enforced __Host- prefix in production. It lasts at most fourteen days, and expires sooner if unused for seven. Signing out revokes it on the server.
• A short-lived mailbox-connection cookie, set for ten minutes while you complete Google’s consent screen so the response can be matched to the request you started. It is deleted as soon as it is used.

Your browser also keeps one preference in local storage — the quote filter you last used, so the list opens where you left it. It stays on your device and is never sent to us.

Paddle’s scripts, which run on these pages for billing, may set their own cookies or local storage. Those are Paddle’s, and Bidador does not read them.

Your business records — quotes, customers, conversations and their messages, inquiries, extracted attachment text, pursuit history and the audit trail — are kept for as long as your account exists, because they are the product: a reconstructed history that cannot be rebuilt from anywhere else. They are deleted when you use either control under Settings → Your data, or ask us to remove them.

Some records are pruned automatically on a schedule:

• Completed background jobs after 7 days; failed ones after 30.
• Expired sessions one day after they expire.
• Cached AI results nothing has used for 90 days.
• AI usage counters after 180 days.
• Password reset and verification tokens 7 days after they expire.
• Transactional email delivery records after 90 days.
• Rate-limit counters and background-worker records shortly after they stop being useful.

Three things are deliberately kept rather than pruned.

• The processing ledger, because deleting it would make the next scan re-download and re-read your whole mailbox at real cost.
• A record that a given mailbox has already had a free trial, so a second one cannot be claimed for it. While your account exists that record is the provider name, the mailbox address and a date.
• A count of how many times mailbox data has been deleted on your account in the last 30 days, so that the limit on that operation means something. It holds your account, who asked, and when — no mailbox, no address, no content.

Separately, and only for as long as it is needed to prevent repeated free trials, we keep a small anti-abuse record that survives an account deletion. It is described under Deleting your data, where the deletion it survives is described.

Attachment bytes are discarded as soon as text has been extracted from them. Where our hosting provider retains database snapshots or backups, information may persist inside those for a limited period after it has been deleted from the live database.

• Traffic to bidador.com is served over HTTPS, and the database connection requires TLS in production.
• Mailbox access and refresh tokens are encrypted with AES-256-GCM before storage, never returned to the browser, and never logged.
• Passwords are stored as scrypt hashes; session cookies are stored only as a SHA-256 hash.
• Every read and every write is scoped to one organization at the data layer, which refuses a query that does not name one.
• A Content Security Policy with a per-response nonce and no inline script, which lets a page load outside code only from Paddle, for billing, and lets the page’s own scripts send requests only to Bidador itself.
• Rate limiting on sign-in, sign-up, password reset, mailbox connection and other sensitive actions, and an audit trail of account actions.
• Logs that drop content and credential fields by name rather than relying on care.

No system is perfectly secure, and we do not claim otherwise. Bidador does not hold SOC 2, ISO 27001 or HIPAA certification, and is not intended for protected health information or other regulated categories of data. If you believe you have found a vulnerability, write to support@bidador.com.

• See and correct your data. Quotes, customers, conversations, review items and settings are all visible and editable in the app, and you can overrule any reading Bidador has made.
• Turn automation off. Pause follow-ups, disable individual steps, or edit the wording and the timing at any time.
• Disconnect a mailbox, which stops all reading and all sending — see below.
• Delete your data yourself. Settings → Your data holds two controls: delete everything Bidador built by reading your mailbox and keep the account, or delete the account outright. Both are immediate. For a copy of your data, write to support@bidador.com from the address on the account.
• Email. Bidador sends transactional and account email only — verification, resets, security and trial notices. There is no marketing list to unsubscribe from, and security notices cannot be turned off while the account is open, because they exist to tell you about access to it.

Depending on where you live, you may have additional rights over your personal information, such as access, correction, deletion, or objecting to certain processing. We honour those requests at the address above and do not discriminate against anyone for making one. Where you use Bidador to process your own customers’ information, you decide what happens to it and we act on your instructions.

You can disconnect a connected mailbox at any time from Integrations in the app. When you do, Bidador deletes the stored access and refresh tokens for that mailbox immediately, clears its sync position, and stops reading and stops sending. The disconnection is recorded in your audit trail.

Disconnecting also revokes the grant at Google. Bidador sends the refresh token back to Google’s revocation endpoint before deleting its own copy, so the authorisation ends rather than simply going unused. If that call does not get through — Google being unreachable, for example — the mailbox is still disconnected here and the credentials are still deleted; you can withdraw the grant yourself by removing Bidador from your Google Account permissions. Removing it there also stops Bidador on its own, because the tokens it holds stop working; the app will tell you the mailbox needs reconnecting rather than failing quietly.

Disconnecting does not by itself delete the estimates and conversations Bidador has already reconstructed — that history stays in your account so you do not lose it by unplugging a mailbox. Deleting it is a separate, deliberate act, described below.

Two controls live under Settings → Your data, and they are deliberately different things. Both are available to the account owner, both require typing a confirmation word, and both take effect immediately.

Delete the data from your mailbox

Removes everything Bidador holds because it read your mail, and keeps your account: the estimates, customers, conversations and message text; attachment text and the review queue; the processing ledger; reply classifications and cached AI results; your pursuit and BidGuard history; scheduled follow-ups, which are cancelled rather than sent; sync state; and the mailbox connection itself, whose grant is revoked at Google and whose stored credentials are deleted. Queued background work for your account is cancelled in the same operation, so nothing re-downloads what was removed.

Your sign-in, your business details, your plan and your follow-up sequences are kept, and so is the account audit trail — with the mailbox address removed from it. Bidador will find nothing until you connect a mailbox again, and reconnecting starts a fresh scan rather than restoring anything.

Delete your account

Removes all of the above and the organization itself: its settings, its people, its audit trail and its subscription record, along with your sign-in if this is the only business you belong to. You are signed out immediately. This cannot be undone and support cannot restore it.

If you would rather we did it, or you need a copy of your data first, write to support@bidador.com from the address on the account.

What survives an account deletion

One record does, and we would rather say so plainly than let you find out. When an account that has used a free trial is deleted, we keep a minimal trial-eligibility record so that the same person or the same mailbox cannot claim a second free trial by deleting the account and signing up again. Without it, “delete and start over” is an endless supply of free Pro, and the cost of that lands on every customer who pays.

What that record contains, exactly:

• A one-way keyed fingerprint of your sign-in address, of the mailbox that was connected, and — where the provider has one — of the provider’s own account identifier. These are computed with a secret key held by the service. They cannot be turned back into an address, and unlike a plain hash of an email they cannot be matched by trying a list of likely addresses.
• The date the trial was granted.

What that record does not contain: your name, your readable email address, your mailbox address, any message, subject, attachment, quote, customer, AI output, access token, IP address or device information. It is not used for anything other than deciding free-trial eligibility, and it is never shared, sold or used to build a profile.

The readable copy of that information — the provider name and mailbox address held while your account exists — is deleted with everything else. Only the fingerprints remain.

Your record of accepting these documents goes too, along with the address it was accepted from. If you belong to a second business on Bidador you keep your account, so that record stays with you and stops naming the business that was deleted.

One further thing ages out rather than going immediately: an entry in our transactional email log for each message we sent you — a template name, a delivery status and a short one-way fingerprint of the address, never the address itself and never the message. Those are pruned 90 days after they are written, as described under retention.

Beyond that, we keep only what we are required to keep by law. Deletion is immediate in the live database; where our hosting provider keeps database snapshots or backups, data can persist inside those for a limited period afterwards, as described under retention. We do not claim otherwise.

How often mailbox data can be deleted

“Delete the data from your mailbox” can be used up to three times in any rolling 30-day period. Rebuilding a mailbox history is expensive to do, and repeating it on a loop is the one pattern that abuse takes here. If you reach the limit, Bidador tells you when the next one becomes available. Disconnecting and reconnecting a mailbox is not limited and never has been, and neither is deleting your account.

If three is genuinely not enough for something you are doing, write to support@bidador.com and we will reset it.

Bidador is a business tool and is not directed at children. It is not intended for anyone under 18, and we do not knowingly collect information from children. If you believe a child has provided us information, write to support@bidador.com and we will delete it.

Bidador is operated for customers in the United States, and its application and database are hosted there. Some of the service providers listed above operate globally — network delivery in particular is distributed by design — so information may be processed or routed outside the United States in the course of delivering the service. If you use Bidador from another country, you are sending your information to the United States for processing.

We may update this policy as the product changes. The effective date at the top of this page always reflects the current version. If a change materially affects how Google user data or your customers’ information is handled, we will tell account holders by email before it takes effect, and — where the change requires it — ask for your consent again.

Questions about this policy, requests for a copy of your data, deletion requests and security reports all go to support@bidador.com.

The companion document is the Terms of Service, which governs your use of Bidador.