Privacy Policy

This Privacy Policy explains how Nordva (ENK, org.nr 938 478 473) (“we”, “us”, “our”) collects, uses, stores, and shares personal data when you use the Nordva Launch platform (the “Service”). We act as a data controller for your account data and as a data processor for content submitted by your End Users through your integration with the Service.

1. Data we collect

Account data (controller)

• Email address, name, and password hash, collected via Clerk when you sign up.
• Billing details: handled by Stripe, which acts as merchant of record for paid plans; we never see your card number. Stripe collects the name, email and billing address needed to calculate tax and issue receipts.
• Project metadata: project name, plan, API key fingerprints (hashed; we cannot recover the plaintext key).
• If you answer the questions at /grow/: the answers, which are multiple choice and describe your product rather than you, counted as you give them. An email address is required to see your plan, and is kept with those answers and your site or project name if you give it, which are stored on your contact in our own project, and the channel that brought you. We send you one email with a link to that plan, because it is the thing you asked for. Anything after that happens only if you tick the separate box, which also puts you on our own waitlist (it sends a receipt), and every email carries an unsubscribe link.
• If you download the Build with AI guide at /build-with-ai/pdf/: your answers to four short questions about what you are building, your site or project name if you choose to give it, and the email address you give. The guide is given in exchange for occasional email: the box that says so is required, and ticking it is recorded with the time. All of it is kept together on your contact in our own project, with the channel that brought you. We send you the PDF by email, put you on our own waitlist (it sends a receipt), and every email after that carries an unsubscribe link. Unsubscribing does not take the guide back.

Affiliate data (controller)

• If you apply to the affiliate program from the dashboard: the name you pick (it is public, in your link and your code), the name your page shows if you set one (public, on launch.nordva.dev/p/<your name>/), what you do, the links you give, your audience size range, a contact email, your payout method (PayPal or Wise) and payout email, and which version of the terms you accepted and when. We get an email with each application so we can review it.
• A ledger to pay you: which customers paid with your code, or signed up through your page or link and started paying within 12 months (as Stripe customer ids), what they paid before tax, your commission, refunds and chargebacks taken off, and the payouts we made. We also count sign-ups that arrived through your link.
• As an affiliate you see counts and amounts only, never who your customers are.

Usage data (controller)

• Request logs: timestamps, endpoints, status codes, IP addresses, user-agent strings. Retained ~30 days for abuse detection and debugging.
• Aggregated metrics: request counts per project per minute for rate-limit enforcement and usage reporting.
• Visits to nettsider.nordva.dev, the company's site for its website service: our own analytics in its strict cookieless form. The same page-view details as below are sent, and nothing is stored on or read from the visitor's device. A request sent through the form there is kept in our own project; that site's privacy page says what it holds.
• Visits to launch.nordva.dev and to the public demo at app.nordva.dev/demo/: our own analytics, in the same auto mode our customers can choose: the page path (no query string), the referring site's hostname, UTM values, window width, the city the request came from and the browser, system and device type. For visitors outside the EEA, the UK and Switzerland it also keeps a random visitor and session id in first-party cookies (see the Cookie Policy); inside them a small banner asks first, and nothing is kept unless the answer is yes. A browser sending Global Privacy Control is never asked and nothing is kept. No IP address or full user agent is stored. On a computer (not a phone), for a visit that may carry ids, we also keep a keyed one-way code made from the IP address, the full browser string and the browser language, so a browser that cleared its cookies is recognised for up to 30 days; the address itself is not kept and cannot be read back from the code. Individual events are kept 90 days. Customers' hosted /log/ and /waitlist/ pages are not counted, and neither is the signed-in dashboard, with one exception: when you create a Nordva Launch account, the dashboard sends one "signup" event to our own analytics, with how you found us and the visitor id our site's cookie already holds if your browser allowed one, and your account's email and id are added as a contact in our own Nordva Launch project, linked to those visits. After that, the first time each day you open the dashboard, it sends one "signin" event the same way, and that contact is updated with the date and the number of days you have signed in, linked to the device you used. Nothing about your projects is sent.
• Page loads on nordva.dev, launch.nordva.dev and nettsider.nordva.dev, measured by Cloudflare, which hosts them, with Cloudflare Web Analytics. On each page load its script (static.cloudflareinsights.com) sends Cloudflare the page address, the referring page, the browser string and how quickly the page loaded, and Cloudflare adds the country. Cloudflare states that it sets no cookie, stores nothing in your browser and does not fingerprint visitors. We see only totals: page views, sources, countries and page speed. The dashboard at app.nordva.dev is not measured this way.

Customer Data (processor)

Content you or your End Users submit through the Service. This includes:

• Waitlist signups: email address, optional referrer, IP address, timestamp, and an optional first-touch source: the hostname of the referring site, UTM parameters and the path of the page the form was on. The form itself uses no cookie or browser storage. When your site also runs the analytics script and may keep a visitor id, the signup carries that random id and the visitor’s first touch, so it can be linked to the visits before it.
• Web analytics events: only if you put the analytics script (e.nordva.dev/v1/s.js) on your site. For each page view, goal and engaged-time ping: the page path (no query string), the referring site’s hostname, UTM values, ref, whether an ad-click id was present (not its value), the window width, and any goal name and properties you send. We add the country, region and city the request came from, coordinates rounded to about 11 km, and the type of browser, system and device. Where your tracking mode and the visitor’s choice allow it (see the Cookie Policy): a random visitor id and session id from first-party cookies on your site, the page’s number in the session and whether the visitor is new. Never stored: the IP address (used in transit to limit abuse and to look up the country and city), the full user agent and full URLs. If you pass the script through your own server (a proxy), your server forwards the visitor’s IP address and location with each request, and we use those instead, in the same way. Events hold no name or email address. Where ids are allowed and the visitor is on a computer (not a phone), we keep a keyed one-way code made from the IP address, the full browser string and the browser language on the first page of each visit, for up to 30 days after it was last seen, so a browser that cleared its cookies gets its visitor id back. The code is different on every site, the address cannot be read back from it, and a code seen with two browsers that both kept their cookies is never used to match again. When a visitor id is linked to a person you already know (their waitlist signup, an identify call, or your Stripe or Lemon Squeezy checkout), you can see that person’s visits on their contact page. For a visitor who may carry an id, the script adds that id to links to your Lemon Squeezy checkout, so the purchase can be traced to the visit.
• Analytics identities: only if your site calls identify (in the page, or from your server after a signup or login): the visitor id linked to your own user id and, when you send one, the user’s email address, kept both as you sent it and as a SHA-256 hash of its normalised form, with the visitor’s first touch and any source label you name (such as “ios-app”). They let a payment be traced to the first visit, and they put that person on your Contacts list. An identify call, or a form marked for it, can also carry details you choose to record about that person (such as an answer to a question) and consents they gave you (such as to marketing email), with when and how; a form marked for it is recorded when the visitor submits it even if they have not allowed cookies, but then without a visitor id, so their visits are not linked to them; these are kept on their contact, and you can filter and export by them. Send no email and we keep none. Kept while the project exists; deleted with it.
• Page-view counts per source: only if you switch this on for a project. A daily total per referring site and campaign. It is not personal data: no IP address, user agent, cookie or identifier is stored with it, and there is no record per visitor.
• Channel costs: what you tell us a source or campaign cost, so the report can show cost per customer. About your business, not about a person.
• Feedback submissions: feedback text, optional email address (if the End User wants a reply), optional source URL, optional category (the type the End User picked, or a hint from your code), optional rating from 1 to 5, and, when sent by the feedback widget or the hosted feedback form, the browser name with its major version (such as "Safari 17") and the device type (desktop, mobile or tablet). The widget and the form work those two out in the End User's browser; the full user agent is never sent to us or stored with the feedback. The IP address is used only to limit abuse and is not stored with the feedback. Best-effort PII stripping is applied before AI classification but is not guaranteed. When you reply from the inbox, the text of your reply and when it was sent are kept with the feedback, and the reply is emailed once to the address the End User left.
• Connected Stripe data: if you connect your own Stripe account, read-only: your customers' email, name and Stripe ids, their subscriptions (status, plan, amount) and paid invoices (amount, date). Never card or bank details. The restricted key you provide is encrypted at rest. Disconnecting, or deleting the project, deletes the key and all of this data.
• Connected Lemon Squeezy data: if you connect a store of your own Lemon Squeezy account, which we only read: your customers' email, name, country and Lemon Squeezy ids, their subscriptions (status, product, price, dates), and their orders and subscription invoices (amount before tax, currency, date, refunds). Never card or bank details. If you set up its webhook, the visitor id your checkout carried, for the customer it belongs to; nothing else from the webhook is kept. The API key and the webhook signing secret are encrypted at rest. Disconnecting, or deleting the project, deletes both and all of this data.
• Contacts: not new data, but a combined view: one record per End User across the items above, matched on email address, plus an optional stage and free-text note that you write. A contact is deleted when the person no longer exists in any of those sources.
• Notifications: title, body, the user_id you supply (none for a message to everyone), optional action URL, buttons, category, a data object you choose, and when it is to show. For a message to a group, the user_id of each person in it. For a message to a group or to everyone, per person: when they read, clicked or archived it. For a message that takes reactions, per person who reacted: their user_id, which reaction and when. For each user_id your application asks about, when it first and last asked (updated at most once an hour). When you pick people by email or from Contacts, the email is used to find their user_id in what you already hold with us and is not stored with the notification. No email, IP address or user agent is stored with any of these.
• Feedback board (when you switch it on): each idea's title and text, its status and vote count; for an idea an End User suggested, the email they chose to leave (never shown on the board). Each vote is stored with a random id that the board page or widget makes in the voter's browser, or, when your site signs the user in, a one-way hash of your user id, and nothing else about them. The visitor's IP address is used to limit abuse and is not stored.
• Changelog entries: markdown content you author. Images in an entry are links to images you host: we never store, copy or proxy them, and End Users’ browsers fetch them straight from your host without a referrer.
• Changelog subscribers: email address and, if the End User picks topics, which of your labels they follow (the subscription and the label, nothing more). A subscription made in a browser gets one email asking the person to confirm it, and is deleted after 7 days if they do not.
• Changelog reactions and reading: for a reaction, the entry, which reaction and when, and who reacted as either the user_id you supply or a random id the changelog widget makes in the End User’s browser (it is made from nothing about the person). For an entry shown to a signed-in End User (a user_id your server signs), the entry, that user_id and when it was first shown, so read state follows them across devices. Reading without a user_id only adds to per-entry counts (views, readers, button clicks): nothing about the visitor is kept. Feedback sent from an entry keeps which entry it was about. No email, IP address or user agent is stored with any of these.

You are the controller of Customer Data. You determine what is collected from your End Users and are responsible for providing them with an appropriate privacy notice and lawful basis. Our processing of Customer Data on your behalf is governed by the Data Processing Agreement.

2. Why we process it

• To provide, operate, and maintain the Service (contractual necessity, Art. 6(1)(b) GDPR).
• To bill you and prevent fraud (legitimate interest, Art. 6(1)(f)).
• To run the affiliate program if you join it: review your application, create your code, count what you earn and pay you (contractual necessity), and keep the payment records the law requires (Art. 6(1)(c)).
• To detect, prevent, and respond to abuse, security incidents, and rate-limit violations (legitimate interest).
• To run AI classification on feedback content, when enabled by your plan (contractual necessity).
• To show you revenue, contacts and signup attribution from a Stripe account or Lemon Squeezy store you choose to connect. We only read from it; we never create, change or refund anything in it (contractual necessity).
• To send you the weekly summary email, or the monthly report on your website (taps on the phone number, contact forms sent, visits and top sources, in Norwegian or English), only if you switch it on or ask us to. Every such email has a one-click unsubscribe link (consent).
• To comply with legal obligations (Art. 6(1)(c)).
• To send transactional emails (account, billing, security). We do not send marketing emails without your consent.

3. Sub-processors

We use the following trusted sub-processors to operate the Service:

Your own Stripe account or Lemon Squeezy store is not one of our sub-processors. If you connect it, it is the source of that data under your own agreement with Stripe or Lemon Squeezy. We copy the data listed in section 1 into our database on Cloudflare and do not pass it to any other provider: it is not sent to Anthropic, and it is not included in feedback routing.

Standard Contractual Clauses (SCCs) or equivalent transfer mechanisms are in place for transfers outside the EEA where required. We give at least 14 days' notice before adding or replacing a sub-processor; see the Data Processing Agreement.

4. Cookies

We use only essential cookies, mainly the Clerk session cookie that keeps you logged in. We do not use cross-site tracking. The one outside analytics is Cloudflare Web Analytics on our websites, which sets no cookie (section 1). Our marketing site loads the Google Ads tag to learn which of our ads lead to a purchase: outside the EEA, the UK and Switzerland it may set Google’s first-party cookies, inside them it sets none (Google Consent Mode). In the app it reports only that the app was opened (once per session, never which page), that a checkout started with the plan's price, and after a purchase the amount, the currency and an order id, nothing about you. Details are in the Cookie Policy. The waitlist, feedback and notification embeds set no cookies on your End Users’ browsers, and the changelog widget keeps its read state in local storage (what the visitor has already seen, and, once they react to an entry, a random id for their reactions). The analytics script sets first-party cookies on your site only when your tracking mode allows it for a visitor, and in cookieless mode never one that holds an id. With data-cookieless on its tag it stores nothing in the visitor’s browser and reads nothing stored there. The full list is in the Cookie Policy.

5. Retention

• Account data: kept while your account is active; deleted within 30 days of account closure.
• Request logs: ~30 days.
• Notifications: deleted 90 days after they showed, with who read, clicked, archived or reacted to them. A user_id whose application has not asked for 90 days is deleted too.
• Feedback / waitlist / changelog: kept until you delete them. You control retention via the dashboard or API. Changelog reactions and read records are kept with the entry and deleted with the project; a subscriber’s label choices are deleted when they unsubscribe.
• Web analytics events: 90 days, then deleted automatically. They cannot be deleted one by one before that: they are stored for counting, not by person, and hold no name or email. A visitor can end their id at any time by clearing the site’s cookies. When a project is deleted, its events can no longer be read and expire within 90 days.
• Web analytics daily totals: each finished day is also summed into counts per day, page, source, place, device and goal, so history reaches past 90 days. They hold no visitor id, session, IP address or anything else about a person, are kept up to five years, and are deleted with the project. With the monthly report on, each reported month’s totals (visits and a count per goal) are kept 13 months, so the next report can compare with them.
• Connected Stripe and Lemon Squeezy data: kept while the connection exists and refreshed about hourly. Disconnecting, or deleting the project, deletes the stored key (and a Lemon Squeezy webhook secret) and every synced customer, subscription and payment immediately. Payments older than 24 months are never kept.
• Billing records: retained as required by tax and accounting law (typically 5 years).
• Affiliate data: kept while you are an affiliate. After you stop, the ledger and payout records (with your name and payout email) are retained as required by tax and accounting law (typically 5 years); the rest of your application is deleted on request.

6. Your rights

Subject to applicable law (GDPR, UK GDPR, CCPA), you have the right to:

• access the personal data we hold about you;
• request correction or deletion;
• export your data in a portable format;
• object to or restrict processing;
• withdraw consent (where processing relies on consent);
• lodge a complaint with a supervisory authority (in Norway: Datatilsynet).

To exercise these rights, email hello@nordva.dev. We will respond within 30 days. For requests about Customer Data (End-User submissions), contact the relevant Customer; we will assist as your data processor.

7. Security

We protect data with TLS in transit, encryption at rest where supported by Cloudflare D1, bcrypt-hashed API keys, AES-256-GCM encryption for routing-destination credentials and for any Stripe restricted key or Lemon Squeezy API key you connect (which is never shown again, returned by the API or written to logs), read-only access to connected Stripe accounts and Lemon Squeezy stores enforced in code, role-scoped access, and Turnstile / rate-limiting on public endpoints. No system is 100% secure. If we become aware of a breach affecting your personal data, we will notify you and applicable authorities within 72 hours where required by law.

8. International transfers

Cloudflare’s edge network and several sub-processors operate outside the EEA. Where personal data is transferred to a non-adequate country, we rely on Standard Contractual Clauses and supplementary measures.

9. Children

The Service is not directed at children under 16. We do not knowingly collect personal data from children. If you believe a child has provided us data, contact us and we will delete it.

10. Changes

We may update this Privacy Policy as the Service evolves. Material changes will be announced via email or in-product notice at least 14 days in advance.

11. Contact

Data controller: Nordva (ENK, org.nr 938 478 473), governed by the laws of Norway.
Email: hello@nordva.dev