DRAFT: not legal advice. This document has not been reviewed by a lawyer and must be reviewed before any paid customer is onboarded.
Last drafted: October 13, 2026
Privacy Policy
Last drafted: October 13, 2026. Not yet in force until reviewed and adopted.
This policy explains what personal data Shelfprice handles about the people who visit the website and use the product, why, who sees it, how long we keep it, and your rights. It follows the UK GDPR and the Data Protection Act 2018. The retail price data we analyze is not personal data.
1. Who we are
Shelfprice is operated by [COMPANY NAME LTD], a company registered in England and Wales, company number [COMPANY NUMBER], registered office [REGISTERED ADDRESS] (“Shelfprice”, “we”, “us”). We are registered with the UK Information Commissioner’s Office (ICO), registration number [ICO REGISTRATION NUMBER].
Shelfprice is a business tool: it analyzes the prices and pack sizes on a US retailer’s shelf for the teams who sell to that retailer. This policy explains what personal data we handle about the people who visit our website and use the product, why, and what rights you have under the UK GDPR and the Data Protection Act 2018. Contact us about any of it at [CONTACT / DPO EMAIL].
Our two roles
- Controller. For the data we use for our own purposes (signing you in and keeping the service secure, billing, our legal obligations, support records, and improving the product) we decide how and why, so we are the controller. Most of this policy is about that data.
- Processor. A customer organization’s workspace also holds personal data about the organization’s own people and contacts: the member list, notes on an opportunity, who it is assigned to, who receives an email. The organization decides what goes in and why, so for that data we act only on the organization’s instructions as its processor, under our Data Processing Addendum. If you work for a customer and want to see or change that data, ask your organization first.
For the reviewer: The split between controller and processor is a judgment call (see open points 1 and 2). Confirm it, and confirm whether the company must pay the ICO data protection fee.
2. The data we handle
We handle the following personal data. We do not collect special category data (health, beliefs and similar) or data about children.
| Data | What it includes | Where it comes from |
|---|---|---|
| Identity and account | Name, work email address, password (stored only as a one-way hash, if you set one), organization name, role in the organization (owner or member), the time you were verified | You, or your organization's owner who invited you |
| Sign-in | A one-time sign-in link (stored only as a hash, removed when used), a signed session token in your browser | Generated when you sign in |
| Workspace content | Notes you write on an opportunity, who an opportunity is assigned to, saved segments and competitive sets, brands you track, alert rules, scheduled export settings and recipients, weekly brief and email preferences, the opportunities you last viewed | You and your teammates |
| Support access log | When Shelfprice staff opened your workspace read-only for support, why, and the pages they opened | Generated by our systems |
| Technical and usage logs | IP address, date and time, page requested, browser type, error details, kept in server logs by our host | Your browser |
| Billing | Plan, trial end date, subscription status and the Stripe customer and subscription ids; the billing contact, invoices and payment history are held by Stripe (card details go to Stripe, never to us) | You |
| Correspondence | Messages you send us for support or about your privacy rights | You |
Data that is not personal data
The retail data at the heart of Shelfprice (product names, sizes, brands and shelf prices at US stores, collected from Kroger’s public API) describes products and prices, not people. It is not personal data and this policy does not cover it. We keep the daily price rows for 90 days, then roll them into weekly summaries (section 7).
People who did not sign up themselves
A workspace owner can invite a teammate by typing their work email address. We then email that address, saying who invited them and to which workspace, with a one-time sign-in link that expires after seven days. The person joins the workspace only when they use the link; until then we keep the invitation (the address, who invited them and when) and nothing else. They are told about this policy in that email and when they sign in. If you think your address was used in error, ignore the email or contact us at [CONTACT / DPO EMAIL] and we will remove the invitation.
3. Why we use it, and our lawful basis
UK law requires a lawful basis for every use of personal data. Ours are:
| What we do | Lawful basis |
|---|---|
| Create and run your account; sign you in; give you and your team the workspace, alerts, exports and weekly brief you or your organization set up. | Contract (Article 6(1)(b)) where you are the customer. Where your employer is the customer, legitimate interests (Article 6(1)(f)): you and we both have an interest in the service your employer bought working for you. |
| Send service emails: sign-in links, notices that an opportunity was assigned to you, and the alerts, scheduled exports and weekly brief that you or your organization turned on. | Contract, or legitimate interests as above. Each recurring email carries an unsubscribe link (section 11). Sign-in links are not optional because you cannot sign in without them. |
| Keep the service secure and working: server logs, preventing misuse, fixing faults, backups. | Legitimate interests: running a secure service. |
| Give support: respond to your messages; where needed, view a customer's workspace read-only to see what the customer sees (section 6). | Legitimate interests (helping customers); contract. |
| Understand how the product is used, in aggregate, so we can improve it. We use no third-party analytics or advertising tools. | Legitimate interests: improving the product. |
| Bill customers, keep accounting and tax records, answer legal or regulatory requests. | Contract and legal obligation (Article 6(1)(c)). |
| Establish, exercise or defend legal claims. | Legitimate interests. |
| Marketing emails. We do not send marketing emails today. If we start, we will send them only where you have consented or where the rules allow us to write to an existing business customer about similar services, and every one will say how to stop. | Consent (Article 6(1)(a)), or legitimate interests where the UK rules on electronic marketing allow it. |
Where we rely on legitimate interests, we have weighed them against your rights and expect the effect on you to be small. You can object (section 9). We do not sell personal data, we do not share it for advertising, and we make no decisions about you by automated means that have legal or similarly significant effects.
5. Transfers outside the UK
We are in the United Kingdom, and the providers above process data in the United States. A transfer to the US is lawful under UK GDPR where one of these applies, and we use whichever fits each provider:
- the UK-US data bridge (the UK extension to the EU-US Data Privacy Framework), where the provider is certified to it;
- otherwise the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU standard contractual clauses, together with a check that the protection is adequate in practice.
You can ask us for a copy of the safeguards for a transfer at [CONTACT / DPO EMAIL]. Our hosting region is [HOSTING REGION].
For the reviewer: The code does not say which region the host runs in or whether Railway and Resend are certified under the data bridge. Confirm both and attach the signed provider terms (open point 4).
6. Staff access to workspaces
A small number of Shelfprice staff hold a platform role that lets them see any workspace. They use it to give support and to run the service. When staff view a customer workspace as that customer sees it, the product is read-only for them (they cannot change anything), a banner shows it, and the session is logged: who, which organization, why, when, and every page opened. The log is part of the workspace’s data and is available to the organization on request.
7. How long we keep it
| Data | How long |
|---|---|
| Daily price rows (not personal data) | 90 days, then rolled into weekly summaries by a job that runs every week. A second pull on the same day replaces that day's row. |
| Weekly price summaries (not personal data) | Kept, with no end date. They hold prices and counts only. |
| Account and workspace data | For as long as the account is open, then deleted or anonymized within [ACCOUNT RETENTION PERIOD]. |
| Sign-in links | Valid for 24 hours and usable once. Only a one-way hash of the link is stored. |
| Support access log | For as long as the customer organization's account is open. |
| Server logs | [LOG RETENTION PERIOD], set by our host. |
| Backups | Deleted data can remain in backups for up to [BACKUP RETENTION PERIOD], and is not used for anything while it is there. |
| Billing and accounting records | Six years from the end of the financial year they relate to, as UK tax and company law require. |
| Messages you send us | As long as the account is open, then [ACCOUNT RETENTION PERIOD]. |
When a customer ends its subscription we delete or return its workspace data as the Terms of Service describe.
For the reviewer: The retention periods in brackets are the owner’s decision. Today there is no self-service delete in the product; deletion on request is done by hand (open point 6).
8. How we protect it
This is what the product does today. We describe only what exists.
- The website and app are served over HTTPS. Our application reaches its database over our host’s private network.
- Passwords are stored only as one-way bcrypt hashes. Sign-in links are single-use, expire in 24 hours, and are stored only as hashes. Sessions are signed and encrypted tokens held in a cookie that scripts on the page cannot read.
- Every request, whether a page, an export, an action or a scheduled email, is checked on the server for who you are and what your organization has paid for. A customer sees only its own workspace and only the categories it is entitled to. Only a workspace owner can invite or remove teammates.
- Staff access to customer workspaces is read-only and logged (section 6). The staff role is set on the server, never by anything a browser sends.
- Scheduled jobs call our server with a secret key; secrets are kept in environment settings, not in our code. The development database is separate from production.
We have not been independently audited or certified (for example SOC 2 or ISO 27001), and we do not yet offer two-factor sign-in. No system is perfectly secure. If a breach affects your personal data we will tell you and the ICO as the law requires.
9. Your rights
Under UK GDPR you have the right to:
- be told how your data is used (this policy);
- get a copy of your data (access);
- have wrong data corrected (rectification);
- have your data erased, where there is no good reason for us to keep it (erasure);
- restrict how we use it while a dispute is settled;
- receive the data you gave us in a common machine-readable format, where we use it under contract or consent (portability);
- object to use based on legitimate interests, and to any marketing, at any time;
- withdraw consent, where we rely on it, without affecting what we did before.
To use a right, email [CONTACT / DPO EMAIL]. We reply within one month, it is free, and we may ask you to prove who you are. If your request concerns content in your employer’s workspace, we may refer you to your employer, who decides about that content.
You can complain to the UK Information Commissioner’s Office (ico.org.uk, 0303 123 1113). We would like the chance to put things right first, so please contact us.
If you are in the United States or the EU
You have the rights above to the extent the law of your place gives them to you. For US state privacy laws, we do not sell personal data or share it for cross-context behavioral advertising. If we are required to appoint a representative in the EU or UK for this purpose, it is [EU/UK REPRESENTATIVE, IF REQUIRED].
11. Email preferences
We send three kinds of email.
- Sign-in links and security messages. Needed to use the service. You cannot turn these off while you have an account.
- Assignment notices. Sent when a teammate assigns an opportunity to you.
- Alerts, scheduled exports and the weekly brief. Sent only because you or your organization set them up. Each one has an unsubscribe link that works without signing in, and you can switch each kind off under Settings, Emails. Opting out stops the emails and nothing else: the alert rules and exports stay in the workspace.
We do not send marketing email today (section 3).
12. Billing data
New workspaces get a free trial of 10 days, after which a paid plan is needed. We hold the plan, the trial end date, the subscription status and the Stripe customer and subscription ids in the product’s database. Card details are collected and held by our payment processor, Stripe, never by us, and Stripe also holds the billing contact, invoices and payment history; it is named in section 4.
13. Children
Shelfprice is for businesses. It is not directed at anyone under 18, and we do not knowingly collect data about children. If you think a child’s data reached us, contact [CONTACT / DPO EMAIL] and we will delete it.
14. Changes to this policy
We may update this policy. The date at the top says when it was last drafted. For a material change we will email the owner of each workspace at least [NOTICE PERIOD DAYS] days before it applies, and will not use data for a new purpose without a lawful basis for it.
15. Contact
Privacy questions and rights requests: [CONTACT / DPO EMAIL].
[COMPANY NAME LTD], company number [COMPANY NUMBER], registered office [REGISTERED ADDRESS].
Open points for the reviewer
This draft was written by an AI model from the product’s code and the owner’s instructions, not by a lawyer. These are the judgment calls it made and the facts it could not know. Each one needs a decision or a check before any paid customer is onboarded. Delete this section only when a qualified lawyer has reviewed and adopted the document.
- Controller or processor. I split it: the customer is the controller, and we the processor, for personal data about its own people in the workspace (member list, notes, assignments, email recipients, saved settings); we are a controller only for our own purposes (sign-in and security, billing, legal duties, support records, product improvement). This matches the DPA. The usual alternative is to treat account data as ours alone. Confirm the split.
- Company facts. The company name, number, registered office, contact and DPO address, ICO registration number (and whether the ICO fee applies), and any EU/UK representative are all placeholders. I did not guess any of them. The old page named privacy@ and legal@ shelfprice.com addresses; I removed them because I cannot tell whether those mailboxes exist.
- Lawful bases. For people whose employer is the customer I chose legitimate interests, with contract where the person is the customer (sole traders, the owner who signs up). Check this, and the statements about the UK rules on electronic marketing (a business-to-business soft opt-in).
- Transfers. The code does not show the hosting region ([HOSTING REGION]) or whether Railway and Resend are certified under the UK-US data bridge. I named the bridge, then the IDTA or UK Addendum as the fallback. Confirm which applies, and sign each provider’s own data processing terms.
- Billing and payment processor. Stripe is built in, in test mode only (src/lib/billing). I added it to the sub-processor lists and Annex C of the DPA and described it in sections 4 and 12 as if live. Confirm the entity (Stripe, Inc. or a regional one), sign Stripe’s data processing terms, and check the transfer wording, before the owner switches live charging on.
- Retention and deletion. I stated the 90-day and weekly price rule from the code. Account retention, log retention and backup retention are placeholders. Six years for billing records is my assumption from UK tax and company rules. There is no self-service account deletion: erasure is done by hand, and removing a member from a workspace deletes the membership but leaves that person’s user record. Unused sign-in links have no clean-up job that I could find. Decide and build, or say so.
- The old Neon database. Production moved from Neon to Railway Postgres on October 6, 2026 (DECISIONS.md). The old Neon copy is stale but still holds accounts as they were then, and nothing has been deleted. Delete it before publishing, or add Neon to the sub-processor lists.
- Logs. If the email key (RESEND_API_KEY) is not set in production, the email helper prints each message, including sign-in links, into the server log. Confirm the key is set. Confirm what Railway logs about visitors and for how long.
- Email opt-out. Section 11 describes the unsubscribe link and the Settings toggles being built in the same release. Confirm they have shipped before this goes live. Also note the weekly brief row in the database defaults to on, although the code comment calls it opt-in; confirm the intended default. The default sender is the onboarding mailbox on the shelfprice.dev domain; confirm the real sending domain.
- Cookies. I treated the preference cookies (brand, store and so on) as exempt from consent because you asked for the function by choosing the value, and so show no banner. A cautious reviewer may want a notice. Confirm.
- Security statements. I described only what the code does. Things the code does not have, and I did not claim: two-factor sign-in, rate limiting of sign-in attempts, third-party certification or testing, an audit log beyond staff support sessions, and any statement about encryption at rest (that depends on the host). Confirm the host’s backups and encryption.
- Anthropic. The owner’s brief said product descriptions are sent. The code sends only a category and a brand name, and turns on the model’s web search. I wrote what the code does. Confirm the account’s data-retention settings with Anthropic, and re-check this section whenever the classifier changes.
- Staff access. Support access is read-only and logged, and the policy says so. Confirm who holds the platform role (today the ADMIN_EMAILS allowlist or a database role) and that this is acceptable to customers. The policy promises the support log is available to the customer on request; confirm that is workable. Consider telling a customer when its workspace was opened.
- Invited teammates. The invite now emails the person (who invited them, which workspace, a one-time link) and creates no membership until they use it. I said so in section 3. Confirm the seven-day expiry and that an invitation record kept until then is acceptable.
- US and EU rules. I added a short paragraph on US state privacy law and a placeholder for an EU/UK representative. Confirm whether either is needed given where customers and users are.