# Programmierer beauftragen: Auftrag beschreiben mit Vorlage

> Einen Programmierer beauftragst du am besten mit einer schriftlichen Beschreibung auf einer Seite: Ziel, Ist-Zustand mit System und Version, gewünschtes Ergebnis, ein prüfbares Abnahmekriterium, Zugänge, Termin und Budgetrahmen. So bekommst du vergleichbare Angebote. Für kleine Aufträge reicht ein Werkvertrag per E-Mail, wenn Leistung, Preis und Abnahme klar darin stehen.

- URL: https://kleinerauftrag.de/auftrag-beschreiben/programmierer-beauftragen/
- Sprache: de
- Aktualisiert: 2026-10-19
- Herausgeber: Kleiner Auftrag (OnlineBuilders LLC, https://onlinebuilders.biz)

Die meisten Rückfragen, die ein Entwickler vor einem Angebot stellt, haben mit Technik wenig zu tun. Er will wissen, wo die Seite liegt, wer die Zugänge hat, welche Version läuft und woran du merkst, dass die Arbeit erledigt ist. Das weißt nur du.

Kommt die Antwort erst nach drei Mails, ist der Auftrag oft schon beim nächsten gelandet. Oder das Angebot enthält einen dicken Puffer für alles, was unklar war. Beides kostet dich Geld.

## Was ein Programmierer vor dem Angebot wissen muss

Ein Angebot ist eine Schätzung unter Unsicherheit. Je mehr Unsicherheit du vorher wegnimmst, desto kleiner wird der Aufschlag, den ein vorsichtiger Entwickler einplant. Neun Angaben decken bei kleinen Aufträgen fast alles ab:

1. **Ziel:** das Problem, nicht deine Lösungsidee. „Bestellungen aus dem Shop sollen ohne Abtippen in der Buchhaltung landen“ ist besser als „bau mir eine API“.
2. **Ist-Zustand:** System, Version, Hosting, relevante Plugins oder Dienste. Ein Screenshot der Systeminfo spart eine Mail.
3. **Gewünschtes Ergebnis:** was danach anders ist, aus Sicht eines Nutzers beschrieben.
4. **Abnahmekriterium:** ein oder zwei Sätze, die man prüfen kann. Mehr dazu in den [Beispielen für Akzeptanzkriterien](https://kleinerauftrag.de/auftrag-beschreiben/akzeptanzkriterien-beispiele/).
5. **Nicht enthalten:** was ausdrücklich nicht dazugehört. Das ist die Zeile, die später am meisten Streit verhindert.
6. **Zugänge:** welche du bereitstellen kannst und wie. Wie das ohne Passwort-Mail geht, steht unter [Zugangsdaten sicher weitergeben](https://kleinerauftrag.de/abwicklung/zugangsdaten-sicher-weitergeben/).
7. **Termin:** bis wann es fertig sein muss und warum. Ein echter Grund (Messe, Kampagnenstart) wird ernster genommen als „asap“.
8. **Budgetrahmen:** eine Spanne genügt.
9. **Ansprechpartner:** wer Fragen beantwortet und wer abnimmt. Wenn das zwei Personen sind, schreib beide hin.

Bei einem Fehler, der behoben werden soll, ersetzt ein sauberer [Fehlerbericht](https://kleinerauftrag.de/auftrag-beschreiben/fehlerbericht-schreiben/) die Felder zwei und drei.

## Vorlage: Auftragsbeschreibung für einen kleinen IT-Auftrag

Kopier dir den Block in eine Mail oder ein Dokument. Lass Felder lieber leer und markier sie mit „weiß ich nicht“, als zu raten. Ehrliche Lücken kann ein Entwickler einschätzen. Falsche Angaben nicht.

```text
Betreff: Angebot für [kurze Bezeichnung], Umsetzung bis [Datum]

1. Ziel
   Warum soll sich etwas ändern? (1–3 Sätze)

2. Ist-Zustand
   System/Version:      z. B. WordPress 6.x, WooCommerce, PHP-Version laut Hoster
   Hosting:             Anbieter, Tarif, wer den Vertrag hat
   Beteiligte Dienste:  z. B. Zahlungsanbieter, Newsletter-Tool, Warenwirtschaft

3. Gewünschtes Ergebnis
   Was soll ein Nutzer danach tun können oder sehen?

4. Abnahmekriterium
   Fertig ist es, wenn ... (prüfbar, mit Beispielwerten)

5. Nicht enthalten
   z. B. Design-Überarbeitung, Texte, Übersetzung, Schulung

6. Zugänge
   Admin-Konto / SFTP / Staging vorhanden? Wie übergebe ich sie?

7. Termin
   Spätestens am ... weil ...

8. Budgetrahmen
   ca. ... bis ... Euro netto

9. Ansprechpartner
   Fragen: Name, Telefon / Abnahme: Name
```

Die Vorlage passt auf eine Seite, und das ist Absicht. Wer drei Seiten Fließtext bekommt, überfliegt sie. Knapp und konkret wird gelesen.

## Beispiel: aus einem Satz wird eine brauchbare Beschreibung

So kommen viele Anfragen an: „Unser Kontaktformular geht nicht mehr, kannst du das schnell fixen?“ Darauf kann niemand seriös einen Preis nennen. Liegt es am Mailversand des Hosters, an einem Plugin-Update, am Spam-Schutz? Jede Ursache bedeutet einen anderen Aufwand.

Die gleiche Anfrage mit der Vorlage:

- **Ziel:** Anfragen über das Kontaktformular sollen wieder im Postfach ankommen.
- **Ist-Zustand:** WordPress mit Contact Form 7, Hosting bei einem Shared-Hoster. Seit dem Plugin-Update vor zwei Wochen kommen keine Mails mehr an, das Formular zeigt trotzdem „Danke für Ihre Nachricht“.
- **Abnahmekriterium:** Drei Testnachrichten von unterschiedlichen Adressen kommen innerhalb von fünf Minuten in info@ an und landen nicht im Spam.
- **Nicht enthalten:** neues Formular-Design, zusätzliche Felder.

Jetzt kann ein Entwickler sagen: Wahrscheinlich Mailversand per PHP-Funktion statt SMTP, Umstellung und Test etwa eine bis zwei Stunden. Das ist eine Schätzung, die du mit einem zweiten Angebot vergleichen kannst.

**Vom Problem zum vergleichbaren Angebot**

1. **Problem notieren** Was passiert, seit wann, wer merkt es? Ein Screenshot dazu.
2. **Vorlage ausfüllen** Neun Felder, unbekannte als **weiß ich nicht** markieren.
3. **Gleiche Beschreibung an zwei Anbieter** Rückfragen beantwortest du beiden, damit die Angebote vergleichbar bleiben.
4. **Angebot prüfen** Steht dein Abnahmekriterium drin? Ist klar, was nicht enthalten ist?
5. **Schriftlich bestätigen** Eine Mail mit Leistung, Preis, Termin und Abnahme genügt.

## Werkvertrag oder Dienstvertrag: was du eigentlich beauftragst

Rechtlich gibt es zwei Grundformen. Beim Werkvertrag nach [§ 631 BGB](https://www.gesetze-im-internet.de/bgb/__631.html) schuldet der Programmierer ein Ergebnis: das Formular funktioniert wieder. Beim Dienstvertrag nach § 611 BGB schuldet er nur die Arbeit, bezahlt wird die Zeit, egal ob das Ziel erreicht ist.

Für kleine, klar abgegrenzte Aufgaben ist der Werkvertrag üblich. Laut einer Auswertung von freelancermap vom September 2026 laufen rund 70 Prozent der ausgeschriebenen Entwicklerprojekte im DACH-Raum als Werkvertrag. Für dich hat das einen handfesten Vorteil. Die Vergütung wird erst mit der Abnahme fällig, und mit der Abnahme beginnt die Frist für Mängelansprüche. Wie du die sauber dokumentierst, steht im Beitrag zum [Abnahmeprotokoll für Software](https://kleinerauftrag.de/abwicklung/abnahmeprotokoll-software/).

Ein Werkvertrag braucht keine Unterschrift auf Papier. Eine Mail, in der Leistung, Preis und Termin stehen, und eine bestätigende Antwort reichen. Wichtig ist nur, dass beide dasselbe meinen.

Ob du einen Festpreis oder Abrechnung nach Aufwand vereinbarst, ist eine eigene Frage. Bei unklarer Ursache, etwa einem Fehler im fremden Code, ist ein Stundenbudget mit Obergrenze oft ehrlicher. Die Abwägung haben wir unter [Festpreis oder Stundensatz](https://kleinerauftrag.de/kosten/festpreis-oder-stundensatz/) durchgerechnet.

## Drei Formulierungen, die Angebote teurer machen

Manche Wörter in einer Auftragsbeschreibung lösen bei Entwicklern sofort einen Risikoaufschlag aus. Nicht aus Böswilligkeit, sondern weil sie offenlassen, wie groß die Aufgabe wirklich ist.

„So ähnlich wie bei Amazon.“ Hinter so einem Vergleich stecken Jahre an Entwicklung. Beschreib lieber die eine Funktion, die dir dort gefällt, mit einem Screenshot.

„Nur eine kleine Anpassung.“ Ob etwas klein ist, entscheidet der Code, nicht der Wunsch. Lass das Wort weg und beschreib das Ergebnis.

„Soll später erweiterbar sein.“ Erweiterbar wofür? Wenn du schon weißt, dass im nächsten Quartal ein zweiter Zahlungsanbieter dazukommt, schreib genau das hin. Wenn nicht, streich den Satz. Vorbauen für unbekannte Anforderungen ist der zuverlässigste Weg, für Code zu zahlen, den nie jemand nutzt.

## Was vor dem Start erledigt sein sollte

Bei kleinen Aufträgen frisst Vorbereitung schnell einen spürbaren Teil der Zeit, und vieles davon kannst du selbst erledigen. Jede Stunde, die der Entwickler auf Zugänge wartet oder ein Backup anlegt, steht später auf der Rechnung. Bei einem Satz von 90 Euro, dem Median freiberuflicher Softwareentwickler laut freelancermap, sind das schnell 50 bis 100 Euro für Dinge ohne jede Programmierung. Wie sich Stundensätze zusammensetzen, steht im Beitrag zum [Programmierer-Stundensatz](https://kleinerauftrag.de/kosten/programmierer-stundensatz/).

**Bevor du den Auftrag vergibst**

- [ ] Aktuelles Backup von Dateien **und** Datenbank liegt vor
- [ ] Eigenes Benutzerkonto für den Entwickler angelegt, kein geteiltes Admin-Passwort
- [ ] Abnahmekriterium in ein bis zwei prüfbaren Sätzen formuliert
- [ ] Liste, was ausdrücklich nicht zum Auftrag gehört
- [ ] Termin mit Grund genannt
- [ ] Budgetrahmen als Spanne
- [ ] Ansprechpartner für Rückfragen und Abnahme benannt

Das Backup ist der Punkt, der am häufigsten fehlt. Wie du eins anlegst und prüfst, ob es sich zurückspielen lässt, erklärt die Anleitung [Website-Backup erstellen](https://kleinerauftrag.de/abwicklung/website-backup-erstellen/).

## Wann aus dem kleinen Auftrag ein Projekt wird

Es gibt ein paar Warnzeichen. Die Beschreibung passt nicht mehr auf eine Seite. Mehr als zwei fremde Systeme sind beteiligt. Oder die Angebote liegen weit über dem, was du für eine Kleinigkeit gehalten hast, und alle Anbieter begründen es ähnlich.

Dann lohnt es sich, die Aufgabe nicht weiter in kleine Tickets zu zerlegen, sondern einmal sauber zu planen. Wer dafür ein Team sucht, das Webanwendungen und Schnittstellen nicht nur baut, sondern auch betreibt, kann bei [OnlineBuilders](https://onlinebuilders.biz/solutions/software-development) eine kostenlose technische Erstberatung anfragen.

Für alles darunter gilt: Nimm die Vorlage oben, füll sie für deinen aktuellen Auftrag aus und schick dieselbe Fassung an zwei Anbieter. Die Antworten zeigen dir schnell, wer deine Beschreibung gelesen hat.

## Häufige Fragen

### Brauche ich für einen kleinen Auftrag ein Lastenheft?

Nein. Ein Lastenheft lohnt sich bei Projekten mit vielen Beteiligten und mehreren Wochen Laufzeit. Für eine Änderung an Website, Plugin oder Schnittstelle reicht eine Seite mit den neun Feldern aus der Vorlage.

### Darf ein Programmierer für das Angebot Geld verlangen?

Nur wenn ihr das vorher vereinbart habt. Nach § 632 Abs. 3 BGB ist ein Kostenanschlag im Zweifel nicht zu vergüten. Eine bezahlte Analyse, etwa zwei Stunden Code-Sichtung vor einem Festpreis, ist trotzdem oft fair, wenn das System unbekannt ist.

### Soll ich mein Budget nennen?

Ja, zumindest als Rahmen. Ein Budget sagt dem Entwickler, ob du eine schnelle Lösung oder eine saubere, erweiterbare suchst. Ohne Rahmen bekommst du Angebote, die sich um das Drei- oder Vierfache unterscheiden und schwer zu vergleichen sind.

### Wie viele Angebote sollte ich einholen?

Für Aufträge unter einem Tag Aufwand reichen zwei. Mehr kostet dich Zeit für Rückfragen, ohne dass die Entscheidung besser wird. Wichtiger ist, dass alle dieselbe Beschreibung bekommen.

Foto: Shixart1985, CC BY 2.0 (https://commons.wikimedia.org/wiki/File:Person_writing_in_notebook_while_using_laptop_at_a_modern_workspace.jpg)