PHP-Entwicklung: warum der Web-Stack eine wirtschaftliche Entscheidung ist

© InfiniteFlow

PHP-Entwicklung im Überblick

👉 PHP läuft auf 70,2 Prozent der Websites mit bekannter serverseitiger Sprache.
👉 PHP 8 ist streng typisiert, Fehler brechen vor dem Betrieb ab.
👉 Jede PHP-Version wird vier Jahre gepflegt, PHP 8.2 bis Ende 2026.
👉 20 der 25 veröffentlichten TenMedia-Referenzen laufen auf PHP, 14 davon auf Laravel.
👉 Größter Kostenblock ist Personal, nicht der Server: 7,7 Monate Vakanzdauer.
👉 Eine PHP-Anwendung entwickeln lassen heißt zuerst, Ausstiegspfad und Versionsstrategie zu klären.

Was PHP-Entwicklung ausmacht und wo ihre Grenzen liegen

PHP ist die Sprache, in der ein Server eine Seite fertig zusammenbaut, bevor sie im Browser ankommt. Steht PHP-Entwicklung im Angebot, lautet die Rückfrage fast immer: zeitgemäße Entscheidung oder bequeme Gewohnheit?

PHP-Entwicklung bezeichnet den Bau individueller Anwendungen, deren Geschäftslogik auf einem Server läuft und deren Oberfläche im Browser erscheint. Sie umfasst Entwurf, Umsetzung, Test und Betrieb einer Webanwendung samt Datenbank und Schnittstellen. Kennzeichnend ist ein offenes Ökosystem: Sprache, Frameworks, Datenbank und Server stammen aus unabhängigen Quellen und binden den Betrieb an keinen einzelnen Hersteller.

Nach der laufenden Erhebung von W3Techs setzen 70,2 Prozent aller Websites mit bekannter serverseitiger Programmiersprache auf PHP, Stand 1. September 2026. Keine andere Sprache kommt dem nahe.

Warum PHP-Entwicklung als Legacy-Thema missverstanden wird

Der Ruf der Sprache hinkt ihrem tatsächlichen Stand hinterher. Diskutiert werden Rust, Go und TypeScript, während die PHP-Webentwicklung im Hintergrund die Arbeit erledigt. Im eigenen Bestand zeigt sich dasselbe Muster: 20 der 25 veröffentlichten TenMedia-Referenzprojekte laufen auf PHP, 14 davon auf Laravel. Individuelle PHP-Entwicklung ist hier keine Option neben anderen, sondern das Rückgrat des Portfolios. Ob eine andere Sprache besser passt, lässt sich allerdings erst beurteilen, wenn die Kostenlogik über die Laufzeit steht. Geklärt wird das im Vergleich zu Node.js, Python und .NET.

Was PHP 8 an der Sprache geändert hat

Mit PHP 8 hat die Sprache den Sprung zur strikten Typisierung gemacht. Rückgabewerte, Parameter und Eigenschaften lassen sich verbindlich festlegen, und unveränderliche Objekte sind seit der 8er-Reihe von PHP ein Sprachmittel statt einer Vereinbarung im Team. Für die Entscheidungsebene zählt daran ein einziger Effekt: Fehler, die früher erst im Betrieb auffielen, brechen heute schon beim Übersetzen ab. Das verschiebt Aufwand aus der Fehlersuche in die PHP-Entwicklung selbst, also in einen planbaren Bereich. Am deutlichsten zeigt sich das bei Übernahmen durch ein fremdes Team.

Diese vertiefenden Seiten schließen an diesen Überblick an, von der Wahl des Frameworks über die einzelnen Technologien bis zu Altbeständen und laufendem Betrieb:

📎 PHP-Framework-Vergleich Welches Framework passt zu welchem Projektzuschnitt? 📎 Laravel im Detail Wofür eignet sich das meistgenutzte PHP-Framework? 📎 Symfony im Enterprise-Einsatz Was macht Symfony für langlebige Systeme stark? 📎 TYPO3 als Enterprise-CMS Wann lohnt sich ein CMS statt einer Eigenentwicklung? 📎 PHP Legacy-Modernisierung Wie kommt ein Altbestand ohne Stillstand auf den aktuellen Stand? 📎 PHP-Wartung und Betrieb Was gehört in einen belastbaren Wartungsvertrag?

Was die Versionspflege daran ändert

Die PHP-Versionen folgen dabei einem Takt, der seit Jahren unverändert gilt. Jede wird zwei Jahre aktiv gepflegt und danach zwei weitere Jahre mit Sicherheitspatches versorgt. PHP 8.2 erreicht sein Supportende am 31. Dezember 2026, PHP 8.5 läuft bis Ende 2029. Damit steht der Rhythmus fest, in dem eine Anwendung angefasst werden muss, und lässt sich Jahre im Voraus einplanen. Wie ein solcher Versionswechsel praktisch abläuft, gehört in den Wartungsvertrag und nicht in die Technologieentscheidung.

Wofür sich eine PHP-Webanwendung eignet

Der Bogen der PHP-Entwicklung reicht weiter, als der Ruf der Sprache vermuten lässt. Entscheidend ist nicht, ob etwas technisch möglich ist, sondern ob die Anforderung zum Ausführungsmodell passt. PHP nimmt eine Anfrage entgegen, liefert eine Antwort und wartet auf die nächste. Alles, was sich in dieses Muster fügt, ist gut aufgehoben, und das ist der weit überwiegende Teil dessen, was Organisationen tatsächlich brauchen. Typische Einsatzgebiete einer individuellen Webanwendung:

• Fachverfahren und Antragsstrecken mit Rollen, Fristen und Aktenführung
• Selbstverwaltungsportale für Kundschaft, Mitglieder oder Bürgerinnen und Bürger
• Warenwirtschaft, Terminplanung und Ressourcenverwaltung im Tagesbetrieb
• Schnittstellen zwischen Bestandssystemen, die nicht miteinander sprechen
• Auswertungen und Berichte auf gewachsenen Datenbeständen
• Redaktionsplattformen mit mehrstufigen Freigaben

Fachverfahren und Portale in der Verwaltung

Behörden und öffentliche Einrichtungen stellen an eine Webapplikation zwei Anforderungen, die in der Privatwirtschaft seltener zusammenfallen: sehr lange Laufzeiten und lückenlose Nachvollziehbarkeit. Eine Anwendung, die Anträge bearbeitet, muss nach zwölf Jahren noch erklären können, wer wann was entschieden hat. PHP-Entwicklung für die öffentliche Verwaltung trägt das, weil Datenhaltung und Protokollierung im Kern der Anwendung liegen und nicht in der Zusatzkomponente eines Anbieters. Ein Beispiel ist der Relaunch eines Datenbanksystems für die berufliche Bildung mit Datenbestand, Rollen und Auswertung.

Was die Verwaltung zusätzlich verlangt

Dazu kommen Anforderungen an die PHP-Entwicklung, die kein Lastenheft eines Unternehmens kennt. Barrierefreiheit nach BITV ist verpflichtend, nicht wünschenswert, und die Datenhaltung muss benennen können, in welchem Rechenzentrum sie liegt. Die Abnahme prüft außerdem, ob das Haus die Anwendung im Ernstfall ohne den bisherigen Dienstleister weiterbetreiben könnte. Diese dritte Anforderung entscheidet über den Preis eines Anbieterwechsels und gehört in die Abnahme. In der Individualsoftware für eine Behörde stand sie von Beginn an im Lastenheft.

Geschäftsanwendungen im Mittelstand

Im Mittelstand hat die PHP-Entwicklung einen anderen Auslöser. Dort steht am Anfang meist eine Tabellenkalkulation, die über Jahre zum Betriebssystem einer Abteilung geworden ist: Sie kennt jede Ausnahme des Hauses, verträgt aber keinen zweiten gleichzeitigen Zugriff. Eine individuelle Softwareentwicklung löst sie ab, ohne den bewährten Ablauf umzubauen. Der wirtschaftliche Punkt liegt dabei selten in der Software, sondern in den Datenbeständen dahinter. Wie die PHP-Datenbank geschnitten ist, entscheidet über jede spätere Auswertung, und eine belastbare Datenbankentwicklung ist deshalb der Teil des Projekts, an dem am wenigsten gespart werden sollte.

Schnittstellen zwischen Bestandssystemen

Der dritte große Fall der PHP-Entwicklung trägt keinen eigenen Namen und macht trotzdem einen erheblichen Teil der Projekte aus. Zwei Systeme existieren, beide funktionieren, keines spricht mit dem anderen. Ein PHP-Backend eignet sich für diese Vermittlerrolle, weil praktisch jedes Format und jedes Protokoll bereits als geprüfte Bibliothek vorliegt. Der Aufwand steckt fast nie im Datenaustausch selbst, sondern in den Fällen daneben: wenn das Zielsystem wartet, ein Datensatz doppelt ankommt oder eine Übertragung mitten im Lauf abbricht. Eine PHP-API, die diese drei Fälle offenlässt, funktioniert im Test und erzeugt im Betrieb Handarbeit, und genau daran misst sich eine Schnittstellenentwicklung.

Wann ist PHP die richtige Wahl und wann nicht?

Ein ehrlicher Blick auf die Grenzen spart mehr Geld als jede Framework-Diskussion. Das Ausführungsmodell, das PHP-Entwicklung für Anfrage und Antwort so effizient macht, wird dort zum Hindernis, wo eine Anwendung dauerhaft mithören oder dauerhaft rechnen muss. Vier Fälle, in denen eine andere Technologie die bessere Antwort ist:

➤ Echtzeitkommunikation mit vielen offenen Verbindungen, etwa Chat oder Live-Telemetrie ➤ Rechenintensive Verarbeitung auf Grafikprozessoren, etwa Bildanalyse oder Modelltraining ➤ Desktop-nahe Anwendungen mit Zugriff auf lokale Hardware ➤ Eingebettete Systeme und Steuerungstechnik mit harten Zeitanforderungen

Außerhalb dieser vier Fälle ist die Frage nicht, ob PHP es kann, sondern ob der Anbieter es kann. Teamform, Zertifizierungen und Wartungsbereitschaft wiegen dabei schwerer als die Technologieliste im Angebot, und das gilt unabhängig vom Framework, wie die Auswahl einer Laravel-Agentur zeigt. Unternehmen, die eine Webanwendung entwickeln lassen, prüfen deshalb zuerst die Anforderung und danach die Technik. Die Sprache ist selten der Engpass, die Erfahrung mit dem Betrieb ist es.

Was eine PHP-Webanwendung über Jahre kostet

Angebote lassen sich leicht nebeneinanderlegen, die Kosten über die Laufzeit dagegen nicht. Ein Angebot für PHP-Entwicklung nennt den Preis der Erstentwicklung, die drei Posten dahinter selten: Personal, Betrieb und Versionspflege. Sie verhalten sich über fünf Jahre gegenläufig, denn die Entwicklung kostet anfangs viel und danach immer weniger, der Betrieb bleibt gleich, und die Versionspflege springt in Stufen nach oben. Ein Vergleich allein über den Angebotspreis bildet nur die erste dieser drei Kurven ab.

Personalverfügbarkeit als Kostenfaktor

Der größte Kostenblock einer individuellen Webanwendung sind Menschen, und deren Verfügbarkeit ist keine Konstante. Der Bitkom zählt rund 109.000 unbesetzte IT-Stellen bei einer durchschnittlichen Vakanzdauer von 7,7 Monaten, erhoben 2025 unter 855 Unternehmen. Auf ein laufendes Projekt übertragen heißt das: Der Ausfall einer Schlüsselperson verschiebt Termine nicht um Wochen, sondern um zwei bis drei Quartale. Eine Sprache mit breitem Arbeitsmarkt senkt dieses Risiko spürbar, und darin liegt der wirtschaftliche Vorteil der PHP-Entwicklung gegenüber Nischentechnologien. Für die Backend-Entwicklung wiegt das schwerer als für die Oberfläche, weil dort das fachliche Wissen sitzt.

Was das für Konzerne bedeutet

Dort entscheidet nicht nur die Verfügbarkeit am Markt, sondern die Frage, ob die eigene interne IT eine übernommene Anwendung weiterentwickeln kann. Ein Stack, den drei Abteilungen im Haus bereits betreiben, kostet in der Übergabe einen Bruchteil einer Speziallösung. Ein verbreiteter Stack ist in Konzernen deshalb weniger eine Technik- als eine Organisationsentscheidung, und die PHP-Entwicklung profitiert davon.

Die fünf Posten im laufenden Betrieb

Die Betriebskosten zerfallen in fünf Posten mit sehr unterschiedlichem Verlauf. Der erste ist der sichtbarste und zugleich der kleinste, woraus die verbreitete Fehleinschätzung entsteht, eine PHP-Webanwendung koste im Betrieb fast nichts. Belastbar wird die Rechnung einer PHP-Entwicklung erst, wenn alle fünf über die Laufzeit angesetzt werden.

• Serverkosten: PHP-Hosting ist planbar und über die Laufzeit weitgehend flach
• Sicherheitsupdates: gleichmäßiger Grundaufwand für Abhängigkeiten und Betriebssystem
• Versionspflege: kein gleichmäßiger Posten, sondern ein Sprung an jedem Supportende
• Fachliche Weiterentwicklung: der einzige Posten, der neuen Nutzen erzeugt
• Monitoring und Bereitschaft: kalkulierbar, sobald Reaktionszeiten vereinbart sind

Wo die Kosten im dritten Jahr springen

In den ersten beiden Jahren nach der Abnahme fallen fast nur Sicherheitsupdates an, und der Eindruck entsteht, eine PHP-Anwendung koste im Betrieb kaum etwas. Im dritten Jahr trifft sie auf das Supportende ihrer PHP-Version und damit auf ein Bündel aufgestauter Framework-Updates. Wer diesen Sprung nicht eingeplant hat, verhandelt ihn unter Zeitdruck. Solide PHP-Entwicklung zeigt sich daran, dass dieser Termin bereits im Angebot steht und nicht erst im Wartungsticket auftaucht.

Der Ausstiegspfad als Preisbestandteil

Kaum ein Lastenheft fragt danach, wenn Organisationen eine Webanwendung entwickeln lassen, und kaum eine Entscheidung wirkt länger nach. In der PHP-Entwicklung sind Hosting, Werkzeuge und Personal an keinen Anbieter gebunden: Die Sprache ist quelloffen, die Datenbank austauschbar, und der Betrieb läuft auf gewöhnlichen Servern ohne Lizenzgebühren. Damit bleibt der Wechsel des Dienstleisters ein Übergabeprojekt und wird nicht zur Neuentwicklung.

Warum die Technik dabei nur die halbe Rechnung ist

Vertragslaufzeiten, die Verteilung des Wissens im eigenen Haus und die Rechtsordnung des Betreibers wiegen schwerer als die Wahl der Programmiersprache, und alle drei gehören zur digitalen Souveränität. Eine quelloffene Sprache nützt wenig, wenn niemand im Haus den Quellcode je gelesen hat. Öffentliche Auftraggeber legen an denselben Ausstiegspfad einen weiteren Maßstab an, weil das Vergaberecht sie zur Technologieneutralität verpflichtet und trotzdem einen Eignungsnachweis verlangt. Gefordert ist dabei nicht eine Sprache, sondern ein nachweisbarer Betrieb, und wie Vergabestellen diesen Nachweis prüfen, entscheidet über den Zuschnitt eines Angebots.

© KI-generiert (TenMedia)

Der Betriebsstack unter der Anwendung

Zwei Anwendungen auf PHP-Basis mit gleichem Funktionsumfang können sich im Serverbedarf deutlich unterscheiden, ohne dass ihr Code sich unterscheidet. Der Grund liegt eine Ebene tiefer, nämlich darin, wie der Server die Anwendung startet und wie lange er sie im Speicher behält. Diese Ebene taucht in kaum einem Angebot auf und entscheidet trotzdem über Antwortzeiten, Serverzahl und Betriebsaufwand. Sie gehört deshalb in jedes Auswahlgespräch über PHP-Entwicklung.

Warum PHP 8 im Worker-Betrieb anders läuft

Klassisch startet ein PHP-Server für jede Anfrage einen frischen Prozess, lädt die Anwendung, antwortet und wirft danach alles weg. Das ist robust, weil kein Zustand von einer Anfrage in die nächste überläuft, und teuer, weil dieselbe Startarbeit tausendfach anfällt. Der Worker-Betrieb kehrt das um: Die Anwendung wird einmal geladen und bleibt im Speicher, jede weitere Anfrage trifft auf ein einsatzbereites System. Tragfähig wurde das Modell erst mit PHP 8, weil die Sprache seither Objekte verlässlich unveränderlich hält und Speicher sauberer freigibt.

• Die Startarbeit fällt einmal an statt bei jeder einzelnen Anfrage
• Datenbankverbindungen bleiben offen und werden nicht ständig neu aufgebaut
• Der Speicherbedarf wächst nicht mehr mit der Zahl gleichzeitiger Prozesse
• Fehler im Umgang mit Zustand fallen sofort auf statt sich selbst aufzuräumen
• Dieselbe Last braucht weniger Server, und das senkt die Betriebskosten unmittelbar

Was der Umstieg an einer Bestandsanwendung verlangt

Der letzte Punkt ist der unbequeme. Der Worker-Betrieb verzeiht schlampigen Umgang mit Zustand nicht, und Anwendungen, die lange mit dem großzügigen Aufräumen des klassischen Modells gelebt haben, müssen dafür angefasst werden. Der Wechsel ist keine Konfigurationsfrage der PHP-Entwicklung, sondern eine Entscheidung mit Aufwand. Bei einer kleinen Fachanwendung bleibt das klassische Modell die richtige Wahl.

Was unterscheidet PHP-Hosting von normalem Webhosting?

Der Unterschied ist größer, als der Name vermuten lässt. Gewöhnliches Webhosting stellt einen Interpreter bereit und beschränkt sich darauf, was für eine private Seite genügt und für eine webbasierte Anwendung nicht. PHP-Hosting für eine Geschäftsanwendung muss zusätzlich die Version festschreiben, Erweiterungen mitliefern, Hintergrundprozesse dauerhaft laufen lassen und einen Zwischenspeicher betreiben. Bei einem Redaktionssystem kommen Bildbibliotheken hinzu, weshalb TYPO3-Hosting eigene Mindestanforderungen kennt. Die acht jüngsten TenMedia-Projekte laufen nicht auf einem klassischen PHP-Server hinter Apache, sondern auf FrankenPHP mit dem Webserver Caddy, dazu Redis und Docker. Damit bleiben Entwicklung, Test und Produktion identisch. Dass er auch eine übernommene Bestandsanwendung trägt, zeigt die hochverfügbare Plattform eines Digitalisierungsdienstleisters.

Braucht eine PHP-Webanwendung ein eigenes JavaScript-Frontend?

Lange lautete die Antwort in der PHP-Entwicklung ja, und mit ihr kamen eine zweite Codebasis und oft ein zweites Team. Inzwischen gibt es einen tragfähigen Mittelweg: Die Oberfläche bleibt im PHP-Backend und reagiert trotzdem ohne vollständigen Seitenneuaufbau. Fünf der acht jüngsten Projekte arbeiten so. Eine Webanwendung programmieren zu lassen bedeutet damit nicht mehr zwangsläufig zwei getrennte Systeme.

Warum die Zahl der Codebasen zählt

Der Gewinn liegt nicht in der Technik, sondern in der Zahl der Dinge, die später gepflegt werden müssen. Eine Anwendung mit einer Codebasis braucht eine Wartungsplanung, eine mit getrenntem Frontend zwei, und beide altern unterschiedlich schnell. Wo eine Oberfläche sehr viel Interaktion trägt, bleibt das getrennte Frontend die bessere Wahl. Diese Entscheidung fällt, bevor jemand die erste Zeile einer Webanwendung programmieren kann, weil sie sich nachträglich nur mit einem Neubau der Oberfläche zurücknehmen lässt, und im Betrieb und in der Wartung wirkt sie über die ganze Laufzeit nach.

PHP im Vergleich zu Node.js, Python und .NET

Die Frage, ob PHP-Entwicklung die richtige Wahl ist, wird meistens als Glaubensfrage geführt und ist in Wahrheit eine Beschaffungsfrage. Dasselbe gilt eine Ebene tiefer im Direktvergleich von Laravel und Symfony, wo Architekturvorlieben die Anforderungen verdrängen. Technische Feinheiten helfen im Auswahlgespräch wenig, weil sie sich nicht in eine Entscheidungsvorlage übersetzen lassen. Vier Kriterien tun das sehr wohl, denn jedes lässt sich in Geld oder in Zeit ausdrücken:

💡 Personalverfügbarkeit: Wie schnell lässt sich eine ausgefallene Rolle nachbesetzen? 💡 Betriebsmodell: Was kostet der laufende Betrieb, und wie viele Anbieter kommen infrage? 💡 Lizenz- und Werkzeugkosten: Fallen neben der Entwicklung wiederkehrende Gebühren an? 💡 Ausstiegspfad: Wie aufwendig ist die Übergabe an ein anderes Team?

PHP und Node.js

Node.js ist stark, wo eine Anwendung dauerhaft zuhören muss, also bei Chat, Benachrichtigungen und Live-Daten. Der oft genannte Vorteil, dass Frontend und Backend dieselbe Sprache sprechen, wiegt weniger schwer als erwartet, weil die eigentliche Arbeit im Datenmodell und in der Fachlogik steckt. Beim Vergleich php vs javascript zählt für den Betrieb ein anderer Punkt: Die Abhängigkeitsbäume im Node-Ökosystem sind tiefer und kurzlebiger, was den Pflegeaufwand über Jahre erhöht.

PHP, Python und .NET

Python dominiert dort, wo Daten ausgewertet oder Modelle trainiert werden, und daran führt kein Weg vorbei. Für eine klassische Geschäftsanwendung fällt der Vergleich php vs python nüchterner aus, weil der Betrieb einer Python-Webanwendung mehr Bausteine verlangt und weniger Anbieter ihn standardmäßig unterstützen. Bei .NET ist die Lage eindeutiger: In einem Haus mit Microsoft-Technologie ist .NET naheliegend, weil Betrieb, Verzeichnisdienst und Kompetenz vorhanden sind. Ohne diese Grundlage kehrt sich das Argument um, denn dann kommen Lizenzkosten und ein spezialisierterer Arbeitsmarkt hinzu.

Was die vier Kriterien zusammen ergeben

Keines der vier Kriterien entscheidet für sich, und genau darin liegt der Denkfehler der üblichen Sprachdebatte. PHP-Entwicklung gewinnt selten ein einzelnes Kriterium deutlich und liegt bei allen vieren gleichmäßig vorn oder gleichauf. Jedes der drei anderen gewinnt ein Kriterium deutlich und zahlt an anderer Stelle drauf. Ein gemischter Aufbau ist zulässig und häufig: eine Webapplikation, deren Kern aus der Entwicklung mit PHP stammt, daneben ein kleiner Dienst in der Sprache, die für seine eine Aufgabe die richtige ist.

PHP in Vergabe und öffentlicher Beschaffung

Im öffentlichen Bereich wird die Entscheidung für PHP-Entwicklung nicht nur getroffen, sondern begründet. Das Vergaberecht verlangt eine produktneutrale Leistungsbeschreibung, und zugleich muss die Vergabestelle sicher sein, dass die beschaffte Anwendung über Jahre betreibbar bleibt. Ein Unternehmen entscheidet, ob eine Lösung passt. Eine Vergabestelle muss zusätzlich belegen, warum sie passt und warum eine andere ausgeschieden ist. Diese Beweislast verschiebt den Zuschnitt eines Angebots für PHP-Softwareentwicklung.

Darf eine Vergabestelle PHP überhaupt vorgeben?

Als Selbstzweck darf sie das in aller Regel nicht, und der Grund dafür steht im Vergaberecht. Eine Leistungsbeschreibung darf keine bestimmte Technologie fordern, wenn dafür ein sachlicher Grund fehlt, weil sie damit Bieter ohne Not ausschließt. Zulässig ist der umgekehrte Weg: Die Vergabestelle beschreibt, was gelten soll, etwa dass die Anwendung im eigenen Rechenzentrum ohne Herstellerlizenzen betreibbar sein muss. Erfüllt die PHP-Entwicklung diese Anforderungen, ist die Entscheidung gefallen, ohne dass die Sprache je im Text steht. Für öffentliche Auftraggeber ist das der belastbarere Weg, weil er auch eine Rüge übersteht.

PHP 8 als Anforderung im Leistungsverzeichnis

Statt der Sprache selbst gehört ihr Zustand ins Leistungsverzeichnis, und das ist mehr als eine Formulierungsfrage. Eine Forderung nach PHP 8 in aktiv gepflegter Fassung beschreibt ein Sicherheitsniveau und keine Marke. Die aktuelle PHP-Generation erfüllt sie ohne Zusatzaufwand, eine zehn Jahre alte Installation nicht. Fünf Punkte lassen sich dafür prüfbar formulieren:

• Eingesetzte Version und deren Supportende zum Zeitpunkt der Abnahme
• Verfahren und Frist für den Wechsel auf die nächste Version
• Nachweis der regelmäßigen Prüfung von Abhängigkeiten auf Schwachstellen
• Dokumentation für einen Betrieb ohne den ursprünglichen Auftragnehmer
• Übergabe des Quellcodes samt Rechten für die Weiterentwicklung durch Dritte

Am letzten Punkt scheitern Angebote am häufigsten, obwohl er technisch der einfachste ist. Wird er erst nach dem Zuschlag verhandelt, fehlt die Verhandlungsposition.

Was TenMedia bei PHP-Projekten übernimmt

TenMedia betreibt PHP-Entwicklung seit 2011 in Berlin mit einem festangestellten Team, ohne Freelancer und ohne Auslagerung. Das Unternehmen ist nach ISO 27001 für Informationssicherheit und nach ISO 9001 für Qualitätsmanagement zertifiziert und im Amtlichen Verzeichnis präqualifizierter Unternehmen gelistet. Entwicklung, Betrieb und Wartung kommen aus derselben Hand, von der Anforderungsaufnahme über die Backend-Entwicklung bis zum Monitoring im Dauerbetrieb. Neben der PHP-Webentwicklung deckt das Team auch mobile Anwendungen, Datenmigrationen und Sicherheitsprüfungen ab.

Was PHP-Entwicklung im eigenen Team konkret bedeutet

Der Unterschied zwischen zwei Anbietern für PHP-Softwareentwicklung zeigt sich selten am Anfang und fast immer nach der Abnahme. Entwickelt dasselbe Team eine Anwendung weiter, das sie gebaut hat, bleibt das Wissen über die Ausnahmen im Haus, und Ausnahmen sind der eigentliche Inhalt jeder Fachanwendung. PHP-Entwicklung mit wechselnden externen Kräften erzeugt bei jeder Übergabe einen Wissensverlust, den niemand bilanziert. Dazu kommt ein praktischer Punkt für Auftraggeber mit Geheimhaltungsbedarf: Der Quellcode verlässt das Unternehmen nicht. Für Behörden und Unternehmen mit schutzbedürftigen Daten gibt häufig genau dieses Kriterium den Ausschlag.