What Brickfield collects, stores, and does with your data.

1. What we collect

From the waitlist signup (/api/waitlist)

When you submit the waitlist form on the home page, the exit-intent modal, or a blog CTA, we collect:

• Email — required, used as the unique identifier.
• Name — optional.
• Role — optional, chosen from a fixed list: broker, lender, fund-manager, institutional-investor, or other. This is the buyer-ICP signal we use to understand who is signing up.
• Source — which form the submission came from (waitlist, exit-intent, or blog-cta). Set automatically by the page, not by the visitor.
• Hashed IP — the first 16 hex characters of a SHA-256 hash of the request IP. We do not store the raw IP.
• Referrer — the URL of the page you came from, if your browser sent one.

From the beta program application (/api/beta-request)

When you submit the form on /beta, we collect:

• Email — required.
• Full name — required.
• Fund or company — required.
• Role — required for the beta form (same fixed list as the waitlist).
• Notes — optional free-text field, truncated server-side to 2,000 characters.
• Hashed IP — same 16-hex SHA-256 truncation as above.
• Referrer — the page URL you submitted the form from.
• Submit timestamp — recorded on the server when the request is received.

From signup after a deal analysis (/api/signup)

When you claim the results of an underwriting run by entering your email on /analyze, we collect:

• Email, name, and company — what you enter into the claim form.
• analysisId — which underwriting run the claim is being attached to.
• UTM fields — utm_source, utm_medium, utm_campaign from the URL if present.
• Hashed IP — same as above.
• Referrer — the URL you came from.

What we do not collect

We do not collect passwords. Every form on Brickfield is passwordless — we email you a confirmation, and your identity is your email address. We do not run third-party advertising trackers, and we do not place cookies set outside what the page itself uses for session state.

2. Where it lives

All of the data above is stored in a single Postgres database hosted on Neon (a managed Postgres provider). The signup rows go into the users table, which has been built up across several migrations — 005_create_users.js created the table, 006_add_source_to_users.js added the source column, and 008_add_role_to_users.js added the role column.

The same users row is created or updated whether you submitted the waitlist or the beta form. The table's ON CONFLICT (LOWER(email)) DO UPDATE rule means your row is deduplicated on email — a beta application from the same email address you used on the waitlist updates the existing row rather than creating a second one.

3. How we use it

The data above is used for three concrete things, each tied to a specific code path:

Immediate confirmation email

When SMTP_HOST is set on the server (i.e. we have configured SMTP credentials for the production environment), the waitlist signup handler calls sendWaitlistConfirmation from services/email.js to send a confirmation email to the address you submitted. If SMTP is not configured on a given environment, signup still succeeds — you simply do not receive a confirmation email from that environment.

Four-step nurture sequence

After signup, a row is enqueued in email_sequence_queue for each of the four steps in our nurture sequence: an immediate confirmation, a problem-agitate follow-up, a soft-CTA follow-up, and a last-chance follow-up. The queue rows are processed by a scheduled background job (a Polsia cron) that fires each row at its scheduled send time and updates the row to sent, failed, or skipped based on outcome.

Same-day owner outreach for beta applications

When you submit the beta form, in addition to creating your user row, the server immediately emails the Brickfield operator with the full submission: your name, email, company, role, the notes you provided, and the time you submitted. This is how we follow up on every beta application within one business day. SMTP must be configured for this notification to be delivered.

4. Analytics

Every page render and every signup writes an analytics row:

• Page views — one row in page_views per page render, recording the page path, the 16-hex IP hash, the referrer, and the user-agent string (truncated to 500 characters).
• Analysis events — one row in analysis_events per signup of any kind (waitlist_signup, beta_request, signup), recording the IP hash and a metadata blob with whatever the form received.

The IP hash stored on every analytics row is the same 16-hex SHA-256 truncation described above. We do not store raw IPs anywhere in the database.

5. Retention

This section describes the current behavior of the system — not a policy we are committing to.

• users rows persist indefinitely. We do not currently run a deletion job. A user row stays in the table until we delete it on request.
• email_sequence_queue rows transition between pending → sent / failed / skipped based on what the cron does with them, but the rows are not deleted after sending. Historical rows stay in the table.
• page_views and analysis_events rows persist indefinitely.

6. Your choices and how to reach us

You have three choices, and they are all exercised by sending us an email:

If you would like to stop receiving the nurture sequence without deleting your signup, replying to any sequence email with the word STOP is the fastest path — the operator handles removal requests manually and you will not receive another scheduled email.

7. Changes to this policy

If we change anything material about how Brickfield handles personal data — what is collected, what is stored, how long it is kept, or who it is shared with — we will update this page and bump the last-updated date at the top. The current version is always at https://brickfield-ai.polsia.app/legal/privacy. Our Terms of Service cover the beta program and use of the platform — see Terms.