For us, data protection isn't an addendum in the fine print - it's a build decision. Six concrete points - where your data lives, who gets at it, how we safeguard AI, and what's in the data processing agreement.
Data protection is often treated as a duty exercise - a cookie banner on top, a statement in the footer, done. We see it differently. When we build software for your business, data protection and data minimisation belong in the first sketch - not the last.
This page shows you what we stand by. It isn't the privacy policy of wendwerk.de - you find that in the footer as a legal document. This is our concept: where we host, how we use AI, what contracts we conclude, who has access. If you decide to work with us on a project, that's exactly the ground we stand on.
EU hosting
Whatever your software stores in data sits on servers in the EU or Germany.
Contracts
A data processing agreement with you, a contract with every service provider that works with your data.
Data minimisation
We store what we need - and no more. Not even "for later" or "because we could."
Software needs a place where it runs, and one where the data sits. With us, those are exclusively providers in the EU or in Germany. Web front-ends run on Vercel in the Frankfurt region. Databases and sign-ins sit on Supabase in Frankfurt (region eu-central-1). Where dedicated servers are needed, they sit at Hetzner or IONOS - both German, both GDPR-compliant.
This is a deliberate choice. There are cheaper US providers, faster global CDNs. But for software meant to run in the German SME world, EU hosting isn't a nice-to-have - it's a precondition, legally and practically. In the contract, every single provider that comes into contact with your data is named. You know at any time where your data sits, and you can check.
The background is the Schrems II ruling (CJEU 2020), which substantially tightened the legal situation for US cloud providers. Transmitting data to US servers isn't fundamentally forbidden, but tied to elaborate assessments - and in many cases simply risky. The Datenschutzkonferenz (Germany's federation of data protection authorities) has stated repeatedly in its 2024 resolutions that choosing EU-based providers is the legally cleanest solution.
In practice: Vercel operates its serverless functions in Frankfurt (region fra1), Supabase uses AWS Frankfurt for projects in eu-central-1. Hetzner and IONOS run their own data centres in Germany. With that, data processing is anchored in the EU region at every point - including backups, logs and temporary copies.
When we build software for you in which personal data is processed - customer contacts, user sign-ins, whatever - we are legally your data processor. That has to be set down in writing. With us, it's standard, not a special case: in every project with personal data, we conclude a data processing agreement (DPA) with you. You don't have to ask for it, and you don't have to draft it yourself.
In the DPA stands: which data is processed, to what purpose, for how long, who has access, what technical and organisational measures we use, and what happens if something goes wrong. It also contains the list of sub-processors - providers like Vercel, Supabase or Hetzner whose services we use and with whom we have our own contracts in turn. You can request the originals of those contracts for inspection.
The legal basis is Article 28 GDPR: whoever processes personal data on behalf of another must do so on the basis of a written contract containing certain minimum content. Without a DPA, the processing is simply unlawful - and in case of damage, the responsibility tends to fall on the client, because they didn't properly outsource the data processing.
With many service providers, the client has to explicitly demand the DPA - with some it's available against a surcharge, with others hidden in a self-service portal. We do it differently: the DPA is on the table before the first line of code is written. You don't have to check whether you need it - if any personal data is at all involved, it's there automatically.
AI features in your software don't run on the free consumer chats from OpenAI or Anthropic. We use the API access on a business contract - by default Anthropic Claude, and depending on the case, other providers too. In these business contracts, it's contractually excluded that your inputs are used for further training of the models. What goes in doesn't end up in the next model update.
Where the use case requires it, we route AI requests via EU regions - the effort varies by provider, but it's technically possible. Where it gets too sensitive, or where EU processing is explicitly mandatory, we use European providers (Mistral) or local models. Which provider is responsible for which AI feature in your project is set out in the data processing agreement - by name, region and purpose. You know what's happening, and you can verify it.
The legal basis here is twofold: on the one hand the GDPR, on the other, since 2024, the EU AI Act. Both require that the use of AI services be transparently regulated and contractually secured. The Datenschutzkonferenz (Germany's federation of data protection authorities) issued a 2024 guideline making clear that naive use of public AI tools with personal data is, as a rule, unlawful.
Anthropic concludes its business contracts with the standard DPA including a module for international transfers. OpenAI has offered API customers zero data retention since 2024 - queries are not stored, not passed on for training. Whoever uses that largely meets GDPR requirements. Whoever uses the free consumer chats does not - there, training use is the default. We make exactly this distinction explicitly transparent in every project.
The best data protection is what's never stored. With every piece of software we build, at the start we go through with you: which data do we actually need for the tool to do its job? What would be nice to have, but isn't necessary? What would be a memory aid we can just as well leave out? Many things that off-the-shelf systems collect by default - tracking, IP logs, click paths, device fingerprints - we deliberately don't build in at all.
For the sign-in of your staff and customers, we use the magic link sign-in wherever possible: instead of a password, you enter your email address and receive a one-off sign-in link by email. With that, we store no passwords and avoid the whole class of password-related data breaches. Data minimisation isn't a virtue we stick on at the end. It's an architectural decision on day one.
The legal term is Privacy by Design and Privacy by Default - codified in Article 25 GDPR. The idea: data protection doesn't start with the finished system, but with the architecture. Data minimisation is its own principle in Article 5(1)(c) GDPR: only as much data may be processed as is actually necessary for the respective purpose.
Magic-link sign-ins have become a standard in the industry in recent years, because they solve two problems at once: they store no passwords (so no password databases that could be cracked), and they demand no password hygiene from the user. Banks and large platforms increasingly use them too. Where a classical login is needed - for instance because an existing system is involved - we use established standards with hashed passwords (bcrypt, argon2).
As a rule, exactly one person has access to your data - the human who builds and supports the project. In ongoing projects, that means Johannes Hohls as the technical lead. When the project grows and additional developers come on board, they are named in the data processing agreement - with their own confidentiality obligation. There are no anonymous service accounts that "just happen" to have access.
Within your business, you decide who's allowed to see what. The software we build has a role system from the start - management sees different things than accounting, accounting different than field service. That's not only clean, it's also GDPR-compliant: access rights are part of the technical and organisational measures we describe in the DPA. The question "who actually has access to what right now?" must be answerable at any time in your business.
The technical term is the need-to-know principle - each person gets access only to the data they actually need for their task. In the GDPR, this is in Article 32 (Security of processing) and in the technical and organisational measures (TOMs) required there. Classic examples: role and rights concepts, separated access for different functional areas, logging of sensitive access.
In practice in the software, that means: when each user account is created, a role is assigned. The role controls which areas of the software are visible, which records are loaded, which actions are allowed. Whoever has no role for an area doesn't even see it exists - which excludes not only unauthorised access, but unauthorised knowledge of it.
If your software processes personal data, the people concerned have rights: access, rectification, deletion, restriction, data portability, objection. We build these rights into the software from the start, rather than bolting them on afterwards. If someone wants access, there's a button for it. If someone demands deletion, there's a clean process - and no Excel list that lives on in an old backup.
And if something goes wrong - a data breach, a security incident, an inadvertent access - you'll be informed within 24 hours. That stands in the DPA, that's how we have it in our process. You don't need to panic, but clear information about what happened, what we're doing, and what your duties as controller are towards the supervisory authorities and the people concerned. Data protection in the serious case means: you aren't alone with it.
The rights of data subjects stand in Articles 15-22 GDPR. The obligation to report data breaches is set out in Article 33 GDPR: the controller has to report a data breach to the supervisory authority within 72 hours. So you can meet that, we as data processor have to inform you without delay - in our DPA, the deadline is set to 24 hours from becoming aware.
In practice, we build all software applications so that the rights of the people concerned can be exercised without manual intervention: an export of all one's own data for download, a delete button that actually removes the record (including derived copies), a switch for objection to specific processing. With that, you meet your duty and don't have to phone the technical team every time - which saves time, money, and avoids human error in the process.
Data protection isn't a feature you build in at the end. It's a build decision at the start - and it pays off across the whole lifetime of the software.
We don't build software for one year, but for the next five or ten. In that time, much will change: laws, threat landscapes, your workforce, your customers. What won't change is the fact that trust is the most expensive currency in the digital world - and that it's easier to lose than to gain. Data protection, the way we handle it, is our answer to that.
How AI is concretely deployed with us is on What actually is AI and What AI can't do, even when it looks like it can. Why we generally build the solid foundation first and only then the AI, you'll read on Tools first, AI second.