DEV Community: Daiva McLean

Do I Need a Cookie Policy for My App? (Probably Yes)

Daiva McLean — Sun, 17 May 2026 14:20:47 +0000

It's one of the most common questions from app builders and indie founders: do I actually need a cookie policy?

The short answer is: if your app uses cookies — and most apps do — then yes, you are legally required to tell your users about it.

Here's the longer answer.

What Are Cookies, Really?

Cookies are small files stored on a user's device when they visit your site or use your app. They're used for all kinds of things:

Keeping users logged in between sessions
Remembering preferences
Processing payments (Stripe uses cookies)
Tracking user behaviour (Google Analytics, Mixpanel, Hotjar)
Fraud prevention

Even if you haven't deliberately "added cookies" to your app, if you use any third-party tool — a payment processor, an analytics platform, a customer support widget — that tool is almost certainly setting cookies.

When Is a Cookie Policy Required?

Under UK law (the Privacy and Electronic Communications Regulations — PECR) and EU law (the ePrivacy Directive), a cookie policy is required when your app or website:

Sets non-essential cookies on user devices
Uses analytics tools (Google Analytics, Plausible, Fathom)
Uses advertising or retargeting tools
Embeds third-party widgets (Intercom, Crisp, Stripe)
Uses session management cookies

The only apps that might genuinely not need a cookie policy are those with no third-party tools, no analytics, and no session management. In practice, that's almost nothing.

What's the Difference Between a Cookie Policy and a Privacy Policy?

A privacy policy covers all personal data — how you collect it, use it, store it, and share it.

A cookie policy focuses specifically on cookies — what types you use, why, and how users can control them.

You need both. Some businesses combine them into one document. Others keep them separate. Either approach works, but keeping them separate makes it easier for users to find the specific information they're looking for.

What Your Cookie Policy Needs to Cover

A complete cookie policy for an app or website should include:

1. What cookies you use
List each cookie or category of cookie. Essential cookies, analytics cookies, payment cookies, preference cookies.

2. Why you use them
Explain the purpose of each type. "We use analytics cookies to understand how visitors use our site" is clear and acceptable.

3. Which third parties set cookies
If Stripe sets a cookie, your policy needs to say so. If Google Analytics sets cookies, name it. Users have the right to know.

4. How long cookies last
Session cookies expire when the browser closes. Persistent cookies last longer — your policy should state how long.

5. How users can control cookies
Explain how to accept, decline, or delete cookies through browser settings. Provide links to instructions for major browsers.

Does My App Store App Need a Cookie Policy?

If your mobile app uses a web view, third-party SDKs, or analytics tools — yes. Apple and Google both require apps in their stores to publish a privacy policy, and a cookie policy should be part of your broader privacy documentation if your app uses tracking tools.

Apple in particular has become increasingly strict about data transparency. Not having a clear data practices policy can result in your app being rejected from the App Store or removed after review.

Getting Your Cookie Policy Right

A cookie policy needs to accurately reflect the cookies your specific app uses. A generic template that lists placeholder cookie names is not compliant and will not satisfy a regulator or a suspicious enterprise customer doing due diligence.

InkTerms generates a personalised cookie policy based on your answers to a short questionnaire. You tell us what your app does, what tools you use, and where your users are based. We generate a complete, accurate cookie policy you can publish immediately.

From £9. Ready in minutes.

Generate your cookie policy →

InkTerms provides AI-assisted document generation and is not a substitute for professional legal advice. We recommend reviewing any generated document with a qualified legal professional before relying on it for your business.

Originally published on InkTerms Blog

How to Add a Privacy Policy to Your Shopify Store

Daiva McLean — Sun, 17 May 2026 14:10:47 +0000

Shopify has built-in fields for your legal policies. Here's exactly how to add your privacy policy, where it shows up, and what else you need to do to stay compliant.

Step 1: Go to Settings → Policies in Shopify

Log in to your Shopify admin
Click Settings (bottom left)
Click Policies

You'll see four policy fields:

Refund policy
Privacy policy
Terms of service
Shipping policy

Step 2: Paste your privacy policy

Click into the Privacy policy field and paste your policy text. Shopify accepts plain text or HTML — if your policy is formatted with headings and bullet points, HTML will preserve the formatting.

Don't use Shopify's auto-generator without reviewing it. Shopify generates a basic template when you click "Create from template," but it's generic and may not accurately reflect your store's actual data practices. A policy that doesn't match what your store actually does is worse than a generic one — it's actively misleading.

Step 3: Save

Click Save at the bottom of the page. Shopify will automatically create a page at /policies/privacy-policy for your store.

Step 4: Add it to your footer

Your privacy policy won't appear in your footer automatically — you need to add it as a navigation link.

Go to Online Store → Navigation
Click Footer menu (or whatever your footer navigation is called)
Click Add menu item
Name it "Privacy Policy"
Link type: Policies → Privacy policy
Click Add then Save menu

Do the same for your Terms of Service, Refund Policy, and Cookie Policy.

Step 5: Add it to your checkout

Shopify lets you display policy links at checkout — this is important for consumer rights compliance.

Go to Settings → Checkout
Scroll to the Policies section
You'll see links for Refund policy, Privacy policy, and Terms of service
These are automatically pulled from your Settings → Policies content once it's saved

Customers will see links to your policies at the bottom of the checkout page.

Step 6: Cookie consent banner

Shopify doesn't add a cookie consent banner by default. You need one under UK PECR if your store uses:

Google Analytics
Facebook/Meta Pixel
TikTok Pixel
Klaviyo or other marketing tools
Any retargeting or advertising tags

Options:

Shopify's native privacy banner (limited, available in some markets)
A cookie consent app from the Shopify App Store (Pandectes, CookieYes, Consentmo)

Your cookie consent banner needs to allow users to accept or decline non-essential cookies before they're set.

What else does a UK Shopify store legally need?

Beyond a privacy policy:

Refund Policy — legally required under UK Consumer Contracts Regulations (14-day return right for physical goods)
Terms and Conditions — strongly recommended; defines your relationship with buyers
Cookie Policy — required if using any analytics or marketing tags

Checklist

[ ] Privacy policy written and accurate to your store
[ ] Pasted into Shopify Settings → Policies
[ ] Added to footer navigation
[ ] Refund policy in place
[ ] Terms and conditions in place
[ ] Cookie consent banner active

Generate your Shopify store documents

InkTerms creates personalised privacy policies, terms and conditions, refund policies, and cookie policies for UK Shopify stores — tailored to your products, integrations, and data practices.

Generate My Store Documents →

Originally published on InkTerms Blog

How to Write Terms and Conditions for a SaaS Product

Daiva McLean — Sun, 17 May 2026 14:05:35 +0000

SaaS terms of service are different from a generic website's terms. You're running an ongoing commercial relationship with recurring payments, account-based access, and software that people may depend on for their work.

Here's what yours needs to cover and why each clause matters.

1. What your service actually is

Start by defining the product. This sounds obvious, but a vague definition creates problems when users claim your software should do something it doesn't.

Include:

A brief description of what the software does
What it explicitly does not do (e.g., "not a substitute for professional legal/financial/medical advice")
That you may update features over time

2. Account creation and eligibility

Who can create an account?

Minimum age (typically 18 for a paid product, or 13 with parental consent)
Whether business accounts and personal accounts are treated differently
User responsibility for keeping login credentials secure
That one account = one person or organisation (not to be shared unless you offer team plans)

3. Subscription, billing, and payment

This is where disputes most often arise. Be explicit:

Billing cycle (monthly/annual)
Auto-renewal — state clearly that subscriptions renew automatically
How to cancel (and by when, to avoid the next billing cycle)
What happens when payment fails (grace period, account suspension, data retention)
Price changes — your right to change pricing and the notice period you'll give

4. Refund policy

State your refund policy in the terms — and make sure it's consistent with your separate refund policy page.

UK consumer law gives a 14-day right to cancel for digital services, but this can be waived if the user explicitly consents to immediate access and acknowledges the loss of cancellation right. For SaaS, many businesses offer "cancel anytime, no refund for the current period" — that's fine, but it must be stated.

5. Acceptable use

Define what users can and can't do with your software:

Prohibited uses typically include:

Using the product to do anything illegal
Attempting to scrape, reverse engineer, or extract the underlying code
Reselling or sublicensing access without permission
Sending spam or conducting fraud through the platform
Uploading content that is illegal, harmful, or infringing

This protects you if a user misuses your platform and you need to terminate their account.

6. Intellectual property

Two directions:

Your IP: You own the software. Users get a limited, non-exclusive licence to use it. They can't copy it, resell it, or build on it without permission.

Their IP: If users upload content or create data in your platform, they own it. You have a licence to process it to deliver the service, but it's not yours.

This distinction matters — if a user asks for their data, your terms should confirm it belongs to them.

7. Service availability and disclaimers

Unless you're offering an SLA, you need a clause disclaiming guaranteed uptime:

The service is provided "as is" and "as available"
You don't guarantee it will be error-free or uninterrupted
You may take it offline for maintenance

This protects you from claims if your infrastructure has downtime.

8. Limitation of liability

Cap what you can be held liable for. Typically:

Your total liability is limited to the amount the user paid in the last 12 months
You're not liable for indirect, consequential, or lost profit damages

Without this clause, a business user who claims your SaaS caused them financial loss could theoretically sue you for far more than your ARR.

9. Account termination

You need the right to suspend or terminate accounts:

For violating the acceptable use policy
For non-payment
At your discretion, with reasonable notice

Also state what happens to user data after termination — how long you hold it and how they can export it.

10. Governing law and disputes

State which country's law governs the agreement and where disputes are resolved. For UK-based SaaS: typically England and Wales.

Generate your SaaS terms and conditions

InkTerms creates personalised terms of service for SaaS products — covering subscriptions, acceptable use, liability limits, IP, termination, and jurisdiction — tailored to your specific product.

Generate My SaaS Terms →

Originally published on InkTerms Blog

How to Write a Privacy Policy for a Mobile App

Daiva McLean — Sun, 17 May 2026 14:00:24 +0000

Mobile apps have a few extra requirements that a standard website privacy policy doesn't cover. If you're launching on iOS or Android, here's exactly what your policy needs.

Why mobile apps are different

When someone installs your app, you gain access to things a website can't touch:

The device itself (model, OS version, unique identifiers)
Push notification permissions
Camera, microphone, location (if requested)
Health and fitness data (if integrated with Apple Health / Google Fit)
Contacts (if the app accesses them)
Background data collection (if applicable)

Each of these needs to be disclosed.

What your mobile app privacy policy must cover

1. Device data and identifiers

Your app collects device identifiers automatically. At minimum: device model, OS version, app version. Often also: advertising identifier (IDFA on iOS, GAID on Android).

Your privacy policy needs to:

List what device data you collect
State whether you use advertising identifiers
Explain how to opt out of ad tracking (required by Apple's App Tracking Transparency rules)

2. Permissions you request

Every permission your app requests — camera, location, microphone, contacts — needs a corresponding entry in your privacy policy explaining why you need it and what you do with that data.

If your privacy policy says you don't collect location data but your app requests location permission, the app stores will flag this. Apple's review process checks for this discrepancy.

3. Push notifications

If you send push notifications, your privacy policy needs to mention this and explain what type of notifications you send (marketing, transactional, reminders).

4. In-app purchases and payment data

If your app uses Apple's in-app purchase or Google Play Billing, Apple and Google process the payment — you don't receive card details. But you do receive transaction records and should disclose this.

5. Analytics SDKs

Most mobile apps include at least one analytics SDK — Firebase Analytics, Mixpanel, Amplitude, Adjust. Each one that processes personal data needs to be disclosed as a third-party processor in your privacy policy.

6. Third-party SDKs generally

SDKs collect data independently. Before you ship, list every SDK in your app and check what data it collects. Common ones:

Crash reporting: Sentry, Firebase Crashlytics
Analytics: Firebase, Amplitude
Advertising: Meta Audience Network, Google AdMob
Customer support: Intercom

Each one that touches personal data needs to be in your policy.

App store requirements

Apple App Store

Apple requires:

A privacy policy URL submitted with your app
A Privacy Nutrition Label in App Store Connect listing every data type you collect
Compliance with App Tracking Transparency (ATT) if you use advertising identifiers

Your privacy policy must be accessible before download — linking from the App Store listing is sufficient.

Google Play Store

Google requires:

A privacy policy link in your Play Store listing
A Data Safety section in Play Console describing what data you collect and how it's used

The Data Safety section and your privacy policy need to be consistent. Discrepancies lead to policy violations.

Where to host it

Your mobile app privacy policy should live at a public URL — a page on your website, not inside the app. This allows it to be linked from the app stores and accessed before download.

Generate your mobile app privacy policy

InkTerms creates personalised privacy policies for mobile apps — covering device data, permissions, SDK disclosures, in-app purchases, and app store requirements.

Generate My App Privacy Policy →

Originally published on InkTerms Blog

GDPR Fines for Small Businesses — What You Actually Need to Know

Daiva McLean — Sun, 17 May 2026 13:55:12 +0000

GDPR fines get reported at the €746 million end of the scale. Those are for Meta. What does enforcement actually look like for small businesses?

Here's the honest picture.

The maximum fines (and why they don't apply to you)

GDPR has two tiers of maximum fines:

Tier 1: Up to £8.7 million or 2% of annual global turnover — for less serious violations (e.g. failing to notify a data breach in time)

Tier 2: Up to £17.5 million or 4% of annual global turnover — for the most serious violations (e.g. processing data without a lawful basis, violating core principles)

These maximums are designed for large organisations. A £17.5 million fine on a solo founder with £30,000 in revenue doesn't make economic sense and the ICO knows it.

What small business enforcement actually looks like

The ICO (UK's data protection authority) takes a proportionate approach. For small businesses, typical outcomes of complaints or investigations include:

Informal advice — the ICO contacts you, explains the issue, and tells you what to fix. This is the most common outcome for a first violation with no harm caused.

Formal reprimand — a written warning that goes on record. Public in some cases. No fine attached.

Enforcement notice — a formal order to take specific action (e.g. publish a privacy policy, stop a specific data practice). Failure to comply can lead to further action.

Monetary penalty — for serious or repeated violations, especially where harm was caused or data was handled recklessly. These are publicly announced.

Real examples at the smaller end

The ICO's public register includes enforcement actions against organisations of all sizes:

A small estate agency fined for sending marketing emails without consent
A sole trader fined for unlawfully sharing customer data
A small charity fined for sending millions of unsolicited emails

The fines in these cases ranged from £3,000 to £100,000 — not millions, but still significant for a small business, and all publicly visible.

What actually triggers enforcement

Most ICO investigations start with a complaint from an individual — usually a customer who didn't know their data was being used for marketing, or couldn't get their data deleted when they asked.

The most common triggers:

No privacy policy (basic non-compliance)
Marketing emails sent without consent
Failure to respond to a Subject Access Request (data access request) within 30 days
Data breach not reported within 72 hours
Sharing customer data with third parties without disclosure

The practical compliance floor for small businesses

You don't need a compliance department. You need:

A privacy policy that accurately describes what you do with data — live on your website
A cookie consent banner if you use any analytics or tracking
A way for users to request their data or deletion (an email address is fine)
Not sending marketing to people who didn't consent

That's it. Most small business exposure comes from not having (1) and (2).

The cost of getting it wrong vs getting it right

Getting a privacy policy wrong: potentially £3,000–£100,000 fine, public enforcement notice, reputational damage, customer complaints.

Getting it right: £9 and 10 minutes with InkTerms.

Generate My Privacy Policy →

Originally published on InkTerms Blog

What Happens If You Don't Have a Privacy Policy?

Daiva McLean — Sun, 17 May 2026 13:50:01 +0000

Most small businesses and indie founders don't have a privacy policy because they think the risk is too small to worry about. Here's what the actual risk looks like.

The legal position

Under UK GDPR, a privacy policy isn't optional. If you collect any personal data — which includes emails, IP addresses, names, or anything tracked via analytics — you're legally required to provide a privacy notice that tells users what you're doing with their data.

Operating without one is a breach of data protection law. Full stop.

What can actually happen

ICO complaints

The UK's Information Commissioner's Office (ICO) can receive complaints from your users. If someone signs up to your product, doesn't know how their data is used, and files a complaint — the ICO can investigate. For a business with no privacy policy at all, the outcome is not good.

Fines

ICO fines for GDPR violations can reach £17.5 million or 4% of annual global turnover, whichever is higher. In practice, fines at that scale are for large organisations.

For small businesses and individuals, the ICO typically issues enforcement notices and reprimands first. But formal enforcement actions are public — they appear on the ICO's register. That damages trust and reputation.

Enforcement action example

The ICO has taken enforcement action against sole traders and micro-businesses — not just corporates. If a complaint is made and you have no privacy policy, you've made the ICO's job very easy.

The practical risks beyond regulation

App store rejection. If you're submitting to the Apple App Store or Google Play, a privacy policy URL is mandatory. No privacy policy = no listing.

Payment processor requirements. Stripe requires a privacy policy to be live on your site. PayPal does too. Operating without one can result in account suspension.

B2B deals blocked. Enterprise customers run vendor due diligence. If you have no privacy policy, they won't sign. A single missed contract can cost more than a year of compliance work.

Loss of user trust. More users check privacy policies than you'd expect — especially in the UK and EU. A missing policy signals that you haven't thought about data, which raises red flags at the purchase stage.

"I'm too small for anyone to care"

The compliance risk does scale with size. The ICO prioritises complaints against large organisations. But:

Complaints can come from anyone, regardless of company size
Your competitors can report you
Regulatory risk increases every time you grow — and if you've never had a policy, the history of non-compliance doesn't disappear

Getting compliant now, while small, costs almost nothing and creates no negative consequences.

How long does it take to get one?

Less than an hour using InkTerms. Answer questions about your product, download a personalised privacy policy, paste it into your website. Done.

The risk of not having one far outweighs the five minutes it takes to get it sorted.

Generate My Privacy Policy →

Originally published on InkTerms Blog

Privacy Policy vs Terms and Conditions — What's the Difference?

Daiva McLean — Sun, 17 May 2026 13:44:50 +0000

Most websites need both. They're often linked in the same footer, and new founders sometimes treat them as interchangeable. They're not. They do completely different things.

Privacy Policy — what it is

A privacy policy is a legal document that tells users what personal data you collect and what you do with it.

It's required by law in the UK, EU, and many US states the moment you collect any personal data — which includes emails, IP addresses, names, or anything tracked via cookies.

What it covers:

What data you collect (email, payment info, usage behaviour, etc.)
Why you collect it (service delivery, marketing, analytics)
Who you share it with (third-party processors like Stripe, Google, Mailchimp)
How long you keep it
User rights (access, deletion, correction)
How to contact you about data

Who it protects: your users. It gives them the information they're legally entitled to.

Who requires it: data protection law (UK GDPR, EU GDPR, CCPA).

Terms and Conditions — what it is

Terms and conditions (also called terms of service or terms of use) are a contract between you and your users. They define the rules of the relationship.

They're not strictly required by law in most jurisdictions — but without them, you have no written agreement with your users, no way to enforce your rules, and limited protection if things go wrong.

What it covers:

What your service is and what it isn't
Acceptable use rules
Payment and subscription terms
Intellectual property (who owns what)
Liability limits (what you're not responsible for)
Account termination conditions
Dispute resolution and governing law

Who it protects: primarily you — it sets limits on your liability and gives you a legal basis for taking action if users break the rules.

Who requires it: no specific law mandates it, but common sense and legal exposure do.

The simple way to remember the difference

Privacy policy = about data. What information you collect and how you handle it. Required by data protection law.

Terms and conditions = about the relationship. What users can do, what you'll do, and what happens if something goes wrong. Protects your business.

Can I combine them into one document?

Technically yes — some small sites combine them into a single page. In practice this is messy and harder to maintain. It also reduces clarity for users, which can create its own problems.

Better approach: two separate documents, both linked in your footer.

Do I need both?

For any product with users or paying customers — yes, you need both.

A privacy policy alone doesn't protect you if a user abuses your platform. Terms alone doesn't meet your legal data obligations. They serve different purposes and both need to exist.

Generate both documents

InkTerms generates personalised privacy policies and terms and conditions — separately, correctly structured, and tailored to your specific product. Answer questions once, download both.

Generate My Documents →

Originally published on InkTerms Blog

What Is GDPR and Does It Apply to My App?

Daiva McLean — Sun, 17 May 2026 13:39:39 +0000

GDPR is the UK and EU data protection law that governs how businesses collect, store, and use personal data. If you run any kind of app, website, or digital product, there's a good chance it applies to you.

Here's what you actually need to know.

What is GDPR?

GDPR stands for General Data Protection Regulation. It came into force in the EU in 2018 and was adopted into UK law (as UK GDPR) after Brexit. The two versions are nearly identical.

It gives individuals rights over their personal data and places obligations on the businesses that collect it.

Does it apply to my app?

GDPR applies if:

You collect, store, or process personal data from people in the UK or EU
And you're established in the UK or EU — or you offer goods/services to UK/EU residents, or you monitor their behaviour

Personal data means any information that can identify a living person: names, email addresses, IP addresses, location data, device identifiers, or any combination that could single someone out.

So if your app has user accounts, collects emails, tracks usage, or uses analytics — GDPR applies.

Does it apply if I'm a small business?

Yes. GDPR has no minimum size threshold. A solo founder with 100 users is subject to the same principles as a corporation with millions.

The practical difference is enforcement priority and the amount of documentation required. Businesses with fewer than 250 employees are exempt from some record-keeping requirements — but the core obligations (lawful basis for processing, privacy policy, user rights) apply to everyone.

Does it apply if my users are in the US?

If your product is available to UK and EU users and you have any, GDPR applies to the data you hold on those users — regardless of where you're based.

If you're UK/EU-based and your users are exclusively in the US, UK GDPR technically doesn't apply to those users. But practically, most products serve a mixed audience and both GDPR and US state privacy laws (like California's CCPA) become relevant.

The six principles of GDPR

These govern how you must handle personal data:

Lawfulness, fairness, transparency — users know what you collect and why
Purpose limitation — data collected for one purpose can't be used for another without consent
Data minimisation — only collect what you actually need
Accuracy — keep data correct and up to date
Storage limitation — don't keep data longer than necessary
Integrity and confidentiality — protect data from breaches

What you need to do

For most small apps and websites, GDPR compliance comes down to:

A privacy policy — telling users what you collect, why, who you share it with, and how they can exercise their rights. This is the most important document.

A lawful basis for processing — usually consent (for marketing) or legitimate interests (for analytics/operations). You need to know which one you're relying on for each type of data.

A way for users to exercise their rights — access, deletion, correction. This can be as simple as an email address in your privacy policy.

Cookie consent — for non-essential tracking tools.

What are user rights under GDPR?

Users have the right to:

Access — request a copy of their data
Erasure — request deletion ("right to be forgotten")
Rectification — correct inaccurate data
Portability — receive their data in a usable format
Object — opt out of certain types of processing (e.g. direct marketing)
Restriction — limit how you use their data

Your privacy policy should tell users how to exercise these rights and you should respond within 30 days.

Generate your GDPR-compliant privacy policy

InkTerms generates personalised privacy policies that cover all UK GDPR requirements — lawful basis, user rights, data processors, retention periods, and more.

Generate My Privacy Policy →

Originally published on InkTerms Blog

UK Cookie Law Explained Simply

Daiva McLean — Sun, 17 May 2026 13:34:27 +0000

Cookie law is one of those things that most website owners either ignore entirely or overcomplicate. Here's what it actually requires — no jargon.

What is UK cookie law?

In the UK, cookies are governed by two sets of rules:

UK GDPR — applies to cookies that process personal data (analytics, advertising, tracking)

PECR (Privacy and Electronic Communications Regulations) — the specific UK law about cookies and electronic marketing. This is the one that requires consent banners.

Together, they mean: before you set any non-essential cookie on a user's device, you need their consent.

What counts as a cookie?

For legal purposes, "cookies" includes:

Traditional browser cookies
Local storage
Session storage
Pixels and tracking scripts
Fingerprinting techniques

If it stores or retrieves information from a user's device, cookie law applies.

Essential vs non-essential — the critical distinction

Essential cookies don't need consent. These are cookies that are strictly necessary for your website to function:

Session cookies (keeping users logged in)
Cart/basket cookies
Security cookies (CSRF tokens)
Load balancing cookies

Non-essential cookies require consent before being set. This includes:

Analytics (Google Analytics, Hotjar, Mixpanel)
Advertising and retargeting (Meta Pixel, Google Ads)
Social media embeds
Live chat tools (Intercom, Crisp)
Personalisation cookies

The rule: if your site still works without the cookie, it's non-essential.

What does valid consent look like?

Under PECR, consent must be:

Freely given — users can say no without being blocked from your site
Specific — they know what they're consenting to
Informed — they understand what the cookies do
Unambiguous — a clear positive action, not just scrolling or continuing to browse

This means pre-ticked boxes don't count. "By continuing to use this site you consent" doesn't count. A cookie banner that only has an "Accept" button doesn't fully count.

A compliant banner gives users a genuine choice to accept or decline non-essential cookies.

What your cookie policy needs to include

A cookie policy is a document (usually a separate page) that lists:

Every cookie your site uses
Whether it's essential or non-essential
What it does and why
Who sets it (you or a third party)
How long it lasts
How users can change their preferences

Common mistakes

Setting Google Analytics before consent — extremely common, technically non-compliant. GA should only fire after the user accepts analytics cookies.

No decline option — if there's only an "Accept All" button, your banner isn't compliant.

Cookie policy that doesn't list all cookies — if you've recently added Hotjar or a Facebook Pixel and haven't updated your policy, you're out of date.

Ignoring it entirely — the ICO (UK's data protection authority) has issued enforcement notices for cookie consent violations, including to small businesses.

Does this apply to me if my site is small?

Yes. Size doesn't determine whether PECR applies — using cookies does. If your site uses Google Analytics, you're subject to cookie law.

The practical risk of enforcement for a small site is low, but customer trust is real. A clean consent banner signals that you take privacy seriously.

Generate your cookie policy

InkTerms creates a personalised cookie policy listing the specific cookies your site uses — analytics, advertising, session, and third-party — along with a consent banner setup guide.

Generate My Cookie Policy →

Originally published on InkTerms Blog

Privacy Policy for a No-Code App (Lovable, Bubble, Webflow)

Daiva McLean — Sun, 17 May 2026 13:29:16 +0000

Building on Lovable, Bubble, or Webflow doesn't change your legal obligations. The law doesn't care how you built your app — it cares what your app does with user data.

Here's what you need to know if you've built (or are building) a no-code product.

The no-code misconception

A lot of no-code builders assume that because their platform handles hosting, databases, and infrastructure, the legal side is also handled. It isn't.

Lovable, Bubble, and Webflow are your data processors. You are the data controller. That means the legal responsibility for what happens to your users' data sits with you — not with the platform.

What your privacy policy needs to cover

Your platform as a data processor

Your privacy policy needs to name the no-code platform you're using as a third-party data processor. If your Bubble app stores user data in Bubble's database, that's Bubble processing personal data on your behalf.

List:

Lovable / Bubble / Webflow as infrastructure/hosting
Any connected services: Supabase, Firebase, Airtable
Authentication providers: Auth0, Clerk, Firebase Auth
Analytics: PostHog, Mixpanel, Google Analytics
Payment processors: Stripe, Lemon Squeezy

Third-party integrations

No-code apps typically connect to many services via API or native integrations. Each one that touches personal data needs to be disclosed.

Common ones to check:

Email: Resend, SendGrid, Mailchimp
Customer support: Intercom, Crisp
Error tracking: Sentry
CRM: HubSpot, Notion (if storing user data)

Data storage location

Where is your data actually stored? Bubble stores data in the US by default. Webflow's CMS is hosted on AWS. Supabase lets you choose a region.

Under UK and EU GDPR, if personal data is transferred outside the UK/EEA, you need to mention this in your privacy policy and confirm that adequate safeguards are in place (most major US platforms cover this via their own Data Privacy Frameworks).

User rights

Your privacy policy needs to tell users how they can:

Request a copy of their data
Request deletion
Update or correct information

If your no-code app doesn't have a built-in account deletion flow, you need to provide a contact method (email) where users can make these requests — and you need to actually action them within 30 days.

Cookie situation for no-code apps

No-code platforms often add their own cookies and tracking. Webflow adds Google Analytics integration. Bubble has session cookies. Lovable apps may pull in tracking from integrated tools.

Check what cookies your platform and integrations are setting before writing your cookie policy — the default assumption is more than you'd expect.

The documents a no-code app needs

Privacy Policy — required
Terms and Conditions — required if users have accounts or pay
Cookie Policy — required if any tracking is active
Refund Policy — required if you're selling anything to UK consumers

Generate your no-code app documents

InkTerms generates personalised legal documents for no-code products built on platforms like Lovable, Bubble, and Webflow — covering your specific integrations, data processors, and jurisdiction.

Generate My App Documents →

Originally published on InkTerms Blog

Legal Documents for SaaS Products — The Complete List

Daiva McLean — Sun, 17 May 2026 13:24:04 +0000

SaaS is different from a standard website. You're not just collecting emails — you're running ongoing accounts, charging recurring payments, and giving users access to software that may affect their work or business. The legal requirements reflect that.

Here's what a SaaS product needs.

1. Terms and Conditions (Terms of Service)

Your terms are the contract between you and every user. For SaaS they need to cover more than a basic website.

Essential clauses:

Subscription terms — billing cycle, renewal, cancellation
Acceptable use policy — what users can and can't do with your software
Account termination — when you can suspend or delete an account and what happens to the user's data
Service availability — uptime expectations (or the lack of any guarantee)
Limitation of liability — capping your exposure if your software fails
Intellectual property — you own the software; they own their data
Changes to the service — your right to modify, deprecate, or discontinue features

2. Privacy Policy

Required the moment you collect any personal data — which for SaaS starts at account creation.

For SaaS specifically, your privacy policy needs to cover:

Account data (name, email, payment details)
Usage data (feature usage, session logs, error reports)
User-generated content stored in your platform
Third-party integrations (Stripe, analytics, customer support tools)
Data portability — how users can export their data
What happens to data when an account is closed

3. Cookie Policy

SaaS products typically use cookies for session management, analytics, and feature tracking. You need a cookie policy and a consent banner for non-essential cookies.

4. Refund Policy

UK law gives consumers a 14-day cancellation right. For SaaS, you need to be explicit about:

Whether the 14-day period applies to your product
Whether a refund is available mid-subscription or only at renewal
How cancellations are processed and when billing stops

Many SaaS businesses offer "cancel anytime, no refund for current period" — that's fine, but it needs to be stated clearly.

5. Data Processing Agreement (DPA)

If any of your users are businesses — and especially if they're EU or UK businesses — they will ask for a DPA before signing up. This is a formal document establishing you as a data processor under GDPR.

B2B SaaS without a DPA will lose enterprise deals.

6. Acceptable Use Policy (AUP)

Sometimes included in terms, sometimes a standalone document. Defines prohibited uses: spam, illegal activity, scraping, abuse of other users. Protects you from liability if a user misuses your platform.

What SaaS businesses most commonly miss

No account termination clause — if a user abuses your platform and you close their account, they can argue there was no contractual basis
No data deletion timeline — GDPR requires you to state how long you keep data after account closure
No DPA — fine until your first enterprise customer asks for one and you lose the deal
Vague subscription terms — leading to chargebacks when users expect refunds you didn't intend to give

Generate your SaaS legal documents

InkTerms creates personalised legal documents for SaaS products — terms of service, privacy policy, cookie policy, refund policy, and DPA. Answer questions about your product and download everything in minutes.

Generate My SaaS Documents →

Originally published on InkTerms Blog

Legal Documents Every Shopify Store Needs (UK)

Daiva McLean — Sun, 17 May 2026 13:18:53 +0000

Shopify makes it easy to launch a store. The legal side is your responsibility — and there's more to it than most new store owners realise.

Here's exactly what you need as a UK-based Shopify seller.

1. Privacy Policy — required

The moment someone visits your store, data collection begins. Google Analytics, Facebook Pixel, Shopify's own tracking — all of it is happening before anyone adds anything to their cart.

Under UK GDPR, you need a privacy policy that explains:

What data you collect (browsing behaviour, purchase history, email addresses)
How you use it (order fulfilment, marketing, analytics)
Which third parties receive it (Stripe, Mailchimp, Meta, Google)
How long you keep it
How customers can request deletion

Shopify has a basic privacy policy generator built in, but it's generic. A personalised policy that reflects your actual data practices is better legally and looks more professional.

2. Terms and Conditions — required

Your terms define the relationship between you and your customers. For a UK e-commerce store, they need to cover:

What you sell and what you don't guarantee
Payment terms
Order acceptance (you reserve the right to cancel orders)
Intellectual property (your product images, descriptions, branding)
Limitation of liability
Governing law (England and Wales, or Scotland)

3. Refund Policy — legally required in the UK

This one is non-negotiable. Under the UK Consumer Contracts Regulations, online shoppers have a legal right to a 14-day cancellation period for most goods.

Your refund policy must state:

The returns window (minimum 14 days for physical goods)
How customers start the return process
Who pays return postage
How and when refunds are processed
Any exceptions (personalised items, perishables, digital downloads)

Digital products are different. Once a digital product has been downloaded or accessed, the 14-day right to cancel can be waived — but only if the customer explicitly acknowledges this before purchase.

4. Cookie Policy — required

Shopify stores use cookies extensively — session cookies, cart cookies, analytics, retargeting pixels. Under UK PECR, you need a cookie policy and a consent banner.

Your cookie policy needs to list:

What cookies your store uses
Which are essential vs optional
Which third-party cookies are set (Meta Pixel, Google Analytics, etc.)
How customers can manage preferences

5. Shipping Policy — strongly recommended

Not a legal requirement, but customers expect to find it. Clearly stating:

Processing times
Shipping methods and estimated delivery
International shipping (if applicable)
What happens if an order is lost

Reduces customer service queries significantly.

Where to put them

All policies should be:

Linked in your Shopify footer
Added to your checkout flow (Shopify has a built-in field for policy links)
Accessible before purchase

Shopify Settings → Legal is where you paste your policy text. Then Settings → Checkout lets you display them at checkout.

Generate your Shopify store documents

InkTerms creates personalised legal documents for e-commerce stores — privacy policy, terms and conditions, refund policy, and cookie policy. Answer questions about your store and download everything in minutes.

Generate My Store Documents →

Originally published on InkTerms Blog