PHP-Entwickler in Hamburg

#PHP-Entwicklung für Hamburger Unternehmen: was ich übernehme

Ich bin Mariusz Szatkowski, WPPoland, Gdynia. Ich arbeite seit 2006 mit WordPress, schreibe PHP und übernehme Backend-Arbeit für Unternehmen in Hamburg: ältere Anwendungen auf unterstützte PHP-Versionen bringen, Laravel- und Symfony-Systeme bauen oder erweitern, Schnittstellen zu ERP, Buchhaltung und Zahlungsdiensten anbinden und WordPress als Backend sauber aufsetzen. Alles läuft remote und schriftlich. Es gibt keine Termine vor Ort und keine Telefonrunden, dafür ein Projektprotokoll, das jeder Beteiligte jederzeit nachlesen kann.

Meine typische Ausgangslage bei PHP-Projekten ist gewachsene Software, die jemand anderes vor Jahren gebaut hat und die heute Umsatz trägt.

Foto: Uwe Rohwedder, CC BY-SA 4.0, Wikimedia Commons.

#Der Hamburger Rahmen für Software-Projekte

Wer in Hamburg ein Unternehmen führt, findet mehrere öffentliche Anlaufstellen. Hamburg Invest ist laut Wirtschaftsportal der zentrale Ansprechpartner für Unternehmen, die investieren, erweitern oder sich ansiedeln wollen. Die Seite hamburg-business.com nennt als Schwerpunkte unter anderem Künstliche Intelligenz (“KI-Standort und Modellregion für KI-Startups”), das Projekt smartPORT unter dem Stichwort “Hafen der Zukunft” und vier Innovationsparks und -quartiere in Altona, Bergedorf, Harburg und Finkenwerder. Für Gründer gibt es die Startup City Hamburg als zentralen Einstieg, mit Adresse am Besenbinderhof 31.

Die Handelskammer Hamburg am Adolphsplatz 1 hat auf ihrer Startseite im November 2026 einen Hinweis des BSI zu gefälschten E-Mails und Anrufen gezeigt. Für Backend-Arbeit zählt das: Wer Formulare, Passwort-Reset-Mails oder Rechnungsversand programmiert, baut genau die Wege, über die solche Fälschungen später Vertrauen missbrauchen. SPF, DKIM, DMARC und saubere Absenderadressen richte ich deshalb mit jedem Mailversand ein.

#Leistungen im Überblick

#Ältere PHP-Anwendungen modernisieren

Typischer Auslöser: Der Hoster stellt eine alte PHP-Version ab, ein Plugin oder Paket läuft nicht mehr, oder ein Sicherheitsscan meldet Lücken. Ich gehe in fester Reihenfolge vor. Zuerst lese ich Code und Composer-Abhängigkeiten und schreibe auf, was an der Zielversion bricht. Dann ergänze ich Tests um das bestehende Verhalten, setze Rector und PHPStan ein und hebe die Version in Schritten an, nicht in einem Sprung. Jeder Schritt läuft zuerst auf Staging, bevor ein Release in die Produktion geht.

#Laravel und Symfony

Laravel nehme ich für Geschäftsanwendungen, Admin-Bereiche und APIs, bei denen schnelle Auslieferung zählt. Symfony nehme ich für Systeme, die über viele Jahre gepflegt werden und klar getrennte Komponenten brauchen. Welches Framework passt, entscheidet nicht eine Vorliebe, sondern Ihr Team: Wer später selbst weiterentwickelt, bekommt das Framework, das dort bekannt ist.

#Schnittstellen und Integrationen

Bestehende Warenwirtschaft, Buchhaltung, Zahlungsanbieter und Versanddienste hängen oft an Cronjobs und handgebauten Skripten. Ich ersetze das durch Queues mit Wiederholungslogik, idempotente Webhooks und ein Protokoll, in dem ein fehlgeschlagener Aufruf nachvollziehbar bleibt. Welche Systeme das konkret sind, klären wir im ersten Schriftwechsel.

#WordPress als PHP-Backend

Wenn Ihr Redaktionsteam mit WordPress arbeitet, bleibt WordPress das Backend. Eigene Plugins, REST-Endpunkte und Schnittstellen schreibe ich nach den WordPress-Coding-Standards. Für reine WordPress-Projekte gibt es eigene Seiten, siehe unten.

#Sicherheit und Performance

Ich prüfe Eingabevalidierung, Rechteprüfung, Sessions, Header und Abhängigkeiten mit bekannten Lücken. Bei Performance messe ich zuerst: Profiling, Datenbankabfragen, Caching. Als Zielwerte für die Webseite gelten die offiziellen Schwellen der Core Web Vitals (LCP 2,5 Sekunden, INP 200 Millisekunden, CLS 0,1, siehe web.dev). Eigene Rekordwerte verspreche ich nicht.

#Welche PHP-Version ist 2026 sinnvoll?

Laut der Seite php.net/supported-versions.php gilt am 11. November 2026 diese Tabelle:

PHP 8.1 steht nicht mehr in dieser Liste. Wer dort noch läuft, bekommt keine Sicherheitsfixes mehr. Für 8.2 enden sie in knapp sieben Wochen. Daraus folgt eine einfache Planungsregel: Neue Projekte starten auf 8.4 oder 8.5, bestehende Anwendungen auf 8.2 oder älter gehören in das Budget des nächsten Quartals, nicht des nächsten Jahres. Bei Frameworks lohnt der Blick in deren eigene Support-Tabelle, denn ein Laravel- oder Symfony-Release hat eigene Fristen, die von PHP unabhängig sind.

#Rechtlicher Rahmen für Betreiber in Hamburg

Rechtsberatung ist nicht mein Geschäft. Ich übersetze Gesetzestext in Code und nenne die Quellen, damit Ihre Kanzlei sie gegenlesen kann.

DDG § 5. Anbieter digitaler Dienste müssen bestimmte Angaben leicht auffindbar und ständig verfügbar halten, darunter Name und Anschrift, Kontaktmöglichkeit mit E-Mail-Adresse, Register und Registernummer sowie die Umsatzsteuer-Identifikationsnummer, wenn eine vorhanden ist. Für Ihr Backend heißt das: Das Impressum ist ein Datensatz mit Pflichtfeldern, der auf jeder Seite verlinkt ist. Ich baue es so, dass die Angaben an einer Stelle gepflegt werden und nicht in zehn Templates auseinanderlaufen. Quelle: gesetze-im-internet.de/ddg/__5.html.

TDDDG § 25. Das Speichern von Informationen auf dem Endgerät oder der Zugriff darauf braucht nach Absatz 1 die Einwilligung des Endnutzers, die nach der DSGVO eingeholt wird. Absatz 2 nennt zwei Ausnahmen: reine Nachrichtenübermittlung und Dienste, die der Nutzer ausdrücklich verlangt und für die die Speicherung unbedingt erforderlich ist. Für PHP heißt das konkret: Sessions für den Warenkorb fallen unter die Ausnahme, ein Marketing-Cookie nicht. Ich trenne beides im Code. Quelle: gesetze-im-internet.de/ttdsg/__25.html.

BFSG. Das Gesetz erfasst nach § 1 Absatz 3 unter anderem Dienstleistungen im elektronischen Geschäftsverkehr gegenüber Verbrauchern, erbracht nach dem 28. Juni 2025. § 3 Absatz 3 Satz 1 nimmt Kleinstunternehmen, die Dienstleistungen anbieten, von der Pflicht aus. Bei Server-gerenderten Seiten liegt vieles im PHP-Code: Formularlabels, Fehlermeldungen, Tastaturbedienung im Checkout, Alternativtexte aus dem Redaktionssystem. Quellen: gesetze-im-internet.de/bfsg/__1.html und __3.html.

Datenschutzaufsicht. Zuständig für Hamburg ist Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit. Seine Website bietet Formulare für Beschwerden, für Hinweise auf Verstöße, für die Meldung einer Datenpanne und für die An- oder Abmeldung eines Datenschutzbeauftragten. Für ein Backend bedeutet das: Ein Verfahren für Datenpannen gehört vor den Livegang, nicht danach. Quelle: datenschutz-hamburg.de.

#E-Rechnung: was das Bundesfinanzministerium schreibt

Das Bundesfinanzministerium hat die Regeln in seinen FAQ zur E-Rechnung zusammengefasst. Die wichtigsten Punkte für ein Backend:

• Seit dem 1. Januar 2025 liegt eine E-Rechnung nur vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird. Ein einfaches PDF ist keine E-Rechnung mehr, sondern eine “sonstige Rechnung”.
• Inländische Unternehmen müssen E-Rechnungen seit dem 1. Januar 2025 empfangen können. Ausnahmen sind dafür nicht vorgesehen. Für den Empfang genügt ein E-Mail-Postfach.
• Zum Ausstellen gilt bis zum 31. Dezember 2026 eine Übergangsfrist. Bei einem Vorjahresumsatz bis 800.000 Euro verlängert sie sich bis Ende 2027. EDI-Verfahren dürfen ebenfalls bis Ende 2027 weiterlaufen.
• Als zulässige Formate nennt das BMF Rechnungen nach EN 16931, insbesondere XRechnung und ZUGFeRD ab Version 2.0.1, ohne die Profile MINIMUM und BASIC-WL.
• Rechnungen an Endverbraucher fallen nicht unter die Pflicht.

Für Betriebe mit eigener Rechnungsstellung in PHP ergibt sich eine Aufgabe: Rechnungsdaten brauchen eine strukturierte Quelle, aus der XRechnung oder ZUGFeRD erzeugt und gegen die Norm validiert werden kann. Wo Sie heute PDFs mit einer Bibliothek bauen, lässt sich das meist ergänzen, ohne die Rechnungslogik neu zu schreiben. Ob Sie unter die Übergangsfrist fallen, klärt Ihre Steuerberatung.

#Ablauf eines PHP-Projekts

1. Schriftliche Anfrage. Sie schicken mir Adresse oder Beschreibung, Ziel, Frist und Stack. Ich antworte schriftlich an Werktagen.
2. Rückfragen und erste Einschätzung. Ich stelle meine Fragen schriftlich und schicke eine erste Einschätzung. Sie kostet nichts.
3. Umfang und Annahmen. Danach folgt ein schriftlicher Umfang mit Annahmen und ausdrücklich genannten Ausschlüssen. Nichts darüber hinaus wird ohne neues schriftliches Angebot gemacht.
4. Staging. Jede Änderung läuft zuerst auf einer Testumgebung. Sie bekommen dort Zugang und prüfen.
5. Abnahme. Sie nehmen anhand einer Liste ab, die wir zu Beginn festgelegt haben.
6. Betrieb. Wer möchte, vereinbart danach laufende Pflege: Updates, Monitoring, kleine Anpassungen. Dazu gibt es eine eigene Seite, siehe unten.

Gestaltung, Mockups und Wireframes liefert Ihre Seite. Hat Ihre Anwendung eine Oberfläche, baue ich nach Ihrer Vorlage, entworfen wird bei mir nichts.

#Was ich von Ihnen brauche

• Lesezugriff auf das Repository, falls vorhanden, sonst eine Kopie des Codes.
• Zugang zu Staging oder die Erlaubnis, eine aufzusetzen.
• Die PHP-Version und das Betriebssystem des Servers (ein Screenshot der Hosting-Oberfläche reicht).
• Eine Liste der angeschlossenen Systeme: Zahlung, Versand, Buchhaltung, CRM.
• Eine Person, die schriftlich Entscheidungen trifft.

#Checkliste für Ihre PHP-Anwendung

Sie können diese Punkte ohne mich durchgehen:

• Welche PHP-Version läuft in der Produktion? Steht sie in der Tabelle oben?
• Gibt es eine composer.lock, und meldet composer audit bekannte Lücken?
• Existiert ein Staging, das der Produktion entspricht?
• Gibt es Tests, die den Checkout oder die Hauptfunktion abdecken?
• Ist das Impressum zentral gepflegt, mit den Angaben nach DDG § 5?
• Setzt die Anwendung Cookies oder lokale Speicher nur nach Einwilligung, soweit nicht § 25 Absatz 2 TDDDG greift?
• Kann die Rechnungsstellung strukturierte Formate erzeugen oder wenigstens empfangen?
• Gibt es ein dokumentiertes Verfahren für den Fall einer Datenpanne?
• Wer hat Zugang zum Server, und wann wurde der zuletzt geprüft?

#Häufige Fragen

#Welche PHP-Version sollte eine Anwendung in Hamburg heute laufen?

Eine, die php.net noch unterstützt. Am 11. November 2026 sind das die Zweige 8.2 bis 8.5. Für 8.2 enden die Sicherheitsfixes am 31. Dezember 2026, für 8.4 am 31. Dezember 2028 und für 8.5 am 31. Dezember 2029. Für neue Projekte nehme ich 8.4 oder 8.5, bei bestehenden Anwendungen richtet sich das Ziel nach Framework und Abhängigkeiten.

#Muss mein PHP-Backend die E-Rechnung verarbeiten können?

Empfangen müssen inländische Unternehmen E-Rechnungen seit dem 1. Januar 2025 können. Beim Ausstellen gelten Übergangsfristen bis Ende 2026, bei einem Vorjahresumsatz bis 800.000 Euro bis Ende 2027. Das schreibt das Bundesfinanzministerium in seinen FAQ. Ob Ihre Rechnungsstellung im Shop, im ERP oder in einer Eigenentwicklung liegt, klären wir vorab schriftlich.

#Gilt das Barrierefreiheitsstärkungsgesetz für meinen Webshop?

Das BFSG nennt in § 1 Absatz 3 Dienstleistungen im elektronischen Geschäftsverkehr gegenüber Verbrauchern. Nach § 3 Absatz 3 gilt die Pflicht nicht für Kleinstunternehmen, die Dienstleistungen anbieten. Ob das auf Sie zutrifft, prüft Ihre Rechtsberatung. Die technische Umsetzung übernehme ich.

#Arbeiten Sie vor Ort in Hamburg?

Nein. Ich arbeite aus Gdynia, ausschließlich remote. Abstimmung läuft schriftlich, der Code liegt in Ihrem Repository, Tests laufen auf einer Staging-Umgebung.

#Übernehmen Sie eine Anwendung, die ein anderer Entwickler gebaut hat?

Ja. Am Anfang steht ein Lesezugriff auf Repository und Staging. Ich schreibe auf, was ich vorfinde: PHP-Version, Framework-Stand, Tests, Abhängigkeiten mit bekannten Lücken. Danach entscheiden Sie, ob schrittweise modernisiert oder gezielt repariert wird.

#Was brauche ich, um eine Einschätzung zu bekommen?

Die Adresse der Anwendung oder ein kurzer Beschreibungstext, das Ziel, eine Frist und den bestehenden Stack. Zugänge sind für die erste Einschätzung nicht nötig.

#Weitere Leistungen für Hamburg

PHP-Backends hängen selten allein. Diese Seiten ergänzen sie:

• WordPress-Entwickler Hamburg für Redaktionssysteme und eigene Plugins
• WooCommerce-Entwickler Hamburg für Shops mit Schnittstellen
• Astro-Entwickler Hamburg für ein schnelles Frontend vor dem Backend
• Next.js-Entwickler Hamburg für React-lastige Oberflächen
• Wartung und Support Hamburg für den laufenden Betrieb nach dem Release

#Schreiben Sie mir

Wenn Sie in Hamburg eine PHP-Anwendung betreiben, die Sie modernisieren, erweitern oder absichern wollen, schicken Sie mir über das Kontaktformular vier Angaben: die Adresse der Anwendung, was sie leisten soll, bis wann Sie etwas brauchen und welchen Stack Sie heute einsetzen. Ich lese alles, melde mich schriftlich mit Rückfragen und schicke danach eine erste Einschätzung. Die kostet Sie nichts.