PHP-Entwickler in Zürich

#PHP-Entwicklung für Unternehmen in Zürich

Zürich ist ein Markt mit eigenen Regeln. Wer hier Software einkauft, sitzt oft in einem Umfeld, das von Banken, Versicherungen und Pharmaunternehmen geprägt ist, und selbst kleinere Firmen übernehmen deren Erwartungen an Verlässlichkeit: dokumentierte Abläufe, saubere Übergaben, Systeme, die zehn Jahre laufen und nicht drei. PHP spielt in diesem Umfeld eine unaufgeregte, aber tragende Rolle. Marketing-Plattformen, Kundenportale, Intranets, Karriereseiten und Event-Systeme laufen auf PHP, häufig auf WordPress, oft mit Integrationen in die umliegende Systemlandschaft. Diese Anwendungen stehen selten im Rampenlicht, aber sie tragen den täglichen Kontakt mit Kunden, Bewerbern und Partnern.

Wir liefern für dieses Umfeld PHP-Engineering auf aktuellem Stand: PHP 8.3 mit strikter Typisierung, Composer-basiertes Dependency-Management, PHPStan in der CI, PHPUnit auf den Pfaden, deren Ausfall Geld kostet. Dazu kommt die Arbeit, die im Alltag den größten Teil ausmacht: Upgrades von Legacy-PHP 7.x, WordPress-Core- und Plugin-Entwicklung, REST-APIs für Integrationen und der Relaunch von Websites, deren Technik dem Unternehmen nicht mehr entspricht. Die Zusammenarbeit läuft remote aus der EU, in derselben Zeitzone wie Zürich, mit B2B-Vertrag und in der Sprache, in der Ihr Team arbeitet.

#Was eine PHP-Agentur für den Zürcher Markt leisten muss

Wer nach einer PHP-Agentur in Zürich sucht, sucht meist nicht nach jemandem, der Code schreiben kann. Das können viele. Gesucht wird ein Gegenüber, das die Erwartungen des Schweizer Marktes versteht und über Jahre erreichbar bleibt. Drei Dinge unterscheiden diesen Markt spürbar von anderen.

Erstens die Wartungserwartung. Ein Zürcher Unternehmen, das eine Anwendung in Auftrag gibt, plant deren Betrieb über viele Jahre und erwartet, dass der Dienstleister diesen Zeitraum mitdenkt: Update-Pfade für PHP-Versionen, dokumentierte Deployments, ein Ansprechpartner, der auch im vierten Jahr noch weiß, warum eine Entscheidung so gefallen ist. Zweitens die Qualitätserwartung. Code-Reviews, Staging-Umgebungen und nachvollziehbare Änderungshistorie sind hier keine Extras, sondern Voraussetzung dafür, dass die interne IT ein externes Projekt überhaupt abnimmt. Drittens die Dokumentationserwartung. Eine Übergabe besteht aus Repository, Runbook und Architekturentscheidungen in schriftlicher Form, nicht aus einem Zip-Archiv und einer Telefonnummer.

Eine Agentur trägt gegenüber einem einzelnen Freelancer einen strukturellen Vorteil in genau diesen Punkten: Vertretung bei Ausfall, ein zweites Paar Augen im Review und Kontinuität über Personalwechsel hinweg. Genau das liefern wir, ohne den Overhead großer Beratungshäuser mitzuverkaufen.

#Das Kundenumfeld: Finanzbranche, Versicherungen, Pharma

Die Struktur der Zürcher Wirtschaft prägt auch Projekte, die auf den ersten Blick nichts mit Regulierung zu tun haben. Wer für eine Versicherung eine Kampagnen-Plattform baut oder für einen Zulieferer der Pharmabranche ein Partnerportal, arbeitet mit Einkaufsprozessen, die aus der regulierten Welt stammen: Lieferantenfragebögen zur Informationssicherheit, klare Anforderungen an Datenhaltung und Zugriffskontrolle, definierte Freigabewege vor jedem Produktionsdeployment.

Für die PHP-Arbeit heißt das konkret: Zugänge laufen über personalisierte Konten statt geteilter Passwörter, Secrets liegen in einer Verwaltung und nicht im Repository, und die Anwendung schreibt Audit-Logs für sicherheitsrelevante Ereignisse wie Logins, Rechteänderungen und Datenexporte. Es heißt auch, Grenzen zu respektieren: Eine WordPress-Plattform neben einem Kernsystem einer Bank integriert über definierte Schnittstellen mit klarem Datenvertrag, niemals über direkte Datenbankzugriffe. Wir bauen die PHP-Seite dieser Schnittstellen so, dass sie ein Sicherheitsreview des Kunden ohne Nacharbeit übersteht: Eingabevalidierung an der Grenze, parametrisierte Abfragen, Least-Privilege bei jedem Systemzugang.

Diese Arbeitsweise kostet in der ersten Woche etwas Tempo und zahlt es ab der ersten Abnahme zurück, weil Diskussionen mit der internen IT auf Basis von Dokumenten statt Vermutungen laufen.

#Website-Relaunch mit PHP und WordPress in Zürich

Der Relaunch ist der häufigste Anlass, aus dem Zürcher Unternehmen eine PHP-Agentur suchen. Die bestehende Website ist fünf bis zehn Jahre alt, läuft auf einer nicht mehr unterstützten PHP-Version, das Theme stammt von einem Dienstleister, den es nicht mehr gibt, und jede inhaltliche Änderung dauert länger, als sie dürfte.

Ein Relaunch hat bei uns zwei gleichrangige Hälften. Die sichtbare Hälfte ist der Neuaufbau: ein sauberes WordPress-Theme oder eine neue Architektur, PHP 8.3 als Basis, ein Redaktionssystem, das die Marketingabteilung ohne Entwickler bedienen kann, und eine mehrsprachige Struktur, wenn die Seite auf Deutsch und Englisch laufen soll. Die unsichtbare Hälfte entscheidet über den geschäftlichen Erfolg: das vollständige URL-Inventar der alten Seite, ein Redirect-Plan für jede Adresse, die Rankings oder eingehende Links trägt, die Übernahme der Metadaten und die Prüfung, dass Suchmaschinen die neue Struktur ohne Bruch übernehmen. Wer diese Hälfte auslässt, bezahlt den Relaunch doppelt: einmal für die Entwicklung und einmal über verlorene Sichtbarkeit.

Die technischen Ziele legen wir vor dem ersten Commit fest, nicht danach. Für einen typischen Relaunch heißt das: Core Web Vitals im grünen Bereich als Abnahmekriterium, Antwortzeiten des Servers unter 200 Millisekunden für Besucher aus der Schweiz, ein Caching-Konzept, das Lastspitzen ohne Hosting-Upgrade trägt, und ein Deployment, das Änderungen ohne Wartungsfenster ausliefert.

#Upgrades von Legacy-PHP 7.x auf 8.3

PHP 7.4 hat seit Ende 2022 keine Sicherheitsupdates mehr erhalten, und trotzdem läuft ein erheblicher Teil der Schweizer Firmen-Websites noch darauf. Das Upgrade auf PHP 8.3 ist keine Formalität, aber es ist planbar, wenn man es als Ingenieursaufgabe behandelt statt als Glücksspiel.

Unser Vorgehen: Zuerst entsteht ein Inventar über Composer, das jede Abhängigkeit und deren Kompatibilität mit PHP 8.x ausweist. Dann läuft die Codebasis durch statische Analyse mit PHPStan und Rector, die zeigt, was tatsächlich bricht: entfernte Funktionen, geänderte Typenbehandlung, Verhaltensänderungen bei Vergleichen und Strings. Auf dieser Basis entsteht ein Migrationsplan in Etappen, jede Etappe hinter Tests, die das bestehende Verhalten festhalten. Deprecations werden protokolliert und abgearbeitet, nicht unterdrückt. Der Wechsel der Produktionsumgebung erfolgt zuletzt, mit einem dokumentierten Rückweg für den Fall, dass eine Abhängigkeit sich in Produktion anders verhält als auf Staging.

Bei WordPress-Installationen kommt eine Besonderheit dazu: Der Core selbst ist mit aktuellen PHP-Versionen kompatibel, die Risiken sitzen in Plugins und in gewachsenem Theme-Code. Deshalb gehört zur Migration immer eine Plugin-Triage: Was wird weiter gepflegt, was hat einen Nachfolger, was ersetzen wir durch wenige Zeilen eigenen Code, der dann auch wartbar ist.

#WordPress-Core- und Plugin-Entwicklung in PHP

Ein großer Teil der PHP-Arbeit für Zürcher Kunden findet innerhalb von WordPress statt, und dort trennt sich solide Entwicklung schnell von zusammengeklicktem Bestand. Eigene Plugins entstehen bei uns nach den Core-Standards: Hooks statt Core-Modifikationen, Nonces und Capability-Checks an jedem Formular, Sanitizing bei der Eingabe, Escaping bei der Ausgabe und Datenbankzugriffe ausschließlich über vorbereitete Statements. Das ist keine Stilfrage, sondern die Grundlage dafür, dass ein Plugin die nächsten fünf WordPress-Versionen ohne Überraschungen übersteht.

Typische Aufgaben aus laufenden Projekten: eigene REST-Endpunkte innerhalb der WordPress-API für die Anbindung externer Systeme, eigene Gutenberg-Blöcke mit serverseitigem Rendering für Redaktionsteams, Import- und Synchronisationslogik für Produktdaten und die Ablösung überladener Multifunktions-Plugins durch schlanke, dokumentierte Eigenentwicklungen. Bei WooCommerce-Shops kommt die PHP-Seite des Handels dazu: Checkout-Anpassungen, Preislogik und die Anbindung von Zahlungs- und Versandpartnern.

#REST-APIs und Integrationen mit Schweizer Systemen

Kaum eine Anwendung für einen Zürcher Kunden lebt isoliert. Die Buchhaltung läuft auf Abacus oder bexio, das CRM ist Salesforce oder HubSpot, Zahlungen laufen über Datatrans, Wallee oder PostFinance, und irgendwo wartet ein internes System, das Daten liefern oder empfangen soll. Die Qualität dieser Integrationen entscheidet darüber, ob die Plattform im Alltag trägt oder zur Fehlerquelle wird.

Wir bauen Integrationen nach einem festen Muster: idempotente Webhook-Verarbeitung, damit doppelt zugestellte Ereignisse keine doppelten Buchungen erzeugen, Retry-Logik mit Backoff für vorübergehende Ausfälle der Gegenseite, eine Dead-Letter-Ablage für Ereignisse, die dauerhaft scheitern, und Logging, das Störungen sichtbar macht, bevor der Kunde sie meldet. Eigene APIs dokumentieren wir mit OpenAPI aus dem Code heraus, mit Authentifizierung über OAuth2 oder signierte Tokens und mit Rate-Limits, die öffentliche und interne Endpunkte unterschiedlich behandeln.

#Symfony und Laravel neben WordPress

Nicht jede Anforderung gehört in ein CMS. Wenn ein Projekt eine eigenständige Anwendung verlangt, ein Kundenportal mit komplexer Rechteverwaltung, ein internes Werkzeug mit Workflows, eine API-Plattform ohne redaktionelle Oberfläche, greifen wir zu Symfony oder Laravel. Symfony passt zu langlebigen Systemen mit klaren Modulgrenzen und ausgeprägter Zugriffskontrolle, Laravel zu Geschäftsanwendungen, die schnell produktiv werden müssen und danach geordnet wachsen. Beide Frameworks laufen bei uns auf demselben Qualitätsfundament wie die WordPress-Arbeit: PHP 8.3, statische Analyse, Tests auf den kritischen Pfaden und Deployments ohne Ausfallzeit.

Der häufigste Fall in der Praxis ist ohnehin die Kombination: WordPress als redaktionelle Plattform nach außen, daneben ein schlanker Symfony- oder Laravel-Dienst für die Logik, die im CMS falsch aufgehoben wäre. Die Grenze zwischen beiden ziehen wir bewusst und dokumentieren sie, damit spätere Entwickler sie nicht durch Abkürzungen aufweichen.

#Datenschutz: revDSG und DSGVO nebeneinander

Für Datenschutz gilt in Zürich eine doppelte Realität. Seit September 2023 ist das revidierte Schweizer Datenschutzgesetz in Kraft, oft als revDSG oder nDSG bezeichnet, und es gilt für jede Datenbearbeitung von Schweizer Unternehmen. Wer zusätzlich Kunden in der EU bedient, und das trifft auf die meisten Zürcher Firmen zu, fällt parallel unter die DSGVO. Die beiden Regelwerke sind verwandt, aber nicht identisch, und eine Website, die nur auf eines der beiden ausgelegt ist, hat eine Lücke.

Unsere Aufgabe ist die technische Seite dieser Pflichten. Formulare erheben nur die Daten, die der Zweck verlangt, und schreiben sie nicht beiläufig in Logs oder Analytics. Löschkonzepte sind implementiert: Wenn eine Aufbewahrungsfrist abläuft, löscht ein Prozess die Daten wirklich, statt dass ein Dokument behauptet, jemand würde es tun. Auskunfts- und Löschanfragen lassen sich technisch beantworten, weil die Anwendung weiß, wo personenbezogene Daten liegen, inklusive Backups und Drittsystemen. Einwilligungen werden dort eingeholt, wo sie nötig sind, und ihre Erteilung ist nachweisbar gespeichert. Die juristische Einordnung, welche Pflicht wann greift, gehört zu Ihrer Rechtsberatung; wir sorgen dafür, dass der Code jede Antwort umsetzen kann, die dort fällt.

#Hosting in der Schweiz und Datenresidenz

Die Frage nach dem Serverstandort kommt in Gesprächen mit Zürcher Kunden früh, und sie hat oft vertragliche Gründe: Kundenverträge, interne Richtlinien oder Branchenvorgaben verlangen, dass Daten die Schweiz nicht verlassen. Das ist mit einem PHP-Stack ohne Kompromisse machbar. Anbieter wie Infomaniak, Hostpoint, cyon oder METANET betreiben Rechenzentren in der Schweiz mit aktuellen PHP-Versionen, und für größere Setups stehen Schweizer Cloud-Umgebungen bereit.

Entscheidend ist, die Zusage zur Datenresidenz vollständig zu denken. Die Produktionsdatenbank in der Schweiz zu halten reicht nicht, wenn Backups zu einem US-Anbieter repliziert werden, Fehler-Tracking Stacktraces mit Nutzerdaten in ein Drittland schickt oder ein CDN Formulardaten durch fremde Infrastruktur leitet. Wir planen Hosting-Architekturen so, dass der Datenfluss als Ganzes der Vorgabe entspricht, und dokumentieren ihn so, dass Ihr Datenschutzberater damit arbeiten kann. Wo keine Residenzpflicht besteht, vergleichen wir nüchtern: EU-Hosting ist oft günstiger und für viele Projekte völlig ausreichend, und die Entscheidung fällt beim Kunden, nicht beim Dienstleister.

#Performance-Profiling und Wartung

Langsame PHP-Anwendungen haben selten mysteriöse Ursachen. In der Praxis sind es N+1-Abfragen aus dem ORM oder aus WordPress-Metadaten, fehlende Datenbankindizes, ein aufgeblähter Autoloader oder ein Object-Cache, der nie eingerichtet wurde. Wir messen, bevor wir ändern: Xdebug und Profiling in der Entwicklung, Blackfire oder Tideways gegen die Produktionslast, dazu die realen Nutzerdaten aus dem Feld statt Laborwerten. Aus der Messung entsteht eine priorisierte Liste, und die Abarbeitung beginnt bei dem Punkt mit dem größten Effekt pro Aufwand: Query-Optimierung, OPcache-Tuning, Objekt- und Seiten-Caching auf Redis, Bildauslieferung über ein CDN.

Nach dem Projekt beginnt der Teil, den der Schweizer Markt besonders ernst nimmt: der Betrieb. Wartung heißt bei uns definierte Reaktionswege für Sicherheitsupdates von PHP, WordPress und Abhängigkeiten, ein monatlicher Blick auf Fehlerraten und Performance-Trends und ein Runbook, mit dem auch ein internes Team eine Störung nachts einordnen kann. Der Umfang der Wartung richtet sich nach dem tatsächlichen Risiko der Anwendung, nicht nach einem Pauschalpaket, das niemand ausschöpft.

#Zweisprachig arbeiten: Deutsch und Englisch im selben Projekt

Zürich ist ein zweisprachiger Arbeitsmarkt, auch wenn keine Amtssprache das vorschreibt. Internationale Teams, ETH-Umfeld und ausländische Fachkräfte sorgen dafür, dass in vielen Firmen Deutsch und Englisch nebeneinander laufen: Das Fachgespräch findet auf Deutsch statt, das Ticket dazu auf Englisch, und im Review sitzen beide Welten am selben Pull Request.

Wir arbeiten in beiden Sprachen und ziehen eine klare Linie: Kommunikation in der Sprache des Teams, technische Artefakte auf Englisch. Code, Commits, Dokumentation und Architekturentscheidungen entstehen englisch, weil sie den nächsten Entwickler überleben müssen, und der spricht in Zürich mit guter Wahrscheinlichkeit kein Deutsch. Für die Website selbst gilt dieselbe Zweisprachigkeit auf der Inhaltsebene: Viele Zürcher Auftritte laufen Deutsch und Englisch parallel, manche zusätzlich Französisch oder Italienisch für den Gesamtmarkt Schweiz. Wir bauen die Mehrsprachigkeit als Struktur mit sauberen hreflang-Beziehungen und getrennt pflegbaren Inhalten auf, nicht als nachträglich übersetzte Kopie.

#Remote-Zusammenarbeit aus der EU mit Kunden in Zürich

Die Zusammenarbeit über die Grenze ist im Alltag unspektakulärer, als sie im ersten Gespräch klingt. Zürich und unsere Standorte liegen in derselben Zeitzone, es gibt keinen Versatz bei Abstimmungen und keine Übergaben über Nacht. Die Vertragsseite ist ein gewöhnliches B2B-Verhältnis mit Rechnungstellung an ein Schweizer Unternehmen, NDA auf Wunsch vorab, und die Arbeit läuft in Ihren Repositories und Umgebungen, sodass jeder Stand jederzeit bei Ihnen liegt.

Der Rhythmus ist fest: wöchentlich sichtbare Meilensteine auf Staging, Reviews an realem Code statt Statusfolien und Entscheidungen schriftlich festgehalten, damit sie in sechs Monaten nachvollziehbar sind. Für Kickoff, Workshops oder die Abschlussübergabe sind Termine vor Ort in Zürich möglich, die Distanz ist eine Zugfahrt, kein Interkontinentalflug. Die meisten Kunden stellen nach dem zweiten Sprint fest, dass die Frage nach dem Standort im Tagesgeschäft keine Rolle mehr spielt, weil Erreichbarkeit und Liefertakt die Zusammenarbeit tragen.

#PHP-Projekt in Zürich starten

Der Einstieg ist unkompliziert: Beschreiben Sie in wenigen Sätzen, worum es geht, ein Relaunch, ein PHP-Upgrade, eine Integration, ein neues Portal oder die Übernahme einer bestehenden Anwendung. Nennen Sie den bestehenden Stack, soweit bekannt, den Zeitrahmen und die Vorgaben zu Datenschutz oder Hosting. Wir antworten innerhalb eines Werktags mit Rückfragen und einem Vorschlag für die ersten Schritte, auf Deutsch oder Englisch, wie es für Ihr Team passt.