Fehlerbericht‑Vorlage für Gründer, damit Fehler schneller behoben werden

Warum Ingenieure bei vagen Fehlerberichten stecken bleiben

Ein vager Fehlerbericht scheitert nicht, weil er kurz ist. Er scheitert, weil er zu viele mögliche Ursachen offenlässt. Entwickler raten am Ende, probieren zufällige Fixes oder verschwenden Zeit damit, Ihre exakte Situation wiederherzustellen.

„Ich habe ein bisschen geklickt und dann ging es kaputt“ verdeckt meist die wichtigen Details: auf welcher Seite Sie waren, was Sie geklickt haben, was Sie eingetippt haben und was Sie erwartet haben. Für einen Entwickler kann das ein Frontend‑Bug, ein Backend‑Fehler, ein Berechtigungsproblem, ein ungültiger Browser‑Cache oder ein einmaliger Netzwerk‑Glitch sein. Ohne klaren Reproduktionspfad wirkt der Fehler oft unsichtbar.

Selbst wenn der Fehler echt ist, tritt er möglicherweise nur unter bestimmten Bedingungen auf. Vielleicht betrifft er nur neue Accounts, nur nach einem Passwort‑Reset, nur einen bestimmten Plan oder nur, wenn ein Feld leer bleibt. Wenn diese Bedingungen nicht dokumentiert sind, testet das Team oft nur den Happy‑Path und schließt mit „funktioniert bei mir“ ab.

Sie müssen nicht technisch sein, um zu helfen. Ihre Aufgabe ist, spezifisch und konsistent zu sein, damit jemand anders Ihre Schritte nachvollziehen und denselben Fehler sehen kann.

Wenn Sie 5 Minuten haben, erledigen Sie diese wirkungsvollen Basics:

• Schreiben Sie die genauen Schritte, die Sie gemacht haben, eine Aktion pro Zeile
• Kopieren Sie den genauen Fehlertext (oder machen Sie einen Screenshot)
• Sagen Sie, was Sie erwartet haben vs. was passiert ist
• Notieren Sie Gerät und Browser, die Sie verwendet haben
• Versuchen Sie es in einem privaten Fenster, um zu sehen, ob es sich wiederholt

Ein klarer Bericht schlägt eine lange Nachricht immer. Eine Seite mit präzisen Schritten ist nützlicher als zehn Absätze Kontext.

Bei AI‑generierten Prototypen, die sich unvorhersehbar verhalten, ist Klarheit noch wichtiger. Kleine Details können große Fehler auslösen.

Was ein umsetzbarer Fehlerbericht enthält

Ein umsetzbarer Fehlerbericht ermöglicht es einem Entwickler, das Problem zu reproduzieren, die Auswirkung zu verstehen und zu wissen, wann die Behebung als erledigt gilt. Fehlt eine dieser drei Angaben, wird der Bericht zum Ratespiel.

Beginnen Sie damit, den Fehler leicht auffindbar zu machen. Nennen Sie den genauen Ort (Seite, Feature, Screen oder API‑Route) und die Aktion, die ihn auslöst. „Checkout schlägt fehl“ ist vage. „Checkout: Klick auf Pay im Shipping‑Schritt führt zu 500“ ist etwas, wonach ein Entwickler suchen kann.

Definieren Sie anschließend die Grenzen. Nennen Sie, was betroffen ist und was nicht. Das verhindert verschwendete Zeit mit Tests in irrelevanten Bereichen. Beispiele:

• Tritt nur bei neuen Nutzern auf; wiederkehrende Nutzer können bezahlen
• Bricht nur auf Mobilgeräten; Desktop ist in Ordnung

Fügen Sie die wesentlichen Angaben in einfacher Sprache hinzu:

• Wo es passiert (Screen, URL‑Pfad oder Feature‑Name)
• Wie man es reproduziert (eine kurze Abfolge, der jemand folgen kann)
• Was Sie erwartet haben vs. was tatsächlich passiert ist
• Wie dringend es ist (blockierter Verkauf, kleiner UI‑Fehler, seltene Edge‑Case)
• Was „done“ bedeutet (das genaue Ergebnis, das Sie nach der Behebung sehen wollen)

Ein guter Bericht zeigt außerdem die Auswirkung ohne Drama. „Nutzer können sich nicht einloggen, daher erreichen sie das Dashboard nicht“ ist hilfreicher als „Das ist kritisch!!!“. Wenn Sie Zahlen haben, fügen Sie sie hinzu: „3 von 5 Test‑Accounts trifft es.“

Halten Sie es testbar. Wenn der Bericht um eine Behebung bittet, aber keine Beschreibung, wie geprüft wird, ob sie funktioniert, kann der Entwickler nicht sicher ausliefern. Eine einfache „done“-Formulierung hilft, z. B.: „Ein brandneuer Nutzer kann sich registrieren, E‑Mail bestätigen und ohne Fehler den Home‑Screen erreichen."

Wenn Sie eine AI‑generierte Codebasis verwenden (z. B. aus Tools wie Cursor oder Replit), geben Sie diesen Kontext ebenfalls an. Er beeinflusst oft, wo Entwickler zuerst nachsehen und kann Umfang und Risiko verändern.

Die gründfreundliche Fehlerbericht‑Vorlage (kopieren und ausfüllen)

Verwenden Sie diese Vorlage, wenn Sie möchten, dass ein Entwickler das Problem schnell reproduziert und ohne langes Hin und Her beheben kann.

TITLE
[What broke] in [where: page/feature] for [who: user type]
Example: “Checkout error on Payment step for logged-in users”

IMPACT
- Who is blocked:
- How often it happens (every time / sometimes / first time today):
- Business effect (can’t sign up, can’t pay, data wrong, security risk):

STEPS TO REPRODUCE (numbered, exact)
1) Start state (logged out/in, which account, which plan):
2) Go to:
3) Click/type:
4) Select:
5) Submit/refresh/wait:

EXPECTED VS ACTUAL (one sentence each)
Expected:
Actual:

ENVIRONMENT (what you used when it failed)
- Device (phone/laptop, model if known):
- OS version:
- Browser + version (or app version):
- Account type/role (admin, member, trial, paid):
- Time it happened + timezone:

SMALLEST REPRODUCIBLE CASE
What is the minimum setup that still fails?
- Smallest test account/data needed:
- One setting/flag that seems required:
- Minimal path (fewest steps) that still triggers it:

NOTES (optional)
- First time you noticed it:
- Recent changes (new prompt-generated code, new deploy, new integration):
- Workaround (if any):

Tipp: Wenn Sie es in einem frischen Test‑Account mit einem Beispiel‑Datensatz reproduzieren können, fügen Sie das hinzu. Das halbiert oft die Debugging‑Zeit.

Schritt für Schritt: wie man Reproduktionsschritte schreibt

Reproduktionsschritte sind der schnellste Weg, eine Beschwerde in eine Behebung zu verwandeln. Das Ziel ist einfach: Machen Sie es möglich, dass jemand, der Ihre App noch nie gesehen hat, denselben Fehler in unter 2 Minuten findet.

Starten Sie aus einem sauberen Zustand, damit Ihre Schritte dem entsprechen, was die meisten Nutzer erleben. Das heißt meist: ausloggen, hart neu laden oder einen neuen Tab öffnen (privates/incognito hilft). Wenn der Fehler davon abhängt, eingeloggt zu sein, sagen Sie das und geben Sie an, welche Nutzerrolle verwendet wurde.

Schreiben Sie die Schritte wie ein Rezept, nicht wie eine Geschichte. Verwenden Sie die genauen Bezeichnungen aus dem UI: Seitentitel, Button‑Labels, Feldnamen und Menüpunkte. Wenn Ihr UI „Create workspace“ sagt, Sie aber „add a space“ schreiben, landet ein Entwickler leicht an der falschen Stelle.

Eine kurze Checkliste, die Sie wiederverwenden können:

• Auf sauberen Zustand zurücksetzen (ausloggen, neu laden, neuer Tab)
• Gehen Sie davon aus, dass der Leser neu im Produkt ist
• Verwenden Sie exakte UI‑Texte (Buttons, Seiten, Felder)
• Geben Sie die eingegebenen Daten an (E‑Mail, Plan, Beispiel‑Input)
• Stoppen Sie beim ersten Moment, an dem der Fehler erscheint

Ein konkretes Beispiel (guter Detailgrad): Sie öffnen ein neues Inkognito‑Fenster, gehen zur Login‑Seite, melden sich mit [email protected] (Admin) an, klicken im linken Menü auf „Billing“, klicken „Upgrade plan“, wählen „Pro“ und klicken „Confirm“. Der Fehler tritt direkt nach „Confirm“ auf (Seite friert ein und der Spinner hört nie auf).

Eine Änderung, die sofort hilft: Vermischen Sie nicht Symptome und Vermutungen in den Schritten. Halten Sie die Schritte sauber und sammeln Sie Ihre Gedanken separat unter „Notes“.

Erwartetes vs. tatsächliches Verhalten (machen Sie es eindeutig)

Der schnellste Weg zu einer Behebung ist, das gewünschte Ergebnis (erwartet) und das tatsächlich erhaltene Ergebnis (tatsächlich) in klaren, testbaren Worten zu beschreiben. Denken Sie an „erwartet“ als Nutzerziel, nicht als technischen Aufbau.

Expected sollte wie ein einfaches Versprechen an den Nutzer klingen. Gut: „Nach Klick auf Pay wird die Bestellung erstellt und ich sehe eine Bestätigungsseite mit Bestellnummer.“ Nicht ideal: „Der Stripe‑Webhook sollte feuern und die DB aktualisieren.“ (Das ist eine Implementierungsvermutung.)

Actual ist das, was Sie sehen und kopieren können. Fügen Sie exakten Fehltext, Button‑Labels und das, was die Seite anzeigt, bei. Wenn es eine Fehlermeldung gibt, fügen Sie sie wortgetreu ein. Wenn keine angezeigt wird, sagen Sie das auch.

Partielle Fehler sind wichtig. Viele Bugs sind „es funktioniert, aber …“‑Fälle: es loggt ein, zeigt aber das falsche Konto; es speichert, verändert aber das Datum; es lädt hoch, verliert aber den Dateinamen. Nennen Sie, was funktioniert und was falsch ist, damit Entwickler nicht beim ersten Erfolg stehen bleiben.

Für eine leichte Lesbarkeit dieses Abschnitts dieses Mini‑Format verwenden:

• Erwartet: (ein Satz Nutzerergebnis)
• Tatsächlich: (was Sie gesehen haben, exakter Text)
• Häufigkeit: every time / sometimes / first time only (geben Sie % an, wenn möglich)
• Was ich versucht habe: (Passwort zurücksetzen, anderer Browser, neu laden, etc.)

Beispiel: Erwartet: „Ein Invite sendet innerhalb 1 Minute eine E‑Mail.“ Tatsächlich: „Toast sagt ‚Invite sent‘, aber es kommt keine E‑Mail. Keine Fehlermeldung. Der Nutzer erscheint in der Liste mit Status Pending.“ Häufigkeit: „Tritt 3 von 5 Mal auf.“ Was ich versucht habe: „Zwei E‑Mails getestet, 10 Minuten gewartet, Spam geprüft, einmal erneut versucht."

Umgebung—Details, die Entwickler wirklich brauchen

Wenn ein Fehler nur bei manchen Leuten auftritt, ist der schnellste Weg zu einer Lösung, die exakte Setup‑Beschreibung zu liefern, in der er auftritt. Ohne das können Entwickler Stunden mit Tests auf falschem Gerät, falschem Account‑Typ oder falschem Netzwerk verbringen.

Fügen Sie diese Basics hinzu, wenn möglich:

• Browser + Version (z. B. Chrome 121, Safari 17). Bei Apps: App‑Version.
• Gerät + OS (z. B. iPhone 14 mit iOS 17.2, Windows 11 Laptop, macOS 14).
• Account‑Status (neuer Nutzer vs. bestehender, Admin vs. Member, zahlender vs. gratis, eingeladen vs. Selbstregistrierung).
• Zeitfenster + Zeitzone (z. B. „18. Jan, 09:30–10:00 PT“). Das hilft beim Abgleich mit Server‑Logs.
• Netzwerkhinweise (Home‑WLAN vs. Büro, Mobilfunk, VPN an/aus, Land). Manche Fehler treten nur hinter bestimmten VPNs oder in bestimmten Regionen auf.

Ein einfacher Weg: Kopieren Sie den „About“‑ oder Versions‑Screen Ihres Browsers/App und fügen Sie eine Zeile hinzu, mit welchem Account Sie eingeloggt waren.

Beispiel:

„Tritt auf Safari 17.1 auf iPhone (iOS 17.2) auf. Funktioniert auf Chrome 121 auf meinem Mac. Ich bin als bestehender zahlender Admin eingeloggt. Passiert heute gegen 10:15am ET. VPN an (US‑Standort).“

Wenn Sie eine AI‑generierte App geerbt haben und das Verhalten je nach Browser oder Account variiert, ist das ein starker Hinweis auf versteckte Edge‑Cases. Viele Teams beginnen in so einem Fall damit, Ihre exakte Umgebung nachzustellen, patchen die Logik und härten die kritischen Stellen, damit der Fehler nicht wiederkehrt.

Das kleinste reproduzierbare Beispiel finden

Ein „kleinstes reproduzierbares Beispiel“ ist der kürzeste Pfad, der denselben Fehler auf dieselbe Weise auslöst, jedes Mal. Entwickler können schneller beheben, wenn sie das Problem auf Abruf auslösen können, ohne zu raten, welches Detail wichtig war.

Beginnen Sie damit, alles zu entfernen, was nicht nötig ist, damit der Fehler auftritt. Wenn Sie einen Schritt weglassen können und der Fehler immer noch auftritt, war dieser Schritt Rauschen. Wenn eine Seite drei Aktionen hat, versuchen Sie, den Auslöser auf den einzelnen Klick, das Form‑Submit oder den API‑Call zu reduzieren.

Ein praktischer Weg, das Problem zu verkleinern, ist ein sauberer Setup‑Wechsel. Reale Kundendaten sorgen oft für Verwirrung (Berechtigungen, alte Einträge, Edge‑Cases). Verwenden Sie ein frisches Test‑Account und nur einen einfachen, reproduzierbaren Beispielinput.

Eine Methode, die auch ohne Technikkenntnisse funktioniert:

• Reproduzieren Sie den Fehler einmal und schreiben Sie alle Schritte auf
• Wiederholen Sie ihn, überspringen Sie einen Schritt (oder verwenden Sie einfachere Daten), um zu sehen, ob er weiterhin auftritt
• Wechseln Sie zu einem frischen Test‑Account und benutzen Sie den simpelsten Input
• Reduzieren Sie es, wenn möglich, auf eine Seite und eine Aktion
• Behalten Sie genau den einen Beispiel‑Input, der den Fehler zu 100% auslöst

Dann schreiben Sie zwei Versionen der Schritte: den minimalen Pfad und die vollständige Geschichte. Der minimale Pfad ist das, was ein Entwickler zuerst ausführt; die vollständige Geschichte liefert Kontext, warum es wichtig ist.

Beispiel: Der Signup Ihrer AI‑gebauten App schlägt nur bei einigen Nutzern fehl. Die vollständige Geschichte könnte Einladungen, einen kostenpflichtigen Plan und eine bestimmte E‑Mail‑Domain beinhalten. Das kleinste reproduzierbare Beispiel könnte sein: „Neuer Test‑Account -> Signup -> E‑Mail [email protected] eingeben -> Submit -> Error."

Beweismittel: Fehler, Screenshots und Aufnahmen ohne Rauschen

Gute Beweismittel verwandeln ein „Kannst du das fixen?“ in etwas, womit Entwickler sofort arbeiten können. Ziel: Machen Sie das Scheitern offensichtlich und erleichtern Sie das Abgleichen mit Logs.

Kopieren Sie zuerst den genauen Fehltext. Nicht paraphrasieren. Fügen Sie ihn mit derselben Interpunktion, Wortwahl und allen Codes ein. Wenn die UI eine ID zeigt (Order‑ID, User‑ID, Invoice‑Nummer, Workspace‑Name), fügen Sie sie hinzu. Solche Strings lassen Entwickler oft in Sekunden den passenden Log‑Eintrag finden.

Screenshots helfen am meisten, wenn sie Kontext zeigen. Ein stark beschnittener Error‑Toast kann irreführend sein, weil er nicht zeigt, auf welcher Seite Sie waren und welche Felder ausgefüllt waren. Erfassen Sie den gesamten Bildschirm, inklusive URL‑Bar bei Web‑Apps, und die sichtbaren Inputs.

Aufnahmen sind noch besser, wenn das Problem vom Timing oder einem speziellen Klickpfad abhängt. Kurz halten (20–60 Sekunden), aber die Vorbereitungs‑Schritte und den genauen Moment des Fehlers zeigen.

Am nützlichsten, in Reihenfolge:

• Exakter Fehlermeldungstext (kopieren/einfügen) plus sichtbare IDs
• Vollbild‑Screenshot direkt nach Auftreten
• Kurze Bildschirmaufnahme, die Schritte und Fehler zeigt
• Die eingegebenen Werte (ohne Geheimnisse)
• Ein Zeitstempel und Ihre Zeitzone (hilft beim Abgleich mit Logs)

Beispiel: „Checkout schlägt fehl mit ‚Payment session invalid.‘ Order ID: 18492. Screenshot zeigt Checkout‑Seite mit angewendetem Coupon. Aufnahme zeigt: Cart -> Apply coupon SAVE10 -> Pay -> error. Testkarte endet mit 4242. Keine echten Kundendaten."

Wenn Sie Formularwerte teilen, entfernen Sie Passwörter, API‑Keys und vollständige Kartennummern. Ersetzen Sie sie durch Platzhalter wie [REDACTED].

Beispiel: ein realistischer Fehlerbericht von einem Gründer

Hier ist ein ausgefülltes Beispiel. Szenario: Ein neuer Nutzer versucht sich zu registrieren, bleibt aber in einer Passwort‑Reset‑Schleife hängen.

Title
- Signup sends users into password reset loop

Impact
- New users cannot create accounts. This blocks onboarding and sales demos.

Urgency
- High (we have 3 demos tomorrow). If there’s a safe workaround, that’s fine for now.

Where it happens
- /signup page and the “Forgot password” email link

Reproduction steps
1) Open the app in Chrome.
2) Go to /signup.
3) Enter a new email that has never signed up before.
4) Enter a password (any).
5) Click “Create account”.
6) You see “Account already exists. Reset your password”.
7) Click “Reset password”.
8) Open the reset email and click the link.
9) After setting a new password, you return to /signup and step 6 happens again.

Expected behavior
- Step 5 creates a new account and logs the user in.

Actual behavior
- The app claims the account exists and forces password reset, but the reset does not allow signup to complete.

Environment
- Browser: Chrome 121 (also reproduced on Safari iOS 17)
- Device: MacBook + iPhone
- Account state: email never used before
- Time: started today around 10:30am local

Evidence
- Error shown: “Account already exists. Reset your password”
- Console error: POST /api/auth/signup 409
- Server log snippet: Unique constraint failed on users.email

Workaround tried
- Tried a different email. Same behavior.
- Cleared cookies. No change.

Notes
- Project was generated with an AI tool and then edited in Cursor.

Details, die Gründer oft am Anfang übersehen: ob die E‑Mail jemals benutzt wurde (auch in Staging), ob das Problem in einem anderen Browser auftritt und der genaue Fehlercode (409 ist relevant).

Wie das kleinste reproduzierbare Beispiel es eingrenzt: „Neue E‑Mail + Klick Create account = 409 auf /api/auth/signup jedes Mal.“ Das deutet direkt auf doppelte Nutzererstellung oder ein vermischtes Signup/Reset‑Flow hin.

Die Auswirkung und Dringlichkeit sind klar, ohne Rauschen: es blockiert Onboarding und es gibt eine Deadline.

Häufige Fehler (und wie man sie vermeidet)

Die meisten langsamen Bugfixes sind keine „schweren Bugs“. Es fehlen Details. Eine Vorlage dient hauptsächlich dazu, das Raten zu eliminieren, damit ein Entwickler den Fehler schnell reproduzieren kann.

1) Die Schritte starten von einem unscharfen Punkt

Wenn Ihre Schritte mit „App öffnen“ oder „einloggen“ beginnen, weiß der Entwickler nicht, in welchem Zustand Sie waren. Beginnen Sie mit einem klaren Startpunkt: welche Seite, welcher Account (Admin vs. regulär) und ob die Daten schon existierten.

Einfacher Fix: Fügen Sie eine Zeile vor den Schritten hinzu wie „Startzustand: eingeloggt als Free‑Plan‑User, auf der Settings‑Seite, ohne Team angelegt."

2) Sie paraphrasieren den Fehler (oder lassen ihn weg)

„Server error“ und „es ist abgestürzt“ reichen nicht. Kopieren Sie die exakte Fehlermeldung. Wenn ein Code vorhanden ist (500, 401, „JWT expired“, „SQLSTATE“), fügen Sie ihn ein. Genaue Worte führen oft zu einer spezifischen Datei oder einem Dienst.

3) Sie kombinieren mehrere Probleme in einem Bericht

Entwickler können eine Sache schnell fixen oder drei Dinge langsam. Wenn Login fehlschlägt und das Dashboard langsam lädt, machen Sie zwei Berichte. Wenn Sie nicht sicher sind, ob sie zusammenhängen, sagen Sie das, aber halten Sie sie getrennt.

Häufige Fehler und schnelle Lösungen:

• Zu viele Schritte: Streichen Sie alles, was das Ergebnis nicht ändert
• Fehlender Auslöser: Schreiben Sie den genauen Klick, die Eingabe oder den API‑Call, der es verursacht
• Kein erwartetes Ergebnis: Sagen Sie, was geschehen sollte
• Keine Umgebung: Geben Sie Gerät, Browser und Build/Version an
• Sensible Daten enthalten: Ersetzen Sie durch Fake‑Werte und vermerken Sie die Änderung

4) Sie teilen Geheimnisse oder private Nutzerdaten

Gründer fügen oft Logs mit API‑Keys, Cookies oder echten E‑Mails ein. Schwärzen Sie vor dem Senden alles Sensible. Bei AI‑generierten Apps (z. B. Bolt, v0, Cursor oder Replit) sind exponierte Secrets häufig — seien Sie besonders vorsichtig.

5) Sie melden das Symptom, nicht den Auslöser

„Es speichert nicht“ ist ein Symptom. Der Auslöser ist: „Ich tippe X in Feld Y, klicke Speichern und nach dem Refresh ist die Änderung weg.“ Wenn Sie es auf das kleinste reproduzierbare Beispiel reduzieren, folgt meist schnell die Behebung.

Schnelle Checkliste und nächste Schritte

Wenn Sie nur eines tun: Verwenden Sie eine konsistente Vorlage, damit jeder Bericht die Details enthält, die ein Entwickler braucht, um zu reproduzieren und zu beheben.

Copy‑paste Schnell‑Checkliste

• Titel + Auswirkung: Was kaputt ist und was es blockiert (Checkout scheitert, Signup hängt, Daten falsch)
• Schritte zur Reproduktion: Nummeriert, genaue Klicks und Eingaben, Startpunkt klar
• Erwartetes Verhalten: Was passieren sollte (ein Satz)
• Tatsächliches Verhalten: Was stattdessen passiert (inkl. exakter Nachricht, falls vorhanden)
• Beweis: Ein sauberer Screenshot/Recording oder der Schlüssel‑Fehlertext (kein Rauschen)

Bevor Sie es abschicken, fügen Sie die Umgebungsdetails hinzu, die oft erklären, warum es „auf meinem Rechner“ funktioniert: Gerätetyp, OS‑Version, Browser und Version (oder App‑Version), genutzter Account/Rolle und Zeitpunkt (mit Zeitzone, wenn das Team verteilt ist).

Endkontrollen (dauert 60 Sekunden)

• Repro‑Test: Kann jemand anderes es in unter 2 Minuten ohne Raten nachmachen?
• Kleinster Fall: Entfernen Sie optionale Schritte, bis es im simpelsten Ablauf bricht
• Sicherheit: Entfernen Sie Passwörter, API‑Keys, Tokens und persönliche Daten aus Screenshots/Logs
• Neuer Versuch: Probieren Sie es einmal in einem privaten Fenster oder nach Logout/Login und notieren Sie das Ergebnis
• Bei AI‑generiertem Code: Wenn Fehler sich stapeln (kaputte Auth, geleakte Secrets, chaotische Struktur), starten Sie mit einer fokussierten Diagnose

Wenn Ihre App mit AI‑Tools gebaut wurde und in Produktion ständig ausfällt, kann FixMyMess (fixmymess.ai) helfen, die Codebasis zu diagnostizieren, kaputte Logik zu reparieren und Sicherheitsprobleme zu härten. Wenn Sie zuerst eine klare Karte der Probleme wollen, ist ihr kostenloses Code‑Audit genau dafür gedacht.