WordPress-Plugin-Entwicklung: Selbst bauen oder kaufen?

Die meisten WordPress-Probleme lassen sich mit einem fertigen Plugin lösen. Im Verzeichnis von WordPress.org gibt es über 60.000 kostenlose Plugins, dazu Tausende weitere auf CodeCanyon und bei Herstellern direkt. Warum sollte ein seriöses deutsches Unternehmen also einer Agentur einen vier- oder fünfstelligen Betrag für eine individuelle WordPress-Plugin-Entwicklung zahlen?

Weil sich die übrigen 5 % der Probleme so nicht lösen lassen. Wer sie trotzdem in Standard-Plugins presst, landet bei einer „Frankenstein-Website“ mit 47 Plugins: langsam, fehleranfällig, datenschutzrechtlich fragwürdig und kaum wartbar.

Dieser Ratgeber zeigt, wann eine individuelle Plugin-Entwicklung für ein Mittelstandsunternehmen, ein deutsches SaaS-Start-up oder eine Berliner E-Commerce-Marke die richtige Entscheidung ist und wann sie Budget verschwendet. Wir behandeln realistische Preise 2026 in Euro, Architekturentscheidungen nach DSGVO, Zeitpläne, typische Fehler und die Auswahl von Entwicklern.

Was zählt als individuelle WordPress-Plugin-Entwicklung?

Ein individuelles Plugin ist jedes PHP-Paket, das WordPress um Funktionen erweitert, aber nicht aus einem öffentlichen Verzeichnis stammt. In der Praxis sehen wir vier Varianten:

1. Ein komplett neues Plugin, das etwas leistet, was kein bestehendes Plugin gut kann. Meist geht es um die Anbindung von WordPress an ein internes System (ERP, CRM, Lager, Ticketing).
2. Ein Fork oder Wrapper um ein bestehendes Plugin, um dessen Verhalten zu erweitern, einzuschränken oder umzubenennen, ohne seine Kerndateien zu ändern.
3. Ein „Verbindungs-Plugin“, das zwei oder mehr bestehende Plugins oder externe APIs verknüpft, zum Beispiel die Synchronisierung von WooCommerce-Bestellungen mit einem Lexware-Buchhaltungskonto.
4. Ein seitenspezifisches Funktions-Plugin, das den gesamten individuellen Code einer Website (Snippets, Hooks, Shortcodes) in einem versionierten Paket bündelt, statt ihn über die functions.php zu verstreuen.

Die ersten beiden sind am teuersten. Mit der dritten und vierten Variante steigen die meisten deutschen Kunden tatsächlich ein, und dort ist der ROI am schnellsten erreicht.

Wann sollten Sie ein Plugin selbst entwickeln lassen statt es zu kaufen?

Der ehrliche Test besteht aus fünf Fragen. Beantworten Sie eine davon mit „Ja“, kommt eine individuelle Entwicklung infrage. Beantworten Sie alle fünf mit „Nein“, kaufen Sie ein Plugin.

Gibt es die Funktion bereits in einem gepflegten Plugin?

Durchsuchen Sie zuerst das Verzeichnis von WordPress.org, CodeCanyon und die Produktseiten der drei größten deutschen WordPress-Agenturen. Seien Sie konkret. „Buchung“ ist zu allgemein. „Zweistufige Buchung mit deutscher Rechnungserstellung, USt-ID-Prüfung und SEPA-Lastschrift“ ist konkret genug, um festzustellen, dass eine Kombination bestehender Plugins vielleicht 80 % davon abdeckt.

Wenn etwas mindestens 80 % abdeckt und aktiv gepflegt wird (letztes Update innerhalb von 6 Monaten, über 5.000 aktive Installationen, Support auf Deutsch), kaufen Sie es. Investieren Sie das gesparte Budget in Konfiguration und Inhalte.

Erfüllt ein Standard-Plugin Ihre deutschen rechtlichen Anforderungen?

Hier scheitern die meisten US- und internationalen Plugins. Ein für den amerikanischen Markt gebautes Buchungs-Plugin erzeugt nicht automatisch GoBD-konforme Rechnungen, behandelt die Kleinunternehmerregelung (§ 19 UStG) nicht korrekt, speichert Kundendaten nicht in EU-Regionen und liefert keinen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO.

Wenn Ihre Plugin-Auswahl Sie bei deutschen Rechtsanforderungen zu Behelfslösungen zwingt, ist eine individuelle Entwicklung langfristig günstiger als das rechtliche Risiko.

Hängt Ihr Umsatz von dieser Funktion ab?

Wenn ein Plugin ausfällt und Ihre Website dadurch 500 € pro Tag an Buchungen oder Verkäufen verliert, ist es sehr teuer, einer von 80.000 Kunden zu sein, die auf einen Patch des Herstellers warten. Individuelle Plugins geben Ihnen die Kontrolle über Release-Zyklus, Patch-Zeitfenster und Priorität von Fehlern.

Müssen Sie ein geschlossenes oder internes System anbinden?

Anbindungen an SAP, DATEV, Lexware, Sage, JTL-Wawi, Shopware-Backends, ein internes ERP oder eine proprietäre API erfordern fast immer individuellen Code. Es gibt kein Standard-Plugin für „WordPress mit unserer Java-Eigenentwicklung von 2014 verbinden“.

Bremst das Lizenz- oder Nutzermodell eines bestehenden Plugins Ihr Wachstum?

Wir haben deutsche Kunden gesehen, die 4.800 € pro Jahr für ein Mitgliedschafts-Plugin zahlen, dessen Funktionen sie größtenteils nicht nutzen, nur weil der kostenlosen Alternative eine bestimmte Funktion fehlt. Eine einmalige individuelle Entwicklung für 6.000 € amortisiert sich innerhalb von 18 Monaten, und der Code gehört Ihnen.

Trifft nichts davon zu, sparen Sie sich das Geld und konfigurieren Sie bestehende Werkzeuge.

Was kostet individuelle WordPress-Plugin-Entwicklung in Deutschland?

Ehrliche Preisspannen für 2026 in Euro, basierend auf Agentursätzen in Berlin, München, Hamburg und Frankfurt sowie auf Nearshore-Entwicklern in Polen und Rumänien, die deutsche Kunden betreuen.

Umfang des Plugins	Typische Stunden	Preisspanne (Agentur)	Preisspanne (Nearshore)
Seitenspezifisches Funktions-Plugin	8–20	800–2.400 €	400–1.200 €
Plugin mit einem Zweck (ohne Integrationen)	30–80	3.000–9.500 €	1.800–5.500 €
API-Integrations-Plugin (WP → Lexware/DATEV)	60–150	6.000–18.000 €	3.500–10.500 €
Umfassendes Plugin mit Admin-Oberfläche und mehreren Rollen	120–300	12.000–36.000 €	7.000–21.000 €
Enterprise-Plugin (Multisite, mandantenfähig)	300–800+	30.000–100.000 €+	18.000–60.000 €+

Einige ehrliche Hinweise zu diesen Zahlen:

• Die Stundensätze deutscher Agenturen liegen 2026 bei rund 95–140 € pro Stunde für erfahrene WordPress-Entwickler.
• Nearshore (Polen, Rumänien, Ukraine, Teile Spaniens und Portugals) liegt bei 45–80 € pro Stunde für erfahrene WordPress-Arbeit.
• Reine Junior-Freelancer bieten 25–40 € pro Stunde an. Meiden Sie sie bei allem, was Abrechnung, Kundendaten oder zentrale Umsatzprozesse betrifft.
• Rechnen Sie im ersten Jahr rund 20 % zusätzlich für die laufende Wartung ein.

Der größte Kostenfaktor ist nicht die Entwicklung, sondern die Anforderungsanalyse. Ein schlecht definiertes Plugin kostet im dritten Monat das Doppelte. Bestehen Sie auf einer schriftlichen Spezifikation, bevor die erste Zeile Code entsteht.

Wie läuft der Entwicklungsprozess von Anfang bis Ende ab?

Ein sauberes Plugin-Projekt durchläuft sechs Phasen.

Phase 1: Anforderungsanalyse und Spezifikation (1–2 Wochen)

Sie setzen sich mit dem Entwickler oder der Agentur zusammen und beantworten Fragen, die sich langsam und mühsam anfühlen. Wer nutzt das Plugin? Welche Rollen brauchen Zugriff? Was passiert, wenn ein Nutzer in WordPress gelöscht wird, seine Plugin-Daten aber noch existieren? Wie wird der Datenexport nach DSGVO umgesetzt?

Ein Anforderungsdokument von 8 bis 15 Seiten ist für ein mittelgroßes Plugin normal. Überspringt die Agentur diesen Schritt und beginnt direkt mit dem Programmieren, suchen Sie sich eine andere: Sonst bezahlen Sie deren Lernkurve.

Phase 2: Architektur und Datenmodell (3–7 Tage)

Der Entwickler entwirft Datenbanktabellen, Custom Post Types, Taxonomien, Optionen, REST-API-Endpunkte, die Hook-Strategie und die Struktur der Admin-Oberfläche. Ein Plugin auf schlecht entworfenen eigenen Tabellen lässt sich später kaum ohne schmerzhafte Datenmigration umbauen.

Bei deutschen Projekten klären wir in dieser Phase immer: Datenspeicherung (nur EU), Verschlüsselung personenbezogener Daten im Ruhezustand, Aufbewahrungsregeln, Pseudonymisierungsstrategie und die Umsetzung der Hooks für Export und Löschung.

Phase 3: Kernentwicklung (2–8 Wochen)

Hier fließt der Großteil des Budgets. Code-Reviews finden alle 2 bis 3 Tage statt. Einige Anzeichen für eine gesunde Entwicklung:

• Das Plugin folgt den WordPress Coding Standards (WPCS) und besteht PHP_CodeSniffer
• Alle sichtbaren Texte sind internationalisiert (__(), _e() mit Textdomain)
• Datenbankabfragen nutzen $wpdb->prepare(), keine rohe String-Verkettung
• Keine Fehler im Strict Mode von PHP 8.2

Phase 4: Tests (1–3 Wochen)

Unit-Tests für die Kernlogik, Integrationstests mit einer echten WordPress-Installation, manuelle Qualitätssicherung in mehreren Browsern und Lasttests für alles, was Checkout oder Mitgliederbereiche betrifft. Bei deutschen Projekten testen wir ausdrücklich mit deutschem Locale, Sonderfällen bei Euro-Beträgen und DSGVO-Einwilligungsabläufen.

Phase 5: Deployment und Übergabe (3–7 Tage)

Das Plugin wird zuerst auf Staging und dann in die Produktivumgebung ausgerollt, bei Websites mit Live-Traffic hinter einem Feature-Flag. Die Dokumentation entsteht: Installationsanleitung, Konfigurationsleitfaden, Handbuch für Administratoren (oft auf Deutsch) und Übergabenotizen für Entwickler.

Phase 6: Nachbetreuung und Gewährleistung (typischerweise 4 Wochen)

Die Agentur bleibt für Fehler erreichbar, die im echten Betrieb auftreten. Danach wechseln Sie zu einem Wartungsvertrag oder zur Abrechnung pro Vorfall.

Wie lange dauert die Entwicklung eines individuellen WordPress-Plugins?

Die Dauer hängt vom Umfang ab und davon, wie schnell Ihr Team während der Entwicklung Fragen beantwortet. Ehrliche Spannen für 2026:

• Seitenspezifisches Funktions-Plugin: 1–2 Wochen
• Plugin mit einem Zweck: 3–6 Wochen
• API-Integrations-Plugin: 6–10 Wochen
• Umfassendes Plugin mit Admin-Oberfläche: 8–16 Wochen
• Enterprise-Plugin: 4–9 Monate

Der größte Zeitfresser sind langsame interne Entscheidungen. Ein wöchentlicher 45-minütiger Termin mit einer entscheidungsbefugten Person hält das Projekt in Bewegung.

Welche individuellen Plugins werden in Deutschland am häufigsten angefragt?

Nach Dutzenden Projekten mit deutschen Kunden wiederholen sich dieselben Muster.

ERP- und Buchhaltungsintegration

Die Anbindung von WooCommerce oder einem individuellen WordPress-Checkout an Lexware, DATEV, sevDesk, FastBill oder BuchhaltungsButler. Bestellungen gehen als Rechnungen hinaus, Zahlungen kommen als „bezahlt“ zurück. Die Komplexität steckt in Teilerstattungen, Gutschriften, der USt-ID-Prüfung und dem Reverse-Charge-Verfahren bei B2B-Verkäufen in der EU.

CRM- und Pipeline-Synchronisierung

Formulareinsendungen, Downloads und Angebotsanfragen werden aus WordPress an HubSpot, Pipedrive, CentralStationCRM, Salesforce oder ein internes CRM übertragen. Individuelle Felder, Lead-Scoring, Quellenzuordnung und Dublettenbereinigung, alles DSGVO-konform mit Einwilligungsnachweis und Widerrufs-Hooks.

B2B-Portale mit rollenbasierten Preisen

Ein angemeldeter Händler oder Distributor sieht andere Preise, Zahlungsbedingungen und Lagerbestände als ein Endkunde. Meist auf Basis von WooCommerce mit einer individuellen Plugin-Schicht für Staffelpreise, SKU-Einschränkungen je Kundengruppe und einen B2B-spezifischen Checkout.

Buchung und Ressourcenplanung

Standard-Buchungs-Plugins funktionieren für Friseure und Yogastudios. Schwierig wird es bei mehreren Standorten mit deutscher Adressprüfung, Mitarbeiterkalendern mit Outlook-365-Synchronisierung, Anzahlungs- und Restzahlungsrechnungen, GoBD-konformer Rechnungsnummerierung und Exporten für den Steuerberater.

Rechner und Angebotstools zur Lead-Gewinnung

Ein Konfigurator auf der Website eines Herstellers nimmt 12 Eingaben entgegen, wendet eine komplexe Preisformel an, erzeugt ein gebrandetes PDF-Angebot und sendet es an den Vertrieb, während gleichzeitig ein Lead im CRM angelegt wird. Und das alles, ohne die Preislogik öffentlich preiszugeben.

Individuelle Mitgliederbereiche und Zugriffsbeschränkungen

Wenn MemberPress oder Restrict Content Pro nicht zum Geschäftsmodell passen. Häufig betrifft das regulierte Branchen (Versicherungen, Finanzen, Gesundheitswesen), in denen der Zugriff von Berufsnachweisen, Verträgen oder unterzeichneten AVVs abhängt.

Individuelle Suche und Produktfinder

Vor allem für Industrie- und Mittelstands-Websites mit über 5.000 technischen Produkten, die eine parametrische Filterung brauchen („Edelstahlschraube, M8, 25 mm, DIN 933, A2-70“). Das geht weit über die Standardsuche oder einfache Plugins für facettierte Suche hinaus.

Was unterscheidet ein gutes individuelles WordPress-Plugin von einem schlechten?

Nach der Prüfung Dutzender individueller Plugins, die wir von früheren Agenturen übernommen haben, lassen sich die technischen Unterschiede zwischen „solide“ und „rausreißen und neu bauen“ auf eine kurze Checkliste reduzieren.

Ein gutes individuelles Plugin:

• liegt in einem eigenen Ordner unter /wp-content/plugins/ und ist nicht ins Theme gestopft
• nutzt eine Klassenstruktur mit Namespaces (PSR-4-Autoloading) und vermeidet globale Funktionen
• speichert Daten in gut entworfenen eigenen Tabellen mit Fremdschlüsseln und Indizes
• bietet eine dokumentierte PHP-API (Hooks, Filter, Methoden) für künftige Entwickler
• internationalisiert jeden Text mit einer Textdomain
• lässt sich sauber deinstallieren und entfernt seine Tabellen und Optionen, wenn der Administrator das wünscht
• hat eine readme.txt mit Changelog und Versionshistorie
• nutzt Composer für PHP-Abhängigkeiten von Drittanbietern
• enthält Unit-Tests, auch wenn es nur wenige sind

Ein schlechtes individuelles Plugin verstößt typischerweise gegen vier oder mehr dieser Punkte. Das häufigste Warnsignal ist ein Plugin, bei dem man zum Ändern der Konfiguration die PHP-Dateien bearbeiten muss: keine Admin-Oberfläche, keine Konstanten in der wp-config.php, nur fest einprogrammierte URLs und Zugangsdaten im Quellcode.

Wie prägt die DSGVO ein individuelles WordPress-Plugin?

Die DSGVO ist keine Funktion, die man am Ende ergänzt. Sie ist vom ersten Tag an eine architektonische Vorgabe. Für deutsche Kunden wenden wir fünf Regeln an.

Wo liegen personenbezogene Daten, und wer hat Zugriff?

Jedes Feld, das eine Person identifizieren kann (E-Mail, IP-Adresse, Name, Kundennummer, Geräte-ID), muss erfasst werden. Die Daten des Plugins müssen auf Servern in der EU liegen. Rollen und Berechtigungen legen fest, wer lesen, bearbeiten und exportieren darf.

Auf welcher Rechtsgrundlage beruht jeder Verarbeitungsvorgang?

Für jeden Vorgang muss der Plugin-Entwickler beantworten können: Ist es eine Einwilligung nach Art. 6 Abs. 1 lit. a, Vertragserfüllung (lit. b), eine rechtliche Verpflichtung (lit. c) oder ein berechtigtes Interesse (lit. f)? Lautet die Antwort „Weiß ich nicht“, ist das Plugin nicht fertig.

Wie funktioniert der Datenexport bei Auskunftsersuchen nach Art. 15?

WordPress stellt den Filter wp_privacy_personal_data_exporters bereit. Jedes individuelle Plugin, das personenbezogene Daten speichert, muss sich daran anbinden und die Datensätze des Nutzers strukturiert zurückgeben. Wir haben viele deutsche Websites geprüft, bei denen das offizielle Export-Tool für Plugin-Daten nichts liefert. Das ist ein Prüfbefund.

Wie funktioniert die Datenlöschung bei Anträgen nach Art. 17?

Wie beim Export, nur mit wp_privacy_personal_data_erasers. Das Plugin muss echte Löschung unterstützen oder, wo gesetzliche Aufbewahrungsfristen gelten (etwa 10 Jahre für Rechnungen nach GoBD), eine Pseudonymisierung mit klarem Protokoll der geschwärzten Daten.

Wie werden Einwilligung und Widerruf dokumentiert?

Verarbeitet das Plugin Daten auf Basis einer Einwilligung, muss es den Nachweis speichern: Zeitstempel, IP-Adresse (oder einen pseudonymisierten Hash), den Gegenstand der Einwilligung und die Version des Einwilligungstextes. Ein Widerruf muss über das Nutzerkonto oder einen klaren Kontaktweg möglich sein.

Ein Plugin, das diese fünf Punkte sauber umsetzt, kann ein Datenschutzbeauftragter ohne drei Abstimmungsrunden freigeben.

Wie wählen Sie einen Entwickler oder eine Agentur für die Plugin-Entwicklung aus?

Drei Filter helfen.

Haben sie bereits Plugins für deutsche Kunden produktiv ausgeliefert?

• Fragen Sie nach Fallstudien.
• Bitten Sie um eine Kundenreferenz, die Sie tatsächlich anrufen können.
• Sehen Sie sich die readme.txt und das Changelog eines früheren Plugins an.

Können sie keine tatsächlich ausgelieferte Arbeit zeigen, bezahlen Sie ihren ersten Versuch.

Verstehen sie WordPress jenseits des Customizers?

Fragen Sie: Wie würden Sie diese Daten speichern, als Custom Post Type, eigene Tabelle oder Option? Wie würden Sie eine Berichtsabfrage über 50.000 Zeilen umsetzen? Wie verhindern Sie, dass die Hooks des Plugins mit einem anderen Plugin kollidieren? Bleiben die Antworten vage, suchen Sie weiter.

Schützen ihre Verträge Ihre Rechte am Code?

Achten Sie darauf, dass der Vertrag ausdrücklich festhält: Der Code ist Auftragsarbeit, Sie erhalten eine Lizenz für den gesamten Quellcode, es gibt keine GPL-Inkompatibilitäten und keine Klauseln, nach denen die Agentur die Rechte behält. Eine seriöse deutsche Agentur bietet das standardmäßig an.

Was ist das Problem des „Plugin-Friedhofs“, und wie vermeiden Sie es?

Das ist der teuerste Fehlerfall. Das Plugin wird gebaut und geht live. Zwei Jahre später ist der Entwickler weg, die ursprüngliche Spezifikation verloren, das Plugin funktioniert unter PHP 8.3 nicht mehr, niemand weiß, wie man es repariert, und Sie stecken fest.

Vermeiden Sie das mit vier Vorgaben, die Sie im Projektvertrag verankern:

1. Quellcode in einem Git-Repository, das Ihnen gehört (GitHub, GitLab, Bitbucket, mit Ihrem Konto, nicht dem der Agentur).
2. Schriftliche Architekturentscheidungen, die erklären, warum die Datenbank so entworfen und warum dieser Hook gewählt wurde.
3. Ein Wartungsvertrag mit einem anderen Entwickler oder Team, damit Sie nicht an einen einzigen Anbieter gebunden sind.
4. Eine saubere Trennung zwischen Plugin-Kern und seitenspezifischer Konfiguration, damit sich das Plugin ohne 50 fest einprogrammierte Werte auf einer anderen Website einsetzen lässt.

Wenn Sie ein individuelles Plugin-Projekt starten, verankern Sie diese Punkte von Anfang an.

Kann ein individuelles WordPress-Plugin als Open Source veröffentlicht oder verkauft werden?

Ja. Für manche Mittelstandskunden mit internen Werkzeugen wird daraus sogar eine kleine Einnahmequelle. Plugins, die für einen internen Zweck entwickelt wurden, lassen sich bereinigen und kostenlos auf WordPress.org, kostenpflichtig auf CodeCanyon oder im Direktvertrieb anbieten.

Als Hauptziel lohnt sich das wirtschaftlich selten: Bis sich eine Plugin-Entwicklung für 15.000 € über Verkäufe refinanziert, vergehen Jahre. Als zusätzlicher Markenbaustein und Magnet für Bewerber ist es aber eine Überlegung bei der Architektur wert.

Wann sollten Sie auf individuelle Plugin-Entwicklung verzichten?

Nicht jede Plugin-Idee ist gut. Etwa jede fünfte Anfrage lehnen wir ab oder definieren sie aktiv neu, weil:

• ein kommerzielles Plugin für 40 € das Problem bereits sauber löst
• die Funktion in ein anderes System gehört (CRM, ERP, spezialisiertes SaaS) statt an WordPress angeflanscht zu werden
• das Unternehmen noch nicht geprüft hat, ob überhaupt jemand die Funktion will, und eine individuelle Entwicklung verfrüht ist
• WordPress für die Anforderung die falsche Plattform ist und ein anderer Stack (Headless, Next.js, Django) günstiger und besser wäre

Eine gute Agentur sagt Ihnen auch Nein. Ihr Ruf in drei Jahren ist ihr wichtiger als der Umsatz dieses Projekts.

Wie bleibt ein individuelles Plugin nach dem Launch gesund?

Plugins sind Software, und Software verfällt ohne Wartung. Ein gesundes individuelles Plugin erhält:

• monatliche Kompatibilitätsprüfungen mit neuen WordPress- und PHP-Versionen
• vierteljährliche Updates der Abhängigkeiten (Composer-Bibliotheken, gegebenenfalls JS-Pakete)
• eine jährliche Sicherheitsprüfung mit gezieltem PHP-Code-Audit
• Logging und Fehlerüberwachung (Sentry, Rollbar oder einfache Rotation von Logdateien)
• einen dokumentierten Release-Prozess, damit reguläre Änderungen die Produktivumgebung nicht beschädigen

Wir bündeln das in der Regel mit einem WordPress-Wartungsvertrag für die gesamte Website. Was solche Verträge in Deutschland umfassen und kosten, lesen Sie in unserem Ratgeber zu den Kosten der WordPress-Wartung, oder sehen Sie sich unsere Leistungen im Bereich Webentwicklung an.

Häufige Fragen zur individuellen WordPress-Plugin-Entwicklung

Bereit, Ihr Plugin-Projekt zu planen?

Individuelle WordPress-Plugin-Entwicklung ist eine echte Investition. Für das richtige Problem zahlt sie sich aber durch eingesparte Lizenzgebühren, geringere rechtliche Risiken und operative Vorteile um ein Vielfaches aus.

Wenn Sie abwägen, ob Sie selbst entwickeln oder kaufen sollen, ist ein 30-minütiges Gespräch der schnellste Weg zur Antwort: Wir sehen uns das Problem und den bestehenden Markt gemeinsam an. Buchen Sie einen Termin oder senden Sie uns die Details über unsere Kontaktseite. Sie erhalten eine schriftliche Empfehlung, selbst wenn sie lautet: „Bauen Sie das nicht, hier ist ein Plugin für 60 €, das die Aufgabe erledigt.“