If you build a client portal, a booking app or a small CRM for your customers, GDPR compliance quickly becomes a real question, even if you have no legal team and no in-house lawyer. This guide breaks down, in plain language, what the GDPR actually asks from a small business app, what changes when you build with a no-code or AI platform, and a practical checklist you can run through yourself. It is an educational overview, not legal advice: for regulated industries (health, finance, children's data) or larger-scale processing, talk to a lawyer or a Data Protection Officer before you ship.
Controller vs processor: the one distinction that clarifies everything
The GDPR is built around a simple but often confusing split. The data controller decides why and how personal data is processed, that is usually you, the business owner, when you collect your customers' names, emails or bookings inside your app. A data processor processes that data on the controller's behalf and instructions, that is every tool you plug in: your no-code/AI platform, your hosting provider, your database, your email sender, your payment processor. This distinction matters in practice for one reason: it tells you who is accountable for what, and it is why you should expect a Data Processing Agreement (DPA) from every processor that touches your users' data. If a vendor cannot produce a DPA on request, treat that as a red flag.
- Controller: you, for your end customers' data collected through your app.
- Processor: your platform, your hosting provider, your email tool, your payment provider, anyone processing data only on your instructions.
- Sub-processor: a processor's own vendors, such as the cloud host behind your database provider.
What GDPR compliance typically requires from a small business app?
Strip away the legal language and most GDPR compliance obligations for a small no-code app boil down to a short, practical list. The UK ICO provides excellent practical guidance that applies equally well to EU GDPR.
- A privacy policy in plain language: what you collect, why, for how long, who has access, and how people can exercise their rights.
- A legal basis for each type of processing: contract performance for fulfilling a booking, consent for marketing emails or non-essential cookies, legitimate interest for basic security and fraud prevention.
- Consent where genuinely required: an explicit opt-in for marketing communications and for any non-essential cookie or tracker.
- Data minimization: collect only the fields you actually need to deliver the service, resist the reflex to add "just in case" fields.
- Security basics: encrypted connections (HTTPS), reasonable access control, hashed passwords, and regular backups.
- User rights: a way for people to ask for access to, correction of, or deletion of their data, and to receive it in a portable format.
- Breach awareness: if something goes wrong, you may need to notify your supervisory authority and, in some cases, affected users.
The extra questions a no-code or AI platform adds
Building on a no-code or AI platform does not remove your GDPR obligations as a controller, it adds a layer of questions about your vendor. Before you commit real customer data to any platform, ask the following.
- Where does the data physically live, whose infrastructure, in which region?
- Who is the processor for that data, and do they publish a list of their own sub-processors?
- Is a Data Processing Agreement available, and does it actually cover the data you will store?
- Can you export your schema and data, and delete everything on request, without depending on the vendor's support team?
- Is the AI used only to help write your app's code, or does it also see and retain your end users' production data?
- Does the platform sit as an opaque middleman for your customers' personal data, or do you hold the keys to the actual database?
Choosing a region and getting a DPA
Two questions decide a large part of your risk exposure: where is the data stored, and can you get a signed DPA for it. Most serious backend-as-a-service providers, Supabase among them, publish a standard DPA you can accept directly, and let you pick the hosting region for your own database project, including EU regions. That matters because it puts the choice of jurisdiction in your hands rather than leaving it to a platform's default. It is worth checking this for every processor in your stack, your database, your email sender, your payment provider, your analytics tool, not just your app builder.
Cookies and trackers on the app or site you generate
Cookie rules are simpler than people expect once you separate the two categories. Strictly necessary cookies, the ones that keep a user logged in or remember a shopping cart, do not require consent. Everything else, such as analytics, ads or social media pixels, generally does, through a clear opt-in before the cookie is set. The simplest approach for a small app: start with only strictly necessary cookies, and add a consent banner only once you actually add an analytics or advertising tool that needs one.
A no-lawyer checklist for common app types
Showcase or portfolio website: a privacy policy page linked in the footer, a contact form that states what happens to submitted data and for how long, and a cookie banner only if you add analytics or ads.
Booking or appointment app: a legal basis combining contract performance for the booking itself and consent for reminder marketing, collecting only what is needed to fulfill the booking (name, contact, date), and listing your processors, calendar sync, payment, SMS or email provider, in your privacy policy.
Client portal or small CRM: a DPA in place with every processor touching client records, role-based access so team members only see what they need, a documented way to export or permanently delete a client's record, and a retention period you actually enforce instead of keeping everything forever.
Where Cadrant fits for no-code compliance: you keep the keys?
Cadrant is built around a bring-your-own-Supabase architecture: when you build an app, you connect your own Supabase organization rather than a database that Cadrant hosts and controls for you. That has direct GDPR compliance consequences. You choose your own Supabase project and its hosting region. Supabase, as your database processor, publishes its own DPA that you accept directly. You remain the controller of your end users' data, the people who book, sign up or submit forms through your app, and you keep full ability to inspect, export or delete that data at any time from your own Supabase dashboard, independent of Cadrant. This is deliberately different from platforms where your customers' data sits inside an opaque, shared, vendor-owned database you cannot query or export.
To be transparent about our own setup: Cadrant is published by Convergence Lab, a French company, and the platform itself, not the databases you connect, is hosted on AWS infrastructure that is not exclusively EU-based; we rely on appropriate safeguards for any transfer outside the EU, and our Data Protection Officer can be reached at dpo@cadrant.ai for questions about the platform itself. We do not claim SOC 2 or ISO 27001 certification today, and you should treat any such claim from a vendor with healthy skepticism until you have actually seen the certificate.
How Cadrant helps with GDPR compliance, in practice?
You can ask in natural language for the pieces that support compliance: a privacy policy page, a cookie consent banner, a contact form that discloses how submissions are used, or an account settings page where your own end users can request their data or ask to be deleted. Because your database lives in your own Supabase project, honoring a deletion or export request is a real, auditable action, not a support ticket sent to a third party. Compliance is never fully automatic, but starting from an architecture where you hold the data makes every step afterward much simpler.