What standard means to us: that after the build you know exactly where your data lives, what the software decides, and why it feels like a good tool. For you, your team and your customers.
Before we build, we have a clear picture of what good software has to look like. Six hallmarks - they are our yardstick in everything.
They are spelled out on a page of their own. If you want to understand where this standard comes from, read on there - When is software actually good?.
Servers in Germany, databases in Frankfurt. No detour through America, no storage location you don't know the whereabouts of. Data protection under the GDPR isn't a checkbox for us - it's the architecture.
You get the data processing agreement with every service we use for you. You see who accesses what. And if you ever want to move on, we hand your data over to you - in full, in a format you can read in elsewhere.
This is governed by the General Data Protection Regulation (GDPR, in force since May 2018). Article 28 requires every external service provider to hold a written data processing agreement with you. Article 20 gives you the right to data portability - meaning: you may demand at any time that we hand you your data in a machine-readable format.
In concrete terms with us: database hosting at Supabase in the eu-central-1 region (Frankfurt). Application servers at IONOS in Germany. Email delivery via Resend - GDPR-compliant with its own processing agreement. More details on providers and contracts under How we handle data protection.
Original regulation text: eur-lex.europa.eu, Regulation (EU) 2016/679 .
When a bot in your software talks to someone, it says so. When a suggestion comes from a language model, it's marked. When a decision was prepared by AI, you can later trace what it saw and what it did - six months back.
From August 2026 the law requires that people can tell when they are talking to an AI system. We already build software today so that this date doesn't mean a phase of rebuilding.
We keep the six-month log for every AI feature - even where the law only requires it for higher-rated systems. Anyone who wants to know six months later who made a decision should be able to trace it. Full stop.
The EU AI Act is the first comprehensive regulation of artificial intelligence worldwide. Adopted in 2024, coming into force in stages. For most applications you run as a mid-sized business - chatbots, assistant systems, automatic classification - Article 50 applies from 2 August 2026: anyone interacting with an AI system must know it.
Article 12 requires, for higher-rated systems, a log over six months that makes traceable what the AI did. At wendwerk we apply this log to every AI feature, not only to high-risk systems. The reasoning isn't the AI Act alone - the GDPR (Article 30) requires a record of all processing activities anyway, and customers with compliance requirements will sooner or later ask: "Who decided this?"
A detailed explanation in plain language under The EU AI Act - what it means for you. Original regulation text: digital-strategy.ec.europa.eu .
Our software responds to every click in under half a second. Not because that's a nice figure, but because something magical happens at this threshold: you stop waiting on the computer and start thinking with it.
On the phone just as at the desk. Tap targets big enough to hit on the go. No horizontal swiping, no tables that are only legible on a monitor. When a customer opens your software on the phone on the train, it should feel just as good as in the office.
The 400-millisecond limit is called the Doherty Threshold, described by Walter Doherty and Ahrvind Thadani in the IBM Systems Journal in 1982. They showed back then: below this threshold productivity rises not linearly but in a leap - because the user stops waiting on the computer.
Today, Google's Core Web Vitals provide an internationally recognised way to measure website speed: under 2.5 seconds for the first visible content, under 200 milliseconds to respond to interaction. These values are the minimum - with us they apply to every project we ship.
Original Doherty study: research.ibm.com, IBM Systems Journal 1982. Core Web Vitals: web.dev/articles/vitals.
Login by email link. You enter your address, click the link in the mail, you're in. No password to forget, no sticky note on the screen, no 90-day change requirement. Anyone who still wants a password can set one up - it's an option, not the norm.
Who is allowed to see what is fixed in the database - not in the code, which could change tomorrow. Updates run without downtime. If something goes wrong, we roll back before you notice.
Magic links - the industry name for the email-link login - have become the standard for most business tools in 2026. The reason isn't convenience but security: an email link can only be used once, expires quickly and can't turn up in a data breach alongside millions of other passwords.
We check permissions with row-level security - the database itself decides which record is handed to whom. That's more robust than permission checks in the application code, because a forgotten check there would immediately be a hole. With us this separation exists everywhere personal data lives.
How we think about security overall is under Security - the yardstick, not the add-on.
You can explain what your software does - in a meeting with your data protection officer, a customer with compliance questions, or an auditor.
You aren't tied to a single provider. If we part ways, you get everything we built. The source code, the data, the contracts. No lock-in, no hidden key.
You're ready for August 2026 before it arrives. When others start bolting on banners and retrofitting logs, you've already got it.
Above all: your staff enjoy using the software. That's the only yardstick by which you can tell in the end whether it was really built well.
Standard doesn't mean "somehow compliant" to us - it means: we know what the research says, what the law demands, and what you'll need tomorrow.
Software that meets this standard is boring to describe. It has no wow effect in the demo video. But it's the reason why, a year later, you no longer wonder whether it works - only what you'll do with it next.
The thinking behind it is under When is software actually good?. How we clarify the real problem before building is under Before we build, we figure out what's broken. And which hurdles most often stand between good software and its actual use in companies is under The biggest hurdles are rarely in the technology.