Programmierung einer Homepage: Anforderungsprofil und Beauftragung für Auftraggeber
Wann individuelle Programmierung wirklich nötig ist, was ins Lastenheft gehört (Funktionen, Schnittstellen, DDG, DSGVO, BFSG) plus Rechte am Quellcode.

Eine Homepage zu programmieren ist seltener ein technisches als ein geschäftliches Entscheidungsproblem. Die Kernfrage lautet nicht, womit gebaut wird, sondern ob Ihr Vorhaben Individualentwicklung überhaupt rechtfertigt. Diese Seite richtet sich an Auftraggeber: Sie beschreibt, was eine Homepage tatsächlich verlangt, woran Sie erkennen, dass Programmierung nötig ist, was Sie von einem Dienstleister verlangen sollten, und wie Sie sich absichern, dass Sie das Ergebnis wirklich besitzen und später ändern lassen können.
Was wird bei einer Homepage programmiert
Eine Website besteht aus Schichten. Nur eine davon ist Programmierung im engeren Sinne.
Die Darstellungsschicht ruht auf offenen Standards: HTML wird als WHATWG HTML Living Standard gepflegt, CSS vom W3C in Modulen. Beide sind lizenzfrei und an keinen Anbieter gebunden. Das bedeutet für Sie: Diese Schicht kann Ihnen niemand entziehen, und sie ist von jedem Dienstleister lesbar.
Die Inhaltsschicht regelt, wie Texte, Bilder und Struktur gepflegt werden, meist über ein Redaktionssystem. Hier wird konfiguriert und angepasst, selten neu entwickelt.
Programmiert wird die Logikschicht: Formularverarbeitung, Berechnungen, Authentifizierung, Suchfunktionen, Buchungs- oder Bestellabläufe, Anbindungen an ERP, CRM oder Termine. Hier entstehen Aufwand, Risiko und Folgekosten. Ein Angebot, das pauschal von “Programmierung” spricht, ohne diese Schicht zu benennen, ist keine Kalkulatiton, sondern ein Versprechen.
Woran Sie erkennen, dass Einzelentwicklung berechtigt ist
Standardsysteme decken die überwiegende Zahl der Anforderungen ab. Einzelentwicklung rechtfertigt sich erst bei mindestens einer dieser Voraussetzungen:
Ein Prozess, der nur bei Ihnen so läuft. Wenn Ihre Preislogik, Terminabläufe oder Angebotsabläufe Regeln folgen, die kein Standardformular abbildet, ist das ein echter Grund. Ein Prozess, den Sie in drei Sätzen erklären können, ist meist keiner.
Eine Schnittstelle zu einem eigenen System. Sobald Daten zwischen Website und ERP, Lagerverwaltung, Zeiterfassung oder Fachanwendung fließen sollen, verlassen Sie den Standard. Prüfen Sie zuerst, ob das Zielsystem eine öffentliche Schnittstelle hat. Wenn nicht, wächst das Projektrisiko drastisch.
Datenmengen oder Zugriffsmuster außerhalb des Üblichen. Zehntausende Produktdatensätze, Nutzer-Bereiche, Mehrparteien-Zugang: solche Anforderungen sprengen Standardkonfigurationen.
Rechtliche oder organisatorische Auflagen mit technischer Wirkung. Aufbewahrungspflichten, Freigabeworkflows, Protokollierung von Zustimmungen.
Fehlt all das: Sie benötigen keine Individualentwicklung, sondern eine saubere Umsetzung auf bewährter Basis. Das ist nicht die Sparversion, sondern das geringere Betriebsrisiko.
Was ins Lastenheft muss
Ein Lastenheft beschreibt, was Sie brauchen, nicht wie. Vier Blöcke sind essentiell.
Funktionen aus Sicht der Nutzer
Formulieren Sie jede Funktion als überprüfbarer Vorgang: “Ein Interessent kann eine Anfrage mit Datei-Anhang senden und erhält eine E-Mail-Bestätigung.” Meiden Sie Eigenschaftswörter wie modern, intuitiv oder performant. Sie sind nicht abnahmefähig und erzeugen im Streitfall die Diskussion, die ein Lastenheft verhindern soll.
Trennen Sie zusätzlich: Was muss zum Start vorliegen, was folgt später. Diese Trennung ist Ihr stärkster Schutz gegen ausufernde Budgets.
Schnittstellen und Datenflüsse
Benennen Sie je Schnittstelle: Gegensystem, Datenrichtung, Aktualisierungshäufigkeit, wer Zugangsdaten stellt und was passiert, wenn das Gegensystem nicht antwortet. Der letzte Punkt wird fast immer vergessen und verursacht später die meisten Störungen. Klären Sie auch: Wem gehören die Daten, und in welchem Format können Sie sie jederzeit exportieren.
Rechtspflichten als Anforderung
Rechtliche Vorgaben sind technische Anforderungen. Wer sie erst nach der Abnahme aufruft, bezahlt sie zweimal.
Die Impressumspflicht für geschäftsmäßige Websites steht seit dem 14. Mai 2024 in Paragraph 5 des Digitale-Dienste-Gesetzes (DDG); der frühere Paragraph 5 TMG ist entfallen. Prüfen Sie Angebote und Vorlagen: Verweisen sie noch auf die alte Norm? Das zeigt, wie aktuell ein Dienstleister arbeitet.
Artikel 13 DSGVO verpflichtet zur Information betroffener Personen zum Zeitpunkt der Datenerhebung. Bei einem Kontaktformular heißt das: unmittelbar an der Erhebungsstelle, nicht nur in einer verlinkten Datenschutzerklärung. Das ist eine Anforderung an die Oberfläche und gehört ins Lastenheft, nicht in eine Rechtsberatung nach dem Launch.
Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 und verpflichtet Anbieter im elektronischen Geschäftsverkehr zu barrierefreien Websites; Kleinstunternehmen sind ausgenommen. Die europäische Norm EN 301 549 nennt für Webinhalte die WCAG 2.1 in Konformitätsstufe AA als technischen Standard. Schreiben Sie diese Stufe als Anforderung hin. Barrierefreiheit nachträglich einzubauen ist regelmäßig teurer als sie mitzuplanen, und sie verbessert die Bedienbarkeit für alle Nutzer.
Messkriterien für die Abnahme
Definieren Sie vorab, woran Erfolg gemessen wird und mit welchem Werkzeug. Seit dem 12. März 2024 gilt eine neue Kennzahl: Google hat First Input Delay (FID) durch Interaction to Next Paint (INP) als Core Web Vital ersetzt. INP ist die maßgebliche Messgröße für Interaktionsreaktion. Ein Abnahmekriterium, das noch FID nennt, misst etwas, das nicht mehr existiert.
Weitere sinnvolle Abnahmekriterien: automatisierte WCAG-Prüfung mit dokumentiertem Ergebnis, Liste unterstützter Browser und Endgeräte, Nachweis jeder Formularstrecke bis zur Zielaktion, Prüfung, dass ohne Zustimmung keine Drittanbieter-Verbindungen aufgebaut werden.
Übergabe, Quellcode-Rechte, Wartbarkeit
Diese drei Punkte entscheiden, ob Ihre Homepage in drei Jahren noch Ihnen gehört.
Nutzungsrechte. Lassen Sie sich ein ausschließliches, zeitlich und räumlich unbeschränktes Recht am Code einräumen, ausdrücklich mit dem Recht zur Bearbeitung und Weitergabe. Ohne Bearbeitungsrecht können Sie den Code besitzen, aber nicht ändern lassen.
Fremdbestandteile. Kaum ein Projekt besteht aus eigenem Code allein. Verlangen Sie eine Liste aller eingesetzten Komponenten mit ihrer Lizenz. WordPress etwa steht unter GPLv2: Der Code darf verwendet, verändert und weitergegeben werden, abgeleitete Werke unterliegen derselben Lizenz. Das ist unproblematisch, muss aber bekannt sein, bevor jemand Code als exklusiv verkauft, der es nicht ist.
Übergabeumfang. Zur Übergabe gehören: vollständiger Quellcode mit Versionsgeschichte, Zugänge zu Domain, Hosting, Redaktionssystem und Analysewerkzeugen auf Ihren eigenen Konten, eine Beschreibung des Aufbauvorgangs, mit dem sich die Seite aus dem Code neu erzeugen lässt, sowie eine Liste aller wiederkehrenden Kosten mit Fälligkeitsdatum. Registrieren Sie Domain und Hosting selbst von Anfang an. Nachträglich umzuziehen ist die häufigste unnötige Reibung beim Dienstleisterwechsel.
Wartbarkeit. Fragen Sie nicht, ob dokumentiert wird; lassen Sie sich Dokumentation aus einem abgeschlossenen Projekt zeigen. Vereinbaren Sie, wer Sicherheitsaktualisierungen einspielt, in welcher Frist, und wie Sicherungen erstellt und getestet werden. Eine Sicherung, deren Wiederherstellung nie erprobt wurde, ist eine Vermutung.
Prüfliste vor der Beauftragung
- Ist mindestens eine Anforderung benannt, die ein Standardsystem nachweislich nicht abdeckt?
- Ist jede Funktion als überprüfbarer Vorgang formuliert, nicht als Eigenschaft?
- Sind alle Schnittstellen inklusive Fehlerfall beschrieben?
- Stehen DDG Paragraph 5, DSGVO Artikel 13 und WCAG 2.1 Stufe AA als Anforderungen im Dokument?
- Sind Abnahmekriterien mit Messverfahren festgelegt, INP statt FID?
- Ist das ausschließliche Nutzungsrecht einschließlich Bearbeitung schriftlich geregelt?
- Liegen alle Fremdkomponenten mit Lizenz offen?
- Laufen Domain, Hosting und Zugänge auf Ihren Namen?
- Ist geregelt, wer aktualisiert, sichert und in welcher Frist reagiert?
Wenn Sie diese Punkte vor der Vergabe klären, verlagern Sie die Entscheidung von der Frage “Wer wirkt sympathisch?” auf die Frage “Wer liefert nachvollziehbar?”. Das ist der Unterschied zwischen einer beauftragten und einer geglückten Programmierung.
