Custom software almost always processes personal data. A client portal knows your customers, a scheduling tool knows your employees, a request form collects names, addresses and sometimes much more sensitive things. And yet, in practice, the GDPR question comes up far too often only after the build, when someone suddenly wonders where all that data actually lives. By then it's expensive and awkward to repair, while up front it was a matter of asking the right questions.
This article helps you ask those questions in time. Not a legal lecture, but a practical checklist for anyone who wants to get GDPR-compliant custom software built and doesn't want compliance to become a nasty surprise after the fact.
Why this matters extra with AI-built software
With AI-built software a layer is added that you're less likely to encounter with a traditional agency. Three questions then suddenly become very concrete.
Where does the AI model run that builds or powers your software? Many well-known AI services run on servers outside Europe, and if your data passes through them, that's a processing operation you need to have an opinion about.
Where does your data ultimately live? The software that gets built has to run somewhere. If that happens by default on American cloud infrastructure, your personal data sits outside the EU without you consciously choosing that.
And does anyone train on your customer data? Some tools use the data that passes through them to improve their own models. For your customer data that's almost always undesirable, and sometimes simply not allowed.
These questions aren't scary once you ask them, but they do have to be asked. That's exactly why GDPR-compliant AI development treats GDPR as an explicit design choice, not as something you'll arrange later. A methodical AI development approach is what makes that possible.
The six checkpoints for GDPR-compliant software
Whether you knock on the door of an agency, a SaaS supplier or an AI development team, these are the six things you want in order up front.
Data location and EU hosting
Where do your servers, backups and log files physically live? For personal data, hosting within the EU is the simplest and safest route. The moment data goes to countries without an adequate level of protection, you need additional safeguards and it gets unnecessarily complicated. Ask explicitly where everything runs, including the backups, because those are often forgotten.
Processing agreement
The moment a supplier processes personal data on your behalf, a processing agreement (a DPA) belongs with it. It sets out what the supplier may do with the data, how it's secured and what happens if things go wrong. No DPA means a gap in your accountability, and that's a gap you'll be held responsible for.
Audit trail
Can you trace back who viewed or changed which data and when? An audit trail isn't just handy during incidents, it's often a hard requirement to demonstrate that you handle data carefully. Ask whether this is built into the software by default or whether you have to arrange it separately.
Data minimization
Does the software collect only what's really needed, or is everything stored "just in case"? GDPR calls for data minimization: less data means less risk, less maintenance and less that you're liable for. This starts as early as the design of your forms and data model. Anyone still keeping data in scattered files can see in from Excel to web app how to turn that scattered chaos into something structured and manageable.
Export and ownership of code and data
Who owns the code, and who owns the data? Can you export and take your data with you at any moment? This is about data sovereignty and about lock-in. If your data is trapped in a supplier's system, you're dependent, and that clashes with the principle that you stay in control of your own personal data.
Sub-processors and AI training
Which other parties (sub-processors) are brought in, and what do they do with the data? And the core question with AI: is your data used to train models? You want a clear no on that last one, in black and white. A supplier who stays vague about this is a supplier you shouldn't yet trust with your customer data.
The right questions for your supplier
These checkpoints only become useful once you turn them into concrete questions. Here's how to tell a good answer from a red flag.
| Question for your supplier | Good answer | Red flag |
|---|---|---|
| Where does my data live, including backups? | "Within the EU, and we can prove it." | "Somewhere in the cloud" or no clear answer |
| Can I get a processing agreement? | "Yes, a standard part of the contract." | "Is that really necessary?" |
| Is my data used to train AI? | "No, explicitly not, it's in the agreement." | "Only to improve the service" |
| Can I export my data and code? | "Yes, at any moment, it's yours." | Export costs extra or isn't possible |
| Is there an audit trail? | "Yes, built in by default." | "We could build that if you like" |
| Which sub-processors do you use? | A concrete, up-to-date list | No visibility or no answer |
If you get a vague answer to several questions, that in itself is information. GDPR compliance isn't something a serious supplier dances around.
Common mistakes
Three pitfalls show up in practice again and again, and they're all avoidable.
American tooling without a DPA. Deploying a popular service without checking where the data lands and without a processing agreement. It goes fine until it doesn't, and then you're left empty-handed.
"We'll sort it out later." Treating GDPR as an afterthought, after the build. In practice, later means: reworking the software, migrating data and arranging agreements after all, at much higher cost than if you'd taken it into account up front.
Data in prototype tools. Quickly building something in a prompt-to-app tool and putting real customer data in it. Prototype tools are rarely set up for GDPR accountability, and data location is often a blind spot there. Fine for testing an idea, not for housing real personal data.
How Turtleship handles this
At Turtleship, GDPR isn't an afterthought but a starting point. Your software and your data run within Europe by default, so you don't have to guess where personal data ends up. The code and the data are yours, in your own repository, so there's no question of lock-in. And an audit trail comes with the building blocks, so you can trace back who did what.
That becomes concrete in the portals you have built. A client portal processes your customers' data, a supplier portal that of your suppliers, and a custom employee portal that of your own people. In all three cases, the question "where does this data live and who can access it" is part of the design from the outset, not something you stick on afterward. The same holds for client portals at service businesses, where confidentiality is often the core of the relationship.
Conclusion
GDPR-compliant custom software isn't a matter of luck or of a legal department approving it after the fact. It's a matter of asking the right questions at the right moment: up front, not after the build. Where does my data live? Is there a processing agreement? Is anyone training on my customer data? Can I export everything and take it with me?
A supplier who answers these questions with a clear yes gives you more than just compliance. They give you the certainty that you can entrust personal data to your software with peace of mind. And that trust is precisely what software for your customers, suppliers and employees is all about.
Want software built where EU hosting and data ownership are the starting point? Start free and see how Turtleship takes GDPR into account from the very first build step.