What we hold, written from the schema rather than from a template.

Four groups, and only one of them signed up. Employees of a general contractor who hold accounts; subcontractor contacts who receive invitations to bid; client contacts who receive a proposal link; and anyone who simply visits the public site.

The split matters throughout. For its own account records Wire-In decides what is collected. For everything a contractor loads about its vendors and clients, the contractor decides and Wire-In only processes — which is why there is a separate data processing addendum, and why this policy should point at it rather than blur the two.

An id, an email address, a full name, and which organization the person belongs to with which of three roles. That is the whole of it in the application database.

Passwords are not in that database. Authentication is handled by Supabase Auth, which stores credentials hashed in a schema this application does not query. The policy should say so plainly, because it is both true and the kind of thing a reader assumes the other way.

Email confirmation is required at sign-up and password reset is by emailed link, so an email address is functionally mandatory rather than optional.

Vendor records carry a company name, trades, service areas, a website and a contractor license number. Vendor contacts carry a name, an email address, a phone number and a role. All of it is entered by the contractor, about businesses it works with.

Files are the sensitive part. The product accepts attachments classified as bid summaries, proposals, quotes, certificates of insurance, W-9s or other. A W-9 contains a taxpayer identification number and a certificate of insurance identifies a third-party insurer and policy.

The precise, checkable statement is this: the document is stored as a file in a private bucket, and the database records only its filename, storage key, content type, size, who uploaded it and its kind. No taxpayer identifier, tax ID, social security number, bank account or routing number is extracted, indexed, searched or displayed anywhere in the product, and no column exists to hold one. The policy should make that distinction rather than collapse it in either direction.

Bid values, submitted totals, outcomes, quote comparisons, who was invited and who declined. For a general contractor this is the material that actually matters, and although most of it is not personal data, a privacy policy that ignores it will read as evasive to the person doing the review.

The right move is a short section acknowledging it and pointing at the security overview and the confidentiality terms, rather than trying to cover it under a personal-data heading where it does not belong.

When a contractor sends a proposal, the recipient email addresses are stored with it and a private link is generated. Opening that link is recorded — the fact of an open, so the estimator knows the proposal reached someone.

The recipient never created an account and may not know Wire-In exists. The policy needs to describe what is recorded, who sees it (the contractor who sent it), and how a recipient can ask about it.

The link is unguessable and deliberately excluded from search engines, but it is public to anyone holding it. That is a design decision worth stating rather than leaving for a reader to discover.

Session cookies set by Supabase Auth to keep a signed-in user signed in, and a theme preference kept in the browser’s own local storage. Both are strictly functional.

There is no analytics package, no advertising pixel and no third-party tracker installed in this application today. A few links carry a data-track attribute in anticipation of one, but nothing reads it and no event leaves the page.

That is a strong and unusual thing to be able to say, and it should be stated only for as long as it stays true — adding any analytics tool means editing this section in the same change.

Operating the product, sending the transactional email the workflow depends on (invitations to bid, proposals, invites to join an organization, password resets), and billing.

Whether anything is used for product analytics, benchmarking across customers, or model training has to be answered explicitly. Nothing does today. If that changes it is a material change and should be treated as one.

Four, all verifiable from the codebase. Vercel hosts the application. Supabase provides the Postgres database, authentication and file storage, running on Amazon Web Services in the us-west-2 region. Stripe processes payments. Resend delivers transactional email.

Card details never reach Wire-In: checkout is hosted by Stripe and the customer is redirected to it, so the card number is entered on Stripe infrastructure and Wire-In stores only Stripe identifiers, a tier, a status and a period end.

This list needs to live somewhere it can be maintained, with a mechanism for notifying customers before a sub-processor is added. A stale sub-processor list is one of the few things in a privacy policy a customer will actually check.

The United States. The database and file storage sit in the us-west-2 region; the application is deployed on Vercel infrastructure.

There is no international transfer mechanism in place because there is currently nothing to transfer. The first Canadian or United Kingdom customer changes that, and this section will need real work before that sale rather than after it.

There is no retention schedule implemented in the product today. Nothing expires, nothing is purged on a timer, and no automated deletion job exists.

A schedule has to be decided and then built, in that order, and the policy must not describe one that does not run. Bid history is the hard case: a contractor wants years of it, because the hit rate is the point, and that argues for a long default with a deletion path rather than a short automatic one.

This section should be short and point at the security overview rather than restate it. The overview is written to be checkable claim by claim, including the gaps, and duplicating it here guarantees the two will eventually disagree.

What belongs here specifically is the isolation model in one sentence — one contractor cannot read another contractor’s data because Postgres row-level security enforces it, not because application code remembers to filter — and a link.

Access, correction and deletion, and the routing question that goes with them. A subcontractor contact who wants their details removed generally has to ask the contractor who entered them, not Wire-In, and the policy should say that clearly instead of leaving the person to guess.

State-level United States privacy law is where the concrete obligations will come from. Which states apply depends on where the entity is formed and where customers are, and neither is settled.

A working address for these requests is a prerequisite. The address published on this site does not yet have mail routed to it.

A business product sold to commercial general contractors, not directed at anyone under eighteen and not knowingly collecting their data. Short section, but expected.

How a change is published, how a material change is notified, and a visible date for when the policy last changed. The date should be maintained by hand, because a build-stamped date would claim a review that never happened.

Who to write to, and the identity and address of the legal entity behind Wire-In. That entity is not yet formed, so this section cannot be completed today.