Sad (but now HAPPY) story. Lost 8 projects over GDPR issues - new feature added

I knew this was coming, unfortunately.

As I was developing affordable apps, the interest kept spiking amongst my clients. Until the point that a single client commissioned N.8 apps.

However, shortly after, I had to deal with one of their Privacy Lawyers who explained how the system infringes GDPR compliance.

Both myself nor the client weren’t planning any fancy data processing mechanism (we didn’t even have Google Analytics installed yet).

However, even just the act of filling a form or saving an item in the user’s favorites seems to be an issue for GDPR.

We have a specific T&C / Privacy Policy section in the app, however, it still doesn’t seem to be enough.

It seems that the only option to go ahead is to create “empty shells” type of apps, where users can’t create their profile, save anything in their favorites or fill a form. Disappointed.

I might have encountered the wrong client. But I’m overall pissed - not with Glide, of course, but with the massive amount of stringent regulations that we have in Europe that are acting as a liability on developers.

Have you guys faced this issue in Europe before? How did you act?


Sorry to learn of your situation. I’m sure I posted a contribution to this topic somewhere on this forum. Let me see if I can locate it.

1 Like

@maschera: Sorry to hear that but it is a serious issue and one reason we are not going hell for leather with our plans with Glide.

All of our business is (and will be) in Europe.

Privacy is one of the tasks on my list and have been using

This enables you, amongst other things, to generate detailed privacy policies listing all of the 3rd party services you use for collecting and managing data.

Did your client’s lawyer express exactly how the system infringes GDPR compliance? And when you say ‘the system’ are you speaking about your Glide app itself, or Glide in general?


Hey Garrison, it makes me feel better I’m not alone in this :slight_smile:

I use Iubenda as well on my site, where I promote my apps - however, there is no mention about GlideApps (I should probably add it).

The way we dealt with it so far is as follows:

  1. Customer posts his own Privacy Policy within a specific Glide App section
  2. At the bottom, I include my own Iubenda policy links

The lawyer of this specific customer claims that I should be elected as the “Responsible for Data Processing”, and he doesn’t feel comfortable if we simply use our Iubenda links within their own Privacy Policy. He wants to me to sign a specific paper that overwrite our Privacy Policy and T&C - and I’m not willing to do so.

He claims that if there’s a Google Sheets’ outage, so the customer loses his data, I should be responsible for it. And he claims I should have backup, redundancy measure and a million other things (even a plan to mitigate natural disasters, imagine).

It’s a massive hassle and feels like a big liability for such a small contract. Were we talking about a XXX$ contract, I’d be happy to have my lawyer review this.

But in my case, it’s not worth at all.


Sounds like they should consider hiring an entire IT department. HADR isn’t exactly a one man job. That’s why people pay Google or Amazon to handle that.


@maschera: As far as I am aware you should be the elected party "Responsible for Data Processing”, or as Iubenda calls it “Owner and Data Controller”.

That is pretty much a given, and indeed forms the key preamble of your privacy policy.

I’m not sure he has any right in seeking you to sign specific papers to overwrite your privacy policy & T&C as there should be indemnity clauses within those articles anyway. Not sure, I’m not a lawyer, just using common sense.

Have you asked Iubenda about this? Might be worth hearing what their take on this is.

And yes, if there’s no preset for Glide you can easily add it in Iubenda yourself using their custom tool.

In terms of loss of data, this isn’t an insurmountable issue is it? There are many ways to backup & protect data.

To mitigate against natural disasters? That’s precisely what ‘Force Majeure’ is for, and almost all T&Cs have this.

1 Like

That’s what exactly I have told them Jeff.

What they sent me is a typical letter of engagement when you outsource an IT function.

1 Like

Yes, it’s sad. And it’s also why I can’t go further with Glide at the moment. The sign up & sign in feature are not usable in this context in Europe. For the other things they told you, it’s a bit hard to listen, in this case there won’t be any no-code tools / apps in Europe…


What I’m wondering though, is if I’m compliant if I adopt the below measures.

Say that I include a Privacy Policy component within the app.

Say that I make sure that every time that a user takes an action that requires him/her sharing personal data (e.g. filling a form), he will need to accept by ticking a box, with a link to the privacy policy.

Since I’m not using any Google Analytics or any other cookies, I feel I’m compliant (unless Glide tracks something I’m not aware of - will need to ask Glide).

The only problem that I see is the use of “Favorites”. There’s no way at the moment to make this GDPR compliant, although it seems technically doable. We might need a simple acceptance box with the T&C links below the email user registration landing page.

Worse gets worse, I will disable the Favorites feature in Europe, and perhaps expand to markets outside of Europe.

It’s a big hassle, but I believe at the moment we have no alternatives.

Hoping that Glide can shed some light on when GDPR compliance is finally going to be available.


What a pity.

We need Glide to help us out. There was quite a learning curve to learn developing in Glide, and I will never want to drop it. I feel both technically and emotionally invested.


@maschera: this is a very valid point you make re: being “both technically and emotionally invested”, as this is exactly how I feel too. Although I must say my emotional investment is more impressive than my technical investment :wink: (still learning though).

I too would like to hear Glide’s take on this, especially the request to signup when using the ‘favourites’ feature.

For example, is there a generic privacy policy we can ‘inherit’ from Glide?

Apart from any 3rd party APIs that people have integrated with their apps, Glide’s core tech stack is fairly narrow, off the top of my head they are…

  • Glide itself (aka Typeguard Inc.)
  • Google Sheets (and by association Google Drive)
  • Google Cloud Platform (i.e. Firebase etc)
  • Google Analytics
  • Mapbox
  • Cloudinary
  • Zapier integration
  • Stripe integration
  • Font Awesome? (icon pack)
1 Like

@maschera Thanks for sharing - I hope that it will get some attention from Glide.

@david It seems obvious that Glide does have an issue with GDPR - and I cannot understand why you are not adressing it - or sharing when and how you will adress it.
Glide (in my understanding without a legal background) serves as a data processor for us as data responsible. The app owner (us) are responsible for the personal data that people leave in our app. When Glide uses’ different 3rd party APIs - we are still responsible for all the personal data that is transferred to the third parties. So if fx mapbox stores - and loses - all the location that the user has saved in Glide - and this data can be traced back to the user (e.g. the data is not anonymous) - well, then we will be responsible. We will have to tell the user that we have lost their data.
Further, the user has a number of rights in relation to GDPR (in my understanding):

  • which processing do we do with the personal data (including what the data processor and their third parties do)
  • rights to know which personal data that we process
  • rights to stop us from processing their personal data (this might mean that they cannot use our app)
  • rights to have data corrected
  • rights to be deleted including all their data
  • rights to limiting the use of the personal data
  • rights to data portability
  • rights to withdraw a consent

Glide could help us as developers to be able to fulfil the GDPR requirements by stating how we can comply. Glide could deliver a data processor agreement telling exactly what Glide does with the personal data - and which 3th party that have access to the data.

I would think that Europe is such that big business oppotunity for Glide that it is not acceptable that only apps without personal data can be created in Europe.


Thanks Krivo, I hope too that @david will shed some light on the issue.

Regardless of where your company is based, GDPR applies if a user is an EU resident. For what I understand, even if the app provider is based in the US but a user happens to be from France, the app provider will be liable if GDPR is not respected.

It’s a top priority issue according to me, and I believe too that this should be treated with transparency and clarity.

David, don’t get us wrong, but GDPR is a major paranoia for us. It’s the elephant in the room that doesn’t make some of us sleep at night.


If it makes anyone sleep a little easier, I know GDPR compliance is on Glide’s roadmap. I can’t speak to the details (because I don’t have them), but it was shared in a Expert meeting that Glide is taking GDPR compliance seriously.

1 Like

Yes, but “within the next 6 months”. What can be understood, but what can’t be accepted to make Glide the baseline of our apps / solutions.

This priority is mainly I guess for Europe and european makers, but it’s far more important than some of the “little” (but with added value) features and enhancements provided during the past weeks or months. I’ve asked about GDPR compliancy roadmap for months, and recently I got the “next 6 months” response to get a login button somewhere else in the app to allow to add one or two checkboxes to manage sign up and sign in seriously.

As makers, we don’t have time and don’t want to loose time to validate our stack for business purpose. If it’s not possible, it’s not possible, that’s it. Other no-code tools do the job and match the requirements.

Time is money. Lost time is lost money. No debate here.

I don’t know if we can transfer an annual PRO subscription, but if somebody’s interested and if we can, I have an unused one, subscribed few days ago. And good price (60% off r./ regular price :slight_smile: )


I’ll confirm this is absolutely the case. I have personally run into this with EU-based users who were previewing a demo without my knowledge and it didn’t take long before I was alerted. It’s nerve-wracking and I’m sorry for what you’re up against.


I’d encourage anyone market-testing or commercializing apps built on a no-code platform to consult an attorney if your budget allows for it. Even better, have them develop your TCs and privacy policy.

1 Like

I am still quite new to Glide and am still in the process of understanding what Glide is “supposed” to be used for.

Glide users, that is us makers, decide what Glide is used for. That being said, in my understanding of Glide so far, there is a strong business case to use Glide for internal business apps, namely due to the row limitations and limited scalability (for now) based on 500, 25K or even 50K list items.

The internal business apps use case would imply that Glide makers who want to monetize their skill would – in some shape or form (selling templates, building prototypes, building full-fledged apps that require limited data) – build B2B apps for businesses.

This would also imply that B2C public-facing apps might be less of a business case for using Glide (for now), which is typically where GDPR comes into play.


@nathanaelb: Yes, the B2C public-facing apps is where we’re coming unstuck, principally because I made the assumption GDPR was covered.

To be fair, it probably is but with the lack of detail on this subject from Glide it’s a little bit murky right now.

That being said, I think the onus is on us as makers to ensure our apps comply with GDPR and there are various tools at our disposal to help with this, namely and others.

However, it would be really helpful if Glide could provide us with some sort of matrix on privacy requirements for each of their respective sign-in models.

That would be a great starting point.