An honest word on “anonymous”
Identity-minimising, not zero-knowledge.
Privacy is the product here, so we would rather be precise than sound impressive. Rbundle is identity-minimising, not zero-knowledge. We collect the least we can, we do not store a Buyer's identity or contact details against an account, and we cannot leak what we do not hold — but a sign-in email exists, and ordinary server logs exist. This policy sets out exactly what we hold and what we do not.
Anonymity also runs in one direction. Providers are not anonymous: a firm that proposes is named, verified and visible to the Buyer considering it.
We do not sell personal information, and we do not share it for cross-context behavioural advertising.
What we collect from Buyers
A sign-in email, banded business attributes, your answers, and ordinary technical data.
- A sign-in email address, used for magic-link sign-in and for notifications. It is never shown to Providers.
- Business attributes needed to scope and price work — entity type, size band, industry, states of operation, revenue band where it genuinely changes a quote. These are held in bands rather than exact figures wherever a band will do.
- Your answers to the Common RFP, including free-text answers, and your stated preferences. These are stored under a pseudonymous account identifier rather than a name.
- Your IP address and basic usage and diagnostic data — time, browser, and the actions taken in the application — used to operate the service and to prevent fraud and abuse.
We do not store, for a Buyer: legal or trading name, individual names, street address, phone number, EIN or other direct identifiers. This is enforced in the schema, not only in policy: the data model is scanned so that no table owned by a Buyer account can carry an identity field.
While you are signed out, a Request you are building is held in your own browser and is not written to our servers. Joining a waitlist or asking us to add a service does record that request, because there would be no point otherwise.
What we collect from Providers
Firm identity, credentials, insurance. Providers are meant to be identifiable.
From a Provider we collect firm identity and contact details, the licences and registrations we verify, evidence of professional indemnity cover, the services and jurisdictions the firm offers, seat and member information for the firm's users, and the Proposals it submits together with the documents attached to them. None of this is anonymised, because a Buyer must be able to see who is proposing.
The one moment identity is exchanged
At selection, to one firm, and not into our database.
When a Buyer selects a Proposal, the Buyer enters the contact details needed to begin work. Those details pass through to that single selected Provider. They are not written to our database, our logs or our analytics. Providers that were not selected are told only that the Buyer chose elsewhere.
There is one exception and it is opt-in and off by default. A Buyer sending a Request directly to Providers it names may choose to identify itself to those Providers up front. Where a Buyer chooses that, the contact information is stored in a single dedicated record scoped to that invitation, and nowhere else.
One thing we cannot do: once a Provider has your identity, deleting it from our systems removes it from our custody, not from theirs.
How we use information
To run the marketplace, route work correctly, stop abuse, and understand the market in aggregate.
- To deliver the service: build and send Requests, route them to eligible Providers, deliver Proposals, and send the notifications that go with each step.
- To verify Providers, including licence lookups against public registries and checking evidence of insurance.
- To prevent fraud, abuse and violations of the Terms, and to keep the Marketplace secure.
- To provide support, including looking up a Request by its code.
- To understand, in aggregate, what the market asks for and what it is offered — which services are requested, at what price and turnaround, and with what outcome.
We analyse usage under the pseudonymous account identifier for internal product and operations purposes. That behavioural record is never exposed to Providers, and no Provider is shown a Buyer's history across Requests.
Who we share it with
Processors that run the service, and legal process. That is the list.
We do not sell your data. We share it only with the service providers that process it on our behalf under equivalent obligations, with the selected Provider in the selection flow described above, and where the law requires it or where sharing is necessary to prevent fraud, abuse or harm.
The processors we rely on to run the Marketplace:
- Vercel
- Application hosting and delivery.
- Supabase
- Managed Postgres database, authentication, and file storage for Proposal documents and insurance certificates. Data is held in the United States.
- Resend
- Transactional email — sign-in links, Proposal alerts and service notifications.
- PostHog
- Product analytics, used to understand how the application is used.
Rbundle also uses ordinary business tools — email, documents and a customer-relationship system — for company correspondence with people who contact us directly. Anonymous marketplace Requests are deliberately kept out of those systems.
CONFIRM before launch: execute data-processing agreements with each processor named above, confirm each one's sub-processors and data location, and decide whether to publish a dated sub-processor list with an advance-notice commitment.
Retention, closure and erasure
Closing an account severs your login and cancels live work. Anonymised records are kept.
You may close an account at any time from your account settings, and closure is immediate. When you do:
- The account's link to your sign-in is severed. If it was the last account under that email, the sign-in itself is deleted.
- Live Requests are cancelled so that Providers can no longer respond to them, and a Provider's outstanding Proposals are withdrawn.
- Any identity you revealed to a Provider through a Direct Invitation is deleted from our systems.
- For a Provider, the identifying Proposal document is deleted and the link between the firm and its past Proposals is severed.
What is kept, and we would rather be plain about it: your Requests, answers and the structured content of standing Proposals — service, price, turnaround, coarse geography and outcome — are retained in anonymised form, with nobody attached to them, so that we can understand what the market asks for and what it is offered. A Proposal that was standing when a Request closed is kept as market data whether or not it won. Drafts, withdrawn Proposals and orphaned uploads are not kept.
Closing an account never prevents you from signing up again later.
CONFIRM with counsel, flagged as a known gap: retain-and-anonymise on closure sits in tension with a right to erasure in jurisdictions that require actual deletion rather than anonymisation. A true-delete path for formal erasure requests is not yet built. Counsel should confirm whether the retained anonymised set can re-identify a firm in a thin market, set a retention schedule, and decide the disclosure this section must make.
Your choices
Export your data, close your account, or write to us.
Any Request or Bundle can be exported to CSV or Excel from its own page; a Bundle exports as one tab per service. You can close an account from your settings, as described above. For anything else — access, correction, or a question about what we hold — write to info@rbundle.com.
Because we hold so little that identifies a Buyer, the sign-in email is generally the only way we can connect a request to an account. Keep it current.
CONFIRM with counsel: which state and international privacy regimes apply, the rights notice each requires, the verification method for a rights request, response deadlines, and whether an authorised-agent process is needed.
Security
Managed infrastructure, access control at the database, and a breach notice if it matters to you.
We take reasonable and appropriate measures to protect information against loss, misuse and unauthorised access. Access control is enforced at the database layer rather than only in the application, sign-in is passwordless by magic link, and Proposal documents are held in private storage reachable only through short-lived signed links.
If a security breach materially affects your information, we will notify you as soon as we can and report what we did in response.
Please do your part: keep access to your sign-in email secure, and tell us immediately if you think your account has been compromised.
Where we operate
United States.
Rbundle is operated from the United States and the data is stored there. If you use the Marketplace from elsewhere, you understand that your information will be transferred to, stored and processed in the United States, where data-protection law may differ from that of your own country.
Other sites, changes and contact
Our policy covers our site. We will post changes here.
The Marketplace links to sites we do not control. This policy does not apply to them; read theirs.
We may update this policy. The date at the top reflects the current version, and material changes take effect when posted.
Questions, complaints or requests: info@rbundle.com, or write to Rbundle, LLC, P.O. Box 1971, Apex, North Carolina 27502.