GDPR and Your Website: What a Small Business Has to Do
On a small business website, GDPR comes down to four decisions, and all four are made while the site is built: what your forms collect and where that lands, what analytics you load, what the page pulls in from other companies, and where the whole thing is hosted. That is why it sits inside the price rather than beside it. A step 03 business website is EUR 1.500 to 3.500, and those four decisions are part of building it.
What sits outside the build is legal advice. We can tell you what your site does with personal data and make it defensible. Whether your particular processing is lawful is a question for a lawyer.
Forms: the data people hand you
Every field is a decision to hold something about a person. Ask for what you will use and nothing else. A contact form needs a name, a way to reply and a message. It does not need a date of birth.
Then decide where it goes: an inbox, a CRM, a database, or several. Each destination is another company holding your visitor's data, so it needs a processor agreement and a line in your privacy statement. Decide how long you keep enquiries, and make that true.
Marketing consent is separate. A newsletter opt-in is its own tick box, never pre-ticked, never bundled into the contact form. Someone asking a question has not asked for your mailing list.
Spam protection is a data flow too. Pick a challenge widget that does not hand your visitors to an advertising company. At build time that choice costs nothing.
Analytics: the data the site collects about visits
There are two routes. Cookieless analytics gives you page views, referrers and which pages people leave from, without storing anything on the visitor's device that needs permission. For a business website that answers the questions you will actually ask.
The other route is Google Analytics and advertising pixels. Pixels need consent before they load, and a banner that genuinely blocks them until then. Google Analytics sits in between: the Dutch regulator has published conditions under which it can run without consent, and outside those it needs consent too. Take that route when you run ads and need conversion data. Skip it when you do not.
Embeds and pixels: what the page loads from other companies
A visitor's browser contacts every domain your page references, and hands over an IP address doing it. The common cases and their fixes:
- Web fonts: host them yourself instead of calling a font service on every page load.
- Video: use the privacy preserving embed, or a thumbnail that loads the player on click.
- Maps: a static image linking through to the map is enough on a contact page.
- Chat widgets and social pixels: real third parties, with a real entry in your privacy statement. Keep the ones that earn it.
Hosting: where all of it sits
On the infrastructure side, personal data ends up in the database behind your forms, the server logs and the backups. Decide the region, decide who holds the accounts, and collect processor agreements from the host, the database provider and whoever sends your transactional email.
Our terms are plain. You own the code, the repository and the database, so nothing is held hostage and any developer can take over. Hosting is agreed per project, so where the site runs and whose account it sits in is settled with you before launch rather than assumed.
The cookie banner is a consequence, not a decision
Consent is required for storage beyond what the site needs to work, with a narrow exception for analytics that barely touches privacy. A site with cookieless analytics, self-hosted fonts, click-to-load video and no advertising pixels has none of that, so it needs no banner.
If you do need one, it has to behave: nothing loads before consent, refusing is as easy as accepting, no pre-ticked boxes, and a way to change the answer later. A banner that appears while the trackers are already running is worse than no banner, because it documents the problem.
The paperwork
A privacy statement describing what your site actually does. A cookie statement if there are cookies. A record of what you process and why. Processor agreements with everyone named above. An address a human reads, for people asking what you hold or asking you to delete it. And a breach plan, because the reporting deadline to the Autoriteit Persoonsgegevens is short.
What it covers at each step
Prices as listed on packages. The right hand column is the privacy work at that size of site.
| Step | Price | What is covered |
|---|---|---|
| 01 Single-page landing | EUR 600-900 | One form, a destination for it, cookieless analytics, and privacy statement content wired into the page |
| 02 Mini-site | EUR 900-1.500 | Contact flow, newsletter opt-in kept separate from it, privacy and cookie pages editable in the CMS |
| 03 Business website | EUR 1.500-3.500 | Several forms, booking or contact routing into an inbox or CRM, retention agreed per form, embeds handled at build time |
| 04 Advanced site or web app | EUR 3.500-7.500 | Accounts, dashboards holding customer records, API integrations, CRM, payments and chatbot transcripts, where access control, export and deletion become features |
| 05 Custom SaaS platform | from EUR 7.500 | After discovery, with a data map, roles, audit trail and deletion designed in from the first screen |
Care at EUR 100 to 300 a month keeps dependencies patched, backups running and small fixes moving, and an unpatched plugin is a privacy problem too. It is not a redesign and it is not new features. A fixed quote always follows scoping.
How the work runs
Scope settles what you collect and why. Build settles where it goes, which analytics loads and which third parties stay. The run-up to launch is the privacy statement, the cookie statement if one is needed, and the processor agreements. Timings follow the step: one to two weeks at step 01, two to three at step 02, three to six at step 03, six to twelve at step 04, and after discovery at step 05. The privacy statement is the part that waits on you, because it has to describe your business. How we build is on design and engineering and our Next.js development page.
When to spend less
- One contact form, cookieless analytics and no embeds means no consent platform subscription. Do not pay monthly for a banner you do not need.
- Removing a tracker is cheaper and faster than keeping it compliantly. Ask what each one is worth before you build a consent flow around it.
- A data protection officer is required in specific situations, large scale monitoring and special category data among them. If that is not what you do, do not buy one.
Questions buyers ask
Do I need a cookie banner?
Only if the site stores something on the visitor's device that needs consent, such as advertising pixels or tracking that shares data onward. Cookieless analytics, self-hosted fonts and click-to-load video get you to no banner at all.
Can I still use Google Analytics?
Yes. Set up within the conditions the Dutch regulator has published, it can run without consent. Set up to share data for advertising, it needs a banner that blocks it until someone agrees. If all you want is traffic and referrers, a cookieless tool gives you that with less to maintain.
Where does my form data go, and who can see it?
Wherever you decide during scoping: an inbox, a CRM, a database, or more than one. We write it down, name each processor in the privacy statement, and set a retention rule per form.
Is a template privacy policy enough?
It is a reasonable skeleton and a bad final answer. A template lists processors you do not use and omits the ones you do, which is exactly the mismatch a complaint exposes. Start from one, then edit it against the real list of forms, analytics, embeds and hosting on your site.
Tell us what your site needs to collect and we will scope it, with a price attached. Start here.
Building something?
JP Studio designs and builds websites, storefronts and product interfaces.