Privacy Policy

Effective Date: July 9, 2026

Last Updated: August 21, 2026

1. Introduction

This Privacy Policy describes how Ficombinator LLC ("we," "us," or "our") collects, uses, discloses, and protects information when you use SoloSearcher ("Service").

Who we are: Ficombinator LLC, Delaware, United States.

Where we operate: the Service is offered in the United States and intended for users in the United States. We do not offer it in the European Economic Area or the United Kingdom, and this policy is written to United States law.

For privacy inquiries, contact: [email protected]

2. Two Zones: The Baseline Universe and Your Private Workspace

Company data in SoloSearcher lives in two zones, and understanding the line between them explains almost everything else in this policy. (Service-level records — authentication data, audit logs, rate-limit counters, access requests — sit outside both and are described in Sections 3, 9, and 12.)

2.1 The shared baseline universe

The Service holds a shared baseline universe of company records built from public records — principally U.S. Small Business Administration PPP loan data released under the Freedom of Information Act, together with U.S. Census Bureau statistics and business-registry data. It is the same for every user, it describes businesses rather than Service users, and it is what anonymous search searches.

It is not built from any user's workspace. Nothing a user adds, edits, uploads, or analyses flows into it.

Anonymous search over this universe returns deliberately limited results — count ranges, coarse summaries, confidence language, and a small number of example companies — rather than the full universe or the enriched detail behind it.

2.2 Your private workspace

Your workspace holds the companies you keep and everything you attach to them: notes, ratings, statuses, contacts, uploaded documents, extracted financials, saved views, search preferences, the analyses your AI agent saves, and every other record you create. Companies may arrive there from the baseline universe, or because you created them by hand, imported a CSV, ingested a broker listing URL, or uploaded a CIM.

Other users never see any of it. Tenant-scoped reads are isolated in the database itself: they run on a restricted database role that row-level security confines to rows belonging to the requesting account, so a coding mistake in a read path cannot return another user's row. Writes and system operations run on a privileged role that row-level security does not constrain, and there isolation is enforced by the application and covered by automated tests. Section 5 states both precisely.

Two consequences are worth stating plainly:

• We do not pool your data. Nothing you add is merged across users, aggregated into a product, or sold. The baseline universe is built from public records and never from any user's workspace, and your copy of a company — once it is in your workspace — is yours alone, including every change and note you make to it.
• The records you keep may describe other people. A company record — particularly one drawn from public-record data — can name a business owner in a business capacity. That is personal data about someone who is not our user, and Section 8 describes how we handle it and how such a person can reach us.

3. Information We Collect

3.1 Account data (via Clerk)

Authentication is handled by Clerk, Inc. When you sign in, Clerk collects and provides us with your email address, display name (if set), session tokens and device identifiers, and login timestamps and IP addresses.

3.2 Private workspace data (user-provided)

Data you enter or upload into your private workspace, including company notes and ratings, pipeline statuses, contact records, uploaded documents (CIMs, tax returns, financial statements), and financial figures you record.

3.3 Payment data — none collected

The Service is free of charge and we collect no new payment data. There is no subscription and no trial, no payment card is requested at any stage, and card numbers have never reached our servers.

Historically, people who reserved a founding-member place completed a card verification through Stripe, Inc. That flow is retired: we send Stripe nothing, and no charge was ever made to anyone. v3 disclosed that four payment-derived fields — a Stripe customer identifier, a verification timestamp, a card fingerprint, and a founding-member rank — remained alongside any such reservation, and that the corresponding objects remained in our Stripe account.

Those records were deleted on 2026-08-20. The waitlist they sat in was removed from the Service entirely on the same day — its table is dropped and no signup path exists — so there is no founding-member reservation record left to describe, no way to create one, and no record in the Service retains payment-derived data.

On Stripe's side we deleted the customer record and detached its payment method. Stripe does not permit deleting the setup-intent object that records the verification, so that object remains in Stripe's systems under Stripe's retention terms, referencing a deleted customer and carrying no card number. See Subprocessors.

3.4 Agent interaction data

We send nothing to an AI provider. The Service performs no AI analysis of its own, holds no model credential you can spend on it, and never transmits your workspace to a model provider. There is no SoloSearcher-hosted AI chat or analysis product.

AI work happens in the agent you connect — Claude, ChatGPT, Gemini, or another supported agent — running under your own account with that provider. What your agent sends to its provider, and what that provider retains, is governed by your agreement with them, not by this policy. We are not a party to it and have no visibility into it.

What reaches us is your agent's tool calls to our API. We log each one: which tool was called, when, whether it succeeded, and a restricted set of request parameters — never the content of your notes, documents, or financial values (numeric financial parameters are recorded only as coarse bands). The one exception is the report_gap tool, whose free-text summary is, by its stated purpose, shared with the operator.

Your agent can read a document you uploaded and write extracted financials back into your workspace. When it does, the document goes from us to your agent at your instruction, and onward handling is between you and your provider.

3.5 Usage, diagnostics, and security data

• Vercel (hosting) logs request metadata (URL, status code, IP, user agent) as part of normal operations.
• Upstash (rate limiting) stores request counters keyed by account or network identifiers — counters only, no content.
• We maintain an append-only audit log of security-relevant actions (logins, key lifecycle events, deletions, corrections, agent tool calls). Audit metadata passes through an allowlist-based redaction layer so that free-text and financial values are excluded by construction.

3.6 Anonymous search and access requests

Searching without an account. You can search the baseline universe before you have an account, and doing so requires no email address and creates no account. The criteria you enter are sent to our own servers, which query the search service on your behalf; your browser never contacts that service directly. Your criteria are not placed in the page address, are not written to your browser's storage, and are held in memory for the length of your visit — reloading the page clears them.

To keep anonymous search available and to limit bulk extraction, our servers derive an abuse-prevention signal from the network address the platform reports for your request, together with a rotating identifier computed on our side. It is used for rate and disclosure limits only. It is not an account, we do not use it to build a profile of you, and we do not attempt to identify you from it.

Requesting access. If you ask to be invited, we collect the search criteria you built, your email address, and the versions of these documents you accepted, together with the time of acceptance. We use them to evaluate the request, to reach you about it, and — if we admit you — so that the search you saved is there for you. They are encrypted at rest. We do not use an access request to market unrelated products to you. You may ask us to delete a pending request at any time at [email protected].

Marketing-site analytics. Pages on the public site report coarse, allowlisted usage events (for example, that a search was run, or which outcome a preview produced). These events carry no search criteria, no email address, and no invitation token, and page addresses are reduced to a route template before being recorded. The public site sets a first-party analytics cookie (Section 13); if you later create an account and sign in, the coarse events recorded under that cookie are linked to your account so we can understand how people find and start using the Service. The events themselves never contain your search criteria or contact details, before or after linking. See Sections 10 and 13.

4. How We Use Your Information

We do not use your private workspace data for training AI models, marketing to third parties, or sale to data brokers. The baseline universe is built from public records, never from any user's workspace.

5. How Your Data Is Protected — Stated Truthfully

We describe our security model in terms of what is actually implemented and verified, not aspiration:

• Layered isolation, stated per direction. Access to your private data is enforced by application-level access control, and for tenant-scoped reads by database row-level security beneath it: those reads use a separate restricted database role, and the account they are scoped to is set per request inside the same database transaction. If that scope is ever missing, the policies return only shared, non-private rows rather than falling back to broader access, and the restricted role is required — the application refuses to serve a tenant read without it instead of quietly using a privileged connection.
• Writes are not row-level-security-protected, and we do not claim they are. Writes and system operations run on a privileged database role that row-level security does not constrain (a small number of tables force it even for that role). Isolation on those paths is enforced in application code, which scopes every statement to the acting account. Both directions are covered by automated isolation tests that run on every change to the codebase, but the guarantee differs: reads are constrained by the database, writes by the application.
• Per-user encryption at rest. Sensitive private content (documents and extracted financial data) is encrypted with a per-user data encryption key (DEK). When your account is deleted, your DEK is destroyed ("crypto-shred"), rendering the encrypted content unrecoverable, in addition to row deletion and file purging. The baseline universe is public-record data shared by all users and is not encrypted per user; the private work you attach to a company is.
• Encryption in transit. All connections use TLS.
• Internal service calls are authenticated. The search service that answers previews is not reachable from your browser; our servers call it over authenticated, signed requests.
• What we do not claim. This is not end-to-end encryption and not a zero-knowledge system. The Service must process your data to operate (for example, to run extractions and searches you request), and the operator retains the technical ability to access data for service operation. Our operating stance on that access is described in Section 9.

6. Your AI Agent's Access

SoloSearcher is designed to be used by AI agents you connect (via API keys or OAuth you authorize):

• Your agent acts as you: it can see only your own workspace — exactly the boundary you have, and never another user's data.
• Keys carry explicit capability grants (read, or read + write) and expire by default; you can revoke them at any time.
• Agent tool invocations are logged as described in Section 3.4 for cost control and security auditing.
• Your agent's conversations with you happen inside your AI provider and are not visible to us; we see only the tool calls that reach our API.

7. Estimated Financials — Disclaimer

The Service derives modeled estimates (for example, estimated revenue, payroll, and seller discretionary earnings) from public industry statistics and the records available for a company. These are:

• Labeled as estimates wherever they appear, with a stated confidence level;
• Accompanied by a methodology explainer describing how they are derived;
• Not financial statements, appraisals, valuations, or investment advice; and
• Provided without warranty of accuracy. Verify independently before relying on any figure in a transaction.

The baseline universe is compiled from public records that carry a source date, shown alongside the data. It records businesses that exist; it does not indicate that a business is for sale or that its owner wishes to be approached.

8. Information About Business Owners and Other Third Parties

This section is for people who are not our users — business owners, brokers, and other contacts who appear in the baseline universe or in a user's workspace.

Company records describe businesses, and many derive from public records: principally U.S. Small Business Administration PPP loan data released under the Freedom of Information Act, together with U.S. Census Bureau statistics and business-registry data. Where such a record names an individual in a business capacity — a business owner named in a public loan record, for example — we hold that information so a user can identify, evaluate, and approach a business about a possible acquisition. Users may also add business contacts of their own.

Where the record sits matters. A record in the baseline universe is held by us, compiled from public sources, and shared across users. If you tell us a fact in it is inaccurate, we will review the claim against its source and applicable law, and we can correct or remove the record there.

A record in a user's private workspace is different: that user decides what it holds and how long to keep it, and we hold it on their behalf — much as any customer-relationship tool holds the records its user keeps about the businesses they deal with. We do not edit or delete one user's workspace records because someone else asked us to, and a correction in the baseline universe does not reach back into copies users already keep. Such a record goes when that user deletes it, or when their account is deleted and their data is purged (Section 12).

Contacting us. If you are named in a record, you can write to [email protected]. We read what we receive. We do not promise a particular outcome, and for the reason above we do not delete another person's workspace records on request.

9. Operator Access Stance

Day-to-day operator monitoring is metadata-only: aggregate usage, cost roll-ups, error rates, audit events, and the redacted invocation logs described above. The operator does not browse users' private content. The only operator actions that touch private content are the ones you request — a data export or an account deletion — and both are recorded in the audit log.

10. Subprocessors

A full list with data-flow details is maintained at /legal/subprocessors.

11. Your Rights

The rights in this table are your rights over your own account and workspace. If you are not a user but appear in the baseline universe or in someone else's workspace, Section 8 explains what we do and how to reach us.

California (CCPA/CPRA): we do not sell or share personal information, and we will not discriminate against you for exercising a right. We respond to rights requests within 30 days.

12. Data Retention

13. Cookies

The Service sets Clerk's authentication cookies (required to sign in), a first-party product-analytics cookie, and no advertising or third-party tracking cookies.

The analytics cookie is set by PostHog on our own domain (solosearcher.com) and holds a random identifier. On the public site it groups the coarse, allowlisted events described in Section 3.6 under that identifier without knowing who you are; no analytics profile is created for you while you remain anonymous. If you create an account and sign in, that identifier is linked to your account so we can see the path from first visit to signup. Your search criteria are never stored in analytics — before or after sign-in — and remain only in memory for the length of your visit.

14. Children's Privacy

The Service is not directed to children under 16, and we do not knowingly collect their personal information.

15. Where Data Is Processed

Our databases and file storage are located in the United States, and that is where your workspace — company records, documents, financials, notes — is held. Two qualifications keep this accurate:

• The public site is served through a global content-delivery network. A request may therefore be routed through, and public page content cached at, an edge location outside the United States, which handles request metadata as described in Section 3.5. Private workspace data is not stored in that network. This is why Vercel appears as "United States / Global CDN" in Section 10 and in Subprocessors.
• One EU fallback. If the U.S. Census geocoder cannot resolve a business address, we fall back to OpenStreetMap's Nominatim service, which is operated in the EU and receives only that business address.

16. Governing Law

This policy is governed by the laws of the State of Delaware, United States. United States federal and state privacy laws apply to the extent they require.

17. Changes to This Policy

We will notify you of material changes by updating the "Last Updated" date and, where required, by email or in-app notice.

18. Contact

Privacy inquiries: Ficombinator LLC — [email protected]

Version: v5 (draft) · Last updated: 2026-08-21 — product analytics described accurately: a first-party analytics cookie on the public site, linkage of coarse pre-signup events to the account after sign-in, and a 24-month analytics retention period added to Section 12. Supersedes v4 (2026-08-20).

v4 (2026-08-20) note: the retired data storefront removed; the single-zone description replaced with the shared public-record baseline universe and your private workspace; anonymous search, access requests, and their retention described for the first time; SoloSearcher-hosted AI analysis removed and Anthropic retired as a subprocessor — AI work runs in an agent you connect, under your own provider account; Vercel Web Analytics listed; the row-level-security description corrected to distinguish database-enforced tenant reads from application-enforced writes; the data-residency statement corrected to acknowledge the global content-delivery network; Sentry removed — it was listed in v2 and v3 but never had a DSN configured and never received any data, and the dependency is now gone from the Service; the waitlist removed from the Service outright — its table dropped and the founding-member reservation records carrying Stripe payment-derived fields deleted, together with the Stripe customer record — so waitlist entries and reservation records are no longer collected, retained, or listed; the one Stripe object that cannot be deleted is described rather than glossed. Supersedes v3 (2026-08-13).