LEGAL

Privacy Policy

Last updated: 2026-11-07

1. Who is responsible for your data

This website (https://make1day-saas-template.vercel.app) is operated by make1day, the data controller for the processing described below. Questions and requests can be sent to [email protected].

Scope matters here. This policy covers only this website and the service that generates a project ZIP for you. Once you download a generated project and deploy it, you become the data controller for that deployment and must publish your own privacy notice — we have no access to the data your deployment collects. The generated project deliberately ships a placeholder privacy page instead of this policy for that reason.

2. What we collect, and where it actually goes

The original version of this page claimed that preferences never leave your browser and that account data lives only in your own Supabase project. Both statements were wrong. This is the real data map, derived from the code and database schema:

  • Browser-only (never sent to our servers): language, theme (sk_theme) and your cookie-consent choice (sk_cookie_consent), all in localStorage.
  • First-party cookies: sk_vid (random visitor id, up to 365 days) and sk_sid (session id, 30 minutes), both httpOnly and SameSite=Lax. They are set only after you accept analytics cookies.
  • First-party analytics: after consent, /api/track records page views, CTA clicks, checkout starts and conversions with the visitor/session ids, path, CTA label, the host of the referrer and a timestamp. These go into the pageviews and traffic_events tables. A checkout or conversion event also stores your email so a paid order can be attributed to the session.
  • Account & profile: email, role, display/full name, company, an scrypt password hash and salt (local-auth mode only), email-verification state and timestamps (profiles). Operator accounts are stored in admin_users and their signed sessions in admin_sessions. When Supabase Auth is configured, authentication data is held by Supabase instead.
  • Purchases & licensing: buyer email, plan, gateway order id, amount, currency and status (orders); the issued key, its id, plan and validity (licenses); and gateway event ids used for webhook deduplication (webhook_events). We never receive or store card numbers — payment details are entered on the payment provider's hosted checkout.
  • Support requests: email, subject, message, status and optional account id (support_tickets).
  • Abuse prevention & quotas: a hashed network key plus a daily counter (quota, for anonymous preview limits) and a per-user daily AI message counter (ai_usage). We do not store raw IP addresses in our application tables, though our hosting provider may log them under its own policy.
  • Password reset / email verification: only a SHA-256 hash of the one-time token, the email and an expiry (password_resets, email_verifications). The raw token exists only inside the email link.
  • Delivery, consent & error audit: a hashed buyer email and license id with an event kind — ZIP download, key redemption, key email or key re-send — and a timestamp (delivery_events); consent accept / withdraw / policy-view / export / erase events with a hashed subject (consent_events); and server error level, message and structured context (error_events). None of these store an IP address or user agent.
  • Transactional email retry: if a key or account email fails to send, the recipient, subject and message body are held in mail_outbox until a scheduled retry succeeds. Delivered or dead rows are deleted by the retention job; pending mail is never purged automatically.
  • Sign-in sessions & rate limits: local password sign-in stores only a hash of the session token, your email and an expiry (local_sessions). API abuse limits keep a hashed bucket key, a counter and a window (rate_limits).
  • AI & RAG content: chat messages are sent to the AI provider you configure and are not written to our application database. Documents you ingest for RAG are stored in the configured vector store. Do not submit personal data you do not want those providers to process.

3. Where data is stored

With no database credentials configured, all of the tables above live in a local SQLite file (.data/shipkit.db) on the server running this site — not in your own Supabase project. When SUPABASE_SERVICE_ROLE_KEY is set, the same records are written to the operator's Supabase project instead. The two backends are selected by configuration; the data categories do not change.

4. Cookies, consent and third-party analytics

Strictly necessary storage is limited to the preference keys above. Analytics cookies, the first-party tracker and Google Analytics 4 are loaded only after you accept the consent banner. GA4 is inactive unless NEXT_PUBLIC_GA_ID is configured, and is loaded with IP anonymisation enabled. Withdrawing consent stops future tracking; you can also clear the two analytics cookies in your browser. Consent decisions, policy views and data-rights requests are additionally recorded server-side in an append-only log keyed by a hashed subject, so we can evidence them without storing another copy of your address. No advertising or cross-site tracking pixels are used.

5. Why we process it

  • Contract: creating accounts, taking payment, issuing a license key, generating and delivering your project, and replying to support tickets.
  • Consent: first-party funnel analytics and Google Analytics.
  • Legitimate interests: abuse prevention, rate/preview quotas, webhook deduplication, security logging and understanding which pages convert.
  • Legal obligations: retaining order records for accounting and tax purposes. Where a payment provider acts as Merchant of Record, it holds the tax records under its own policy.

6. Who else receives data

Only the services the operator actually configures are involved. Depending on that configuration, personal data may be processed by:

  • Payments: one of Stripe, Creem, PayPal, Waffo (Pancake or Acquiring) or Lemon Squeezy — buyer email, order metadata and webhook payloads.
  • Database / auth: Supabase, when a service-role key is configured; otherwise data stays on the site's own server.
  • AI: OpenAI, Anthropic, Google Gemini, OpenRouter, DeepSeek or Groq — chat prompts and RAG content only for the provider in use.
  • Email: Resend or a custom HTTP mailer — recipient address and transactional message content. With MAIL_PROVIDER=none no mail is sent at all.
  • Analytics: Google Analytics 4, only if configured and only after consent.
  • Error reporting: an optional external sink (ERROR_REPORT_URL) receives error messages and structured context only — never analytics identities. If unset, errors stay on our own server.
  • Hosting: whichever platform runs this site; it may keep access logs under its own policy.

We do not sell personal data and do not use it for advertising profiles.

7. International transfers & data processing agreements

The providers above may process data in the United States, the EU or other jurisdictions, so transfers outside your country of residence can occur. It is the operator's responsibility to put the appropriate data processing agreements and transfer safeguards in place with those providers before launch. The repository contains a fill-in DPA template for that purpose; it is not a signed agreement and not legal advice.

8. Retention and deletion

Order and license records are kept while the license is valid and for as long as accounting or tax rules require. An automated retention job (/api/cron/retention, protected by a secret and invoked by our hosting scheduler) deletes analytics, consent, delivery and error events, expired one-time tokens and sessions, old quota / rate-limit buckets and delivered outbox mail after a default of 90 days. It is a job endpoint, not a built-in timer: if the scheduler is not configured for a deployment, those rows are retained until it is. Pending mail is never deleted by the job, because a customer may still be waiting for their license key. Account and support rows are kept until you ask us to remove them or until your data-rights request is processed. One-time reset and verification tokens are deleted on first use or at expiry.

9. Your rights

Depending on your jurisdiction (GDPR, CCPA/CPRA and similar), you may request access to, correction of, export of or deletion of your personal data, object to processing based on legitimate interests, and withdraw analytics consent at any time. Signed-in users can export their data directly from /api/privacy/export (a JSON file) and request erasure from /api/privacy/erase, which requires an exact confirmation of the account email. Erasure keeps the order and license rows required for accounting and for a key you already own, replacing the address with an irreversible tombstone. Otherwise write to [email protected] and we will verify the request before acting on it. Clearing browser storage removes only your local preferences and consent choice — it does not delete server-side records, which must be requested through the address above.

10. Security

Passwords are stored as scrypt hashes with a per-account salt, license keys are HMAC-signed, webhook signatures are verified with constant-time comparisons, one-time tokens are stored only as hashes, and analytics cookies are httpOnly. No method of transmission or storage is perfectly secure, so we cannot guarantee absolute security.

11. Children

This site is aimed at software developers and is not intended for anyone under 16. We do not knowingly collect personal data from children.

12. Changes

We may update this policy as the product changes. Material changes are reflected by the “Last updated” date above and, where appropriate, by a notice on the site.

13. Contact

Data controller: make1day.
Privacy requests: [email protected].
Site: https://make1day-saas-template.vercel.app.

← Back home

Privacy Policy · make1day