Programmierung von Internetseiten: Projektablauf, Abnahme und Steuerung
Erfahren Sie, wie Sie Technik auswählen, Anforderungen festhalten, Umsetzung und Abnahme steuern sowie Quellcode, Wartung und Übergabe regeln.
Wer die Programmierung einer Internetseite beauftragt, kauft keine fertige Ware, sondern ein Projekt mit Beteiligung auf beiden Seiten. Der Erfolg hängt weniger an der Wahl der Technik als daran, ob Anforderungen früh festgehalten, Zwischenstände geprüft und Abnahmekriterien vorher vereinbart wurden. Dieser Text beschreibt die Programmierung aus der Perspektive des Auftraggebers: welche Grundsatzentscheidung am Anfang steht, woraus das entstehende System besteht, wie ein Projekt von der Anforderungsanalyse bis zum Go-live läuft und was danach mit Quellcode, Wartung und Weiterentwicklung passiert.
Die erste Weichenstellung: Baukasten, CMS oder Individualentwicklung
Bevor über Umsetzung gesprochen wird, fällt eine Entscheidung, die alle späteren Kosten und Freiheiten prägt.
Ein Baukasten liefert Gestaltung und Technik als gebündeltes Produkt. Sie mieten eine Umgebung, in der Sie Inhalte pflegen, aber nur innerhalb vorgegebener Bausteine. Programmierung im engeren Sinn findet kaum statt. Der Preis dafür ist begrenzte Anschlussfähigkeit: Schnittstellen zu Warenwirtschaft, CRM oder Buchungssystemen sind entweder vorgesehen oder nicht möglich.
Ein Content-Management-System ist der Mittelweg und der häufigste Fall. Der Kern ist fertig, die Anpassung erfolgt über Templates, Konfiguration und Erweiterungen. Hier entsteht echte Programmierarbeit, aber auf einer bestehenden Basis. Ein oft übersehener Punkt ist die Lizenz des Systems: WordPress etwa erscheint unter der GNU General Public License v2 oder später, der Quellcode ist also einsehbar und veränderbar. Das ist für Sie als Auftraggeber relevant, weil es die Abhängigkeit von einem einzelnen Dienstleister begrenzt.
Die Individualentwicklung ist gerechtfertigt, wenn Ihr Geschäftsprozess selbst im Zentrum steht, etwa bei Konfiguratoren, Portalen mit Nutzerkonten oder eng verzahnten Anbindungen an vorhandene Systeme. Sie zahlen dann nicht für Gestaltung, sondern für Logik. Die Faustregel für die Entscheidung lautet: Je stärker sich Ihre Anforderungen von dem unterscheiden, was tausend andere Unternehmen ebenfalls brauchen, desto weiter rückt das Projekt Richtung Individualentwicklung.
Woraus das entstehende System besteht
Für die Steuerung eines Projekts genügt ein grobes, aber sauberes Bild der Bestandteile. Es hilft vor allem, Aufwände einzuordnen und Missverständnisse in Angeboten zu erkennen.
Das Frontend ist alles, was im Browser des Besuchers läuft: Struktur, Gestaltung und Interaktion. Wichtig für Ausschreibungen: HTML wird nicht mehr in nummerierten Versionen veröffentlicht, sondern von der WHATWG als kontinuierlich gepflegter HTML Living Standard herausgegeben. Eine Anforderung wie “in HTML5 umzusetzen” ist deshalb inhaltsleer. Sinnvoller sind prüfbare Anforderungen an Darstellung, Bedienbarkeit und Barrierefreiheit.
Das Backend ist der Teil, der auf dem Server arbeitet: Formulare verarbeiten, Berechtigungen prüfen, Inhalte ausliefern, mit anderen Systemen sprechen. Er ist für Sie unsichtbar und verursacht trotzdem den größeren Teil des Aufwands, sobald das Projekt über die reine Darstellung hinausgeht.
Die Datenbank hält alles, was dauerhaft bestehen bleibt: Seiteninhalte, Bestellungen, Nutzerkonten, Protokolle. Sie ist das langlebigste Element eines Projekts, weil Gestaltung und Technik ausgetauscht werden können, die gesammelten Daten aber bleiben. Fragen Sie deshalb früh, wem die Daten gehören und in welcher Form Sie sie exportieren können.
Hinzu kommt die Infrastruktur: Server, Domain, Zertifikate, Backups. Auch hier lohnt eine konkrete Nachfrage, denn TLS-Zertifikate von Let’s Encrypt sind kostenlos, laufen aber nur 90 Tage und werden üblicherweise automatisiert erneuert. Wenn ein Angebot eine jährliche Gebühr für ein solches Zertifikat vorsieht, sollte klar sein, welche Leistung damit tatsächlich abgegolten wird.
Anforderungsanalyse und Lastenheft
Die Phase, in der am wenigsten sichtbar passiert, entscheidet über das Budget. Ziel der Anforderungsanalyse ist eine Liste von Aussagen, die entweder erfüllt oder nicht erfüllt sind. “Modernes Design” ist keine Anforderung. “Das Kontaktformular schreibt jede Anfrage in das CRM und sendet dem Absender eine Bestätigung” ist eine.
In das Lastenheft gehören mindestens: die fachlichen Funktionen, die Rollen und Rechte, die anzubindenden Fremdsysteme, die zu übernehmenden Inhalte samt Altbestand, die rechtlichen Vorgaben, die Zielgruppen und Endgeräte sowie die Kriterien, an denen Sie später abnehmen. Der Dienstleister antwortet darauf mit einem Pflichtenheft, das beschreibt, wie er die Punkte umsetzen will. Erst diese beiden Dokumente zusammen sind eine belastbare Grundlage für Festpreise.
Zwei rechtlich getriebene Anforderungen gehören in Deutschland ausdrücklich in dieses Dokument. Die Web Content Accessibility Guidelines 2.1 sind seit dem 5. Juni 2018 offizielle Empfehlung des W3C und definieren die Konformitätsstufen A, AA und AAA. Und das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025 und verpflichtet bestimmte Anbieter digitaler Dienstleistungen gegenüber Verbrauchern zu barrierefreier Umsetzung. Ob Sie betroffen sind, klären Sie vor der Beauftragung, nicht nach der Abnahme: Barrierefreiheit nachträglich einzubauen ist deutlich teurer, als sie von Beginn an mitzuplanen.
Umsetzung: Zwischenstände statt Statusberichte
In der Umsetzungsphase ist Ihre wichtigste Steuerungsentscheidung, wie oft Sie etwas Lauffähiges zu sehen bekommen. Ein Projekt, das erst nach drei Monaten das erste Mal vorgeführt wird, hat drei Monate lang unbemerkt in die falsche Richtung laufen können.
Bewährt hat sich eine Umgebung, auf der der jeweils aktuelle Stand liegt und die Sie jederzeit selbst aufrufen können, zusammen mit festen Terminen, an denen ein abgegrenzter Teil vorgestellt wird. Halten Sie Änderungswünsche schriftlich fest und ordnen Sie jedem zu, ob er im vereinbarten Umfang liegt oder eine Erweiterung ist. Diese Zuordnung gemeinsam und laufend vorzunehmen, verhindert die typische Auseinandersetzung am Projektende, bei der beide Seiten unterschiedliche Erinnerungen an denselben Satz haben.
Test und Abnahme
Die Abnahme ist ein Rechtsakt mit Folgen für Zahlung, Gewährleistung und Haftung. Sie sollte deshalb nicht auf einem Gesamteindruck beruhen, sondern auf einer Liste, die Punkt für Punkt abgehakt wird. Prüfen Sie mindestens:
Funktion. Jede Anforderung aus dem Lastenheft wird einmal echt durchgespielt, inklusive der Fehlerfälle: unvollständig ausgefülltes Formular, abgebrochene Zahlung, doppelter Klick.
Darstellung auf Endgeräten. Die korrekte Darstellung auf Smartphone, Tablet und Desktop ist hier ein Testkriterium, das entweder erfüllt ist oder nicht.
Leistung im Feld. Google hat im März 2024 die Kennzahl Interaction to Next Paint als Core Web Vital eingeführt und damit First Input Delay abgelöst. Wenn Sie Leistungsanforderungen vereinbaren, nennen Sie die heute gültigen Kennzahlen und messen Sie sie an denselben Seiten, die später real genutzt werden.
Barrierefreiheit. Gegen die vereinbarte Konformitätsstufe, nicht gegen ein Gefühl.
Übergabe. Zugänge, Dokumentation und Quellcode liegen vor.
Halten Sie das Ergebnis schriftlich fest, inklusive der Restpunkte und einer Frist für deren Behebung. Eine Abnahme unter Vorbehalt mit benannten Mängeln ist für beide Seiten sauberer als eine verschobene Abnahme.
Quellcode, Zugänge und Abhängigkeiten
Klären Sie vor Vertragsschluss, was Sie am Ende in der Hand halten. Drei Punkte sind entscheidend.
Erstens der Quellcode und die Nutzungsrechte daran: Bekommen Sie ihn, in welchem Umfang dürfen Sie ihn ändern und weitergeben, und liegt er in einem Versionsverwaltungssystem, auf das Sie Zugriff haben. Zweitens die Zugänge: Domain, Hosting, Datenbank, Zertifikate und alle genutzten Dienste sollten auf Ihr Unternehmen laufen und nicht auf ein Konto des Dienstleisters. Drittens die Fremdbestandteile: Welche Erweiterungen und Bibliotheken sind verbaut, unter welcher Lizenz stehen sie, und welche davon sind kostenpflichtig oder an ein Abonnement gebunden. Diese Liste ist die realistischste Vorschau auf Ihre laufenden Kosten.
Wartung und Weiterentwicklung
Mit dem Go-live endet das Projekt, nicht der Aufwand. Eine programmierte Internetseite ist Software in einer Umgebung, die sich ohne Ihr Zutun verändert: Browser, Serversysteme, Zahlungsanbieter und Sicherheitsanforderungen entwickeln sich weiter.
Regeln Sie deshalb in einem eigenen Vertrag, getrennt vom Projekt, mindestens: wer Aktualisierungen einspielt und in welchem Rhythmus, wie schnell auf Sicherheitslücken und auf Ausfälle reagiert wird, wer Backups erstellt und wer regelmäßig prüft, dass sich diese auch zurückspielen lassen. Legen Sie außerdem fest, wie kleine Änderungswünsche abgewickelt werden, damit nicht jede Anpassung ein eigenes Angebot auslöst.
Für die Weiterentwicklung hilft dieselbe Disziplin wie im Projekt: Sammeln Sie Wünsche, priorisieren Sie sie in festen Abständen und geben Sie sie in abgegrenzten Paketen frei. Eine Internetseite, die zweimal im Jahr geplant ausgebaut wird, bleibt technisch beherrschbar. Eine, die über Jahre in Einzelaufträgen wächst, wird irgendwann teurer im Betrieb als eine Neuentwicklung.
