PHP-Entwickler in Berlin

#Warum in Berlin so viel Legacy-PHP läuft

Berlin hat zwischen 2010 und 2018 eine Gründungswelle erlebt, die kaum eine andere europäische Stadt in dieser Dichte kennt. Viele der damals entstandenen Produkte laufen noch heute, und ein erheblicher Teil davon läuft auf PHP: Buchungsplattformen, Marktplätze, interne Tools, Kundenportale. Der Code stammt aus einer Zeit, in der PHP 5.6 aktuell war, Composer sich gerade durchsetzte und Tests als optional galten. Die Agenturen, die diese Systeme gebaut haben, existieren teils nicht mehr, teils haben sie sich neu ausgerichtet, und die Anwendungen sind bei ihren Betreibern geblieben.

Das Ergebnis ist ein Muster, das uns in Berliner Erstgesprächen immer wieder begegnet: Eine Anwendung, die täglich Umsatz erwirtschaftet, steht auf PHP 7.4 oder älter, für das es seit Jahren keine Sicherheitsupdates mehr gibt. Niemand im Haus traut sich an den Code, weil jede Änderung unvorhersehbare Nebenwirkungen hat. Der ursprüngliche Entwickler ist seit drei Jahren weg, die Dokumentation besteht aus dem Code selbst, und jede neue Anforderung wird teurer als die letzte.

Genau für diese Situation gibt es einen belastbaren Weg heraus, und er beginnt nicht mit einem Neuschreiben. Ein Rewrite klingt verlockend und scheitert in der Praxis regelmäßig daran, dass die alte Anwendung Geschäftsregeln enthält, die nirgends dokumentiert sind. Wer sie wegwirft, wirft Jahre an eingebautem Wissen weg. Der tragfähige Weg ist die schrittweise Modernisierung: erst verstehen, dann absichern, dann migrieren, dann verbessern. Wie das konkret abläuft, beschreibt diese Seite.

#Was Sie von einer PHP-Agentur in Berlin erwarten können

Wer nach einer PHP-Agentur in Berlin sucht, hat meist eines von drei Problemen: eine alte Anwendung, die modernisiert werden muss, ein neues Backend, das gebaut werden soll, oder ein Inhouse-Team, das Verstärkung braucht. Alle drei Fälle verlangen dieselbe Grundhaltung, aber unterschiedliche Arbeitsweisen.

Bei der Modernisierung zählt Zurückhaltung. Eine gute PHP-Agentur ändert am Anfang möglichst wenig und misst möglichst viel: Welche PHP-Version läuft wirklich, welche Composer-Pakete sind verwaist, wo liegt Geschäftslogik in Templates oder SQL-Statements, welche Pfade sind durch Tests abgedeckt. Erst wenn dieses Bild steht, beginnt die eigentliche Arbeit, und zwar in Etappen, die einzeln in Produktion gehen. Wer Ihnen für eine ungesehene Codebasis einen Festpreis für die Komplettmigration nennt, hat entweder die Codebasis nicht verstanden oder den Preis mit Puffer für alle Eventualitäten kalkuliert.

Beim Neubau zählt Architekturdisziplin. PHP 8.3 mit strikter Typisierung, PSR-12, statische Analyse mit PHPStan auf hohem Level und Tests auf den Pfaden, an denen Geld oder Daten hängen, sind der Stand der Technik, nicht die Kür. Dazu gehört die unbequeme Ehrlichkeit, Features zu hinterfragen, die Aufwand erzeugen, aber keinen Wert liefern.

Bei der Teamverstärkung zählt Anschlussfähigkeit. Externe Senior-Entwickler, die ihre eigenen Konventionen mitbringen und am Team vorbei arbeiten, hinterlassen mehr Reibung als Fortschritt. Die Arbeit findet in Ihrem Repository statt, nach Ihren Review-Regeln, mit Commits, die Ihr Team lesen und weiterführen kann.

#Modernisierung von PHP 5.6 und 7.x auf 8.3

Die technische Substanz der Modernisierungsarbeit verdient einen eigenen Abschnitt, weil hier die meisten Projekte entschieden werden. Der Sprung von PHP 5.6 oder 7.x auf 8.3 ist kein Versionsupdate, sondern eine Serie von Verhaltensänderungen: geänderte Typvergleiche, entfernte Funktionen, strengere Fehlerbehandlung, neue Deprecations in jeder Zwischenversion. Eine Codebasis, die diese Sprünge nie mitgemacht hat, bricht nicht an einer Stelle, sondern an hunderten kleinen.

Deshalb arbeiten wir mit Werkzeugen, die diese Stellen finden, bevor die Anwendung sie findet. PHPStan zeigt auf niedrigem Level zunächst, wo die Codebasis heute steht, und wächst mit jeder Etappe auf ein strengeres Level mit. Rector automatisiert die mechanischen Anpassungen, also die tausend kleinen Umschreibungen, die kein Mensch fehlerfrei von Hand macht. PHPUnit-Tests entstehen vor der Migration um das bestehende Verhalten herum, nicht danach um das neue, denn das Sicherheitsnetz muss den Ist-Zustand abbilden, damit Abweichungen auffallen.

Die Migration selbst läuft in Etappen, die einzeln deploybar sind. Erst die Abhängigkeiten: verwaiste Pakete werden ersetzt oder ihre Funktion wird in eigenen Code überführt. Dann die Sprachversion, Zwischenschritt für Zwischenschritt, mit Protokoll der Verhaltensänderungen. Dann das Framework, falls eines im Spiel ist. Zuletzt die Aufräumarbeit: tote Codepfade, doppelte Logik, Altlasten in der Datenbank. Nach jeder Etappe läuft die Anwendung in Produktion, und nach jeder Etappe können Sie das Projekt pausieren, ohne in einem halbfertigen Zustand zu stehen. Diese Unterbrechbarkeit ist für Berliner Startups mit schwankenden Budgets kein Randthema, sondern oft das Entscheidungskriterium.

Technische Schulden verschwinden dabei nicht vollständig, und das zu behaupten wäre unseriös. Sie werden sichtbar, priorisiert und planbar. Der Unterschied zu vorher: Ihr Team weiß danach, wo die Schulden liegen und was ihre Tilgung kostet.

#Composer-Abhängigkeiten und fehlende Tests

Zwei Größen entscheiden darüber, ob eine Migration Wochen oder Monate dauert: der Zustand der Abhängigkeiten und die Frage, ob es Tests gibt. Beide stehen in der Bestandsaufnahme ganz oben, noch vor der Sprachversion.

Bei den Abhängigkeiten sortieren wir jedes Composer-Paket in eine von vier Gruppen. Gepflegt und mit PHP 8.3 kompatibel: dort genügt die Aktualisierung. Gepflegt, aber mit geänderter API: die Anpassung wird Teil einer Etappe, und viele Bibliotheken liefern dafür eigene Rector-Regeln mit. Aufgegeben, aber mit klarem Nachfolger: der Wechsel wird eingeplant, inklusive der Stellen, an denen sich das Verhalten unterscheidet. Aufgegeben ohne Nachfolger: hier ist die ehrlichste Antwort meist, die tatsächlich genutzten Teile des Pakets in eigenen, getesteten Code zu überführen, statt einen ungepflegten Fork zu erben. Ein Lauf von composer audit gegen die Advisory-Datenbank zeigt zusätzlich, welche dieser Pakete bekannte Sicherheitslücken tragen. In geerbten Berliner Codebasen ist diese Liste beim ersten Mal selten kurz.

Bei den Tests gilt eine unbequeme Wahrheit: Eine Anwendung ohne Tests bekommt keine nachträgliche Vollabdeckung. Das wäre teuer und ginge am Ziel vorbei. Was sie bekommt, sind Charakterisierungstests auf der Ebene, die sich ohne Umbau prüfen lässt, meist Anfrage hinein, Antwort und Datenbankzustand heraus. Diese Tests halten das heutige Verhalten fest, auch dort, wo es fachlich fragwürdig ist, denn ihr Zweck ist nicht Korrektheit, sondern Unveränderlichkeit während der Migration. Feinere Tests entstehen erst danach und genau dort, wo der Code beim Refactoring ohnehin aufgetrennt wird: feste Instanziierungen mitten in der Logik, statische Zugriffe auf globale Funktionen, Geschäftsregeln, die im Controller wohnen.

#Datenbank und Query-Profiling unter Wachstumslast

Wenn eine Anwendung unter wachsender Last langsam wird, liegt die Ursache selten in PHP selbst, sondern in dem, was PHP die Datenbank fragt. Deshalb beginnt Performance-Arbeit bei uns mit einer Messung auf Abfrageebene und nicht mit einer zusätzlichen Cache-Schicht, die das Problem nur nach hinten verschiebt.

Der erste Blick geht in das Slow-Query-Log und in die Zahl der Abfragen pro Seitenaufruf. Typische Funde in gewachsenen Anwendungen: Schleifen, die pro Datensatz eine weitere Abfrage auslösen, weil das ORM nachlädt; Filter und Sortierungen auf Spalten ohne passenden zusammengesetzten Index; Paginierung über hohe OFFSET-Werte, deren Kosten mit jeder Seite steigen; Zählabfragen, die bei jedem Aufruf die vollständige Tabelle berühren. EXPLAIN auf den teuersten Abfragen zeigt dann, ob ein Index fehlt, ob er existiert und nicht genutzt wird, oder ob die Abfrage selbst falsch gestellt ist.

Die Reihenfolge der Maßnahmen ist nicht beliebig. Erst die Abfrage korrigieren, dann den Index setzen, dann über Caching sprechen. Ein Cache vor einer schlechten Abfrage verbirgt deren Kosten so lange, bis er kalt ist, und das ist erfahrungsgemäß der Moment mit dem höchsten Verkehr. Arbeit, die lange dauert, gehört ohnehin aus dem Anfragezyklus heraus in Queues mit Workern, deren Fehlerfälle sichtbar sind statt still zu scheitern. Eine zusätzliche Leseinstanz kommt zuletzt in Frage, denn eine Replik vervielfacht schlechte Abfragen, statt sie zu heilen.

#Symfony und Laravel im Berliner Umfeld

Berlin ist einer der aktivsten PHP-Standorte Europas. Die Berlin PHP Usergroup trifft sich seit Jahren regelmäßig, SymfonyLive macht als Konferenz Station in der Stadt, und für Laravel existiert eine eigene Meetup-Szene. Diese Dichte hat eine praktische Konsequenz für Unternehmen: Beide Frameworks sind hier keine Exoten, für beide gibt es lokale Entwickler, und ein System, das sauber auf Symfony oder Laravel steht, findet auch in fünf Jahren noch Menschen, die es weiterentwickeln können. Das ist ein unterschätztes Argument gegen Eigenbau-Frameworks, an denen viele Berliner Legacy-Projekte heute tragen.

Die Wahl zwischen den beiden entscheidet sich am Lebenszyklus des Systems. Laravel ist die richtige Basis, wenn ein Produktteam schnell iterieren will: ein SaaS-Produkt, ein Kundenportal, ein internes Tool mit wachsendem Funktionsumfang. Eloquent, Queues, Scheduler und das Ökosystem an gepflegten Paketen verkürzen den Weg von der Idee zur produktiven Funktion. Symfony ist die richtige Basis für Systeme mit langem Horizont: Plattformen, die mehrere Teams berühren, Integrationen in bestehende Unternehmenslandschaften, Anwendungen mit komplexen Berechtigungsmodellen. Die Komponentenarchitektur, Messenger für asynchrone Verarbeitung und Doctrine mit sauber gemappten Aggregaten zahlen sich dort aus, wo Struktur wichtiger ist als Geschwindigkeit der ersten Wochen.

Wir legen die Framework-Empfehlung für Ihr Projekt schriftlich vor, mit Begründung und mit den Punkten, die dagegen sprechen. Eine Empfehlung ohne dokumentierte Gegenargumente ist keine Empfehlung, sondern eine Vorliebe.

#Headless und API-first: das Backend als eigenständiges Produkt

Ein wachsender Teil der Berliner Anfragen betrifft Architekturen, in denen das PHP-Backend gar keine Seiten mehr rendert. Das Frontend ist eine React- oder Vue-Anwendung, eine native App oder eine statisch generierte Site, und das Backend liefert ausschließlich Daten über eine API. Diese Trennung passt zur Teamstruktur vieler Scale-ups, in denen Frontend und Backend getrennt besetzt sind und unabhängig deployen wollen.

API-first heißt dabei mehr als “es gibt eine REST-Schnittstelle”. Es heißt, dass die API als Produkt behandelt wird: ein dokumentierter Vertrag in OpenAPI, der aus dem Code generiert wird statt neben ihm zu altern, Versionierung mit angekündigten Übergangsfristen, konsistente Fehlerantworten, Idempotenz bei zustandsändernden Aufrufen und Rate Limiting, das legitime Clients nicht behindert. Für interne Schnittstellen zwischen Diensten kommt hinzu: nachvollziehbare Authentifizierung von Dienst zu Dienst und Tracing, das einen Fehler über Dienstgrenzen hinweg verfolgbar macht.

Ein Sonderfall, der in Berlin häufig vorkommt: ein bestehendes WordPress- oder WooCommerce-System, dessen Geschäftslogik über Jahre in Plugins gewachsen ist. Statt das System zu ersetzen, extrahieren wir die kritische Logik in einen eigenen Symfony- oder Laravel-Dienst mit sauberer API. WordPress bleibt Redaktions- und Shop-Oberfläche, die Logik wird testbar, versionierbar und unabhängig skalierbar. Das ist oft der wirtschaftlichste Weg, weil er das funktionierende System nicht anfasst und trotzdem die Wartbarkeit der Kernlogik herstellt.

#REST und GraphQL für entkoppelte Frontends

Für ein entkoppeltes Frontend ist REST in den meisten Berliner Projekten die richtige Voreinstellung und GraphQL die begründete Ausnahme. REST bleibt über HTTP-Caching, Statuscodes und Zwischenschichten hinweg berechenbar, jeder Endpunkt lässt sich einzeln versionieren, und die Fehlersuche funktioniert mit den Werkzeugen, die im Team ohnehin vorhanden sind. Auf der PHP-Seite trägt API Platform in Symfony den größten Teil dieser Arbeit, in Laravel übernehmen Form Requests, Resources und Policies dieselbe Rolle, jeweils mit einem OpenAPI-Vertrag, der aus dem Code entsteht.

GraphQL rechnet sich, wenn mehrere Clients mit unterschiedlichem Datenbedarf auf dieselbe Domäne zugreifen, etwa ein Web-Frontend, eine native App und ein Partner-Client, und wenn die Zahl der Spezialendpunkte in REST sonst unkontrolliert wächst. Der Preis fällt im Backend an. Resolver erzeugen ohne Gegenmaßnahme genau die Nachlade-Muster aus dem vorigen Abschnitt, weshalb Batch-Loader nicht optional sind. Dazu kommen eine Begrenzung von Tiefe und Komplexität der Abfragen, damit ein einzelner Client den Server nicht mit einer verschachtelten Anfrage belegt, und persistierte Abfragen, wenn an der Kante gecacht werden soll. Als Bausteine nutzen wir Lighthouse in Laravel, GraphQLite oder API Platform in Symfony und WPGraphQL, wenn WordPress die Inhaltsquelle ist.

In beiden Fällen bleibt eines gleich: Das Schema ist der Vertrag zwischen Frontend- und Backend-Team. Änderungen daran laufen über einen angekündigten Weg mit Übergangsfrist, nicht über eine Nachricht im Chat.

#WordPress-PHP: Hooks, eigene Plugins und WP-CLI

In Berliner Produktfirmen läuft WordPress selten für sich allein. Es steht neben dem eigentlichen Produkt und trägt Marketing-Auftritt, Karrierebereich, Dokumentation oder Blog, häufig als Inhaltsquelle für ein Frontend, das mit React oder Astro gebaut ist. Die PHP-Arbeit daran ist deshalb weniger Theme-Gestaltung als Backend-Handwerk.

Eigene Funktionalität entsteht als Plugin mit klar benannten Hooks, nie als Änderung am Core und nie als Sammlung von Schnipseln in der functions.php eines Themes, das beim nächsten Relaunch verschwindet. Inhaltstypen, Meta-Felder und deren Sichtbarkeit in der REST-Schnittstelle werden im Code definiert, damit sie versioniert sind und in jeder Umgebung gleich aussehen. Für die Anbindung eines entkoppelten Frontends registrieren wir eigene Routen über register_rest_route mit expliziten Berechtigungsprüfungen, statt die Standardendpunkte weit zu öffnen.

Zwei Punkte kosten in gewachsenen Installationen regelmäßig Leistung und werden fast nie geprüft: automatisch geladene Optionen, die über Jahre auf mehrere Megabyte anwachsen und bei jedem Aufruf gelesen werden, und der Standard-Cron, der am Besucherverkehr hängt statt an einem Systemdienst. Beides ist in kurzer Zeit behoben und wirkt unmittelbar.

WP-CLI macht diese Arbeit reproduzierbar. Datenmigrationen, Ersetzungen beim Domainwechsel, Massenänderungen an Metadaten und wiederkehrende Wartungsaufgaben laufen als versionierte Kommandos, die im Repository liegen und sich in der Pipeline prüfen lassen, statt als einmalige Klicks im Adminbereich, die niemand dokumentiert und niemand wiederholen kann.

#Zusammenarbeit mit Inhouse-Teams: Staff Augmentation ohne Reibung

Viele Berliner Unternehmen haben ein eigenes Entwicklungsteam und brauchen keine Agentur, die das Produkt übernimmt. Sie brauchen zusätzliche Senior-Kapazität für ein abgegrenztes Thema: eine Migration, die neben dem Tagesgeschäft nicht zu stemmen ist, ein API-Modul, für das intern die Erfahrung fehlt, oder eine Phase, in der eine Stelle unbesetzt ist und das Recruiting Monate dauert.

Für diese Konstellation gelten bei uns feste Regeln. Die Arbeit findet in Ihrem Repository statt, nicht in unserem. Ihr Team behält die Architekturhoheit, wir liefern Vorschläge als Pull Requests mit Begründung, nicht als vollendete Tatsachen. Reviews laufen in beide Richtungen: Wir prüfen Code Ihres Teams, wenn das gewünscht ist, und unser Code wird von Ihrem Team geprüft, damit das Wissen im Haus bleibt. Und jedes Engagement endet mit einer dokumentierten Übergabe, denn das Ziel von Staff Augmentation ist ein Team, das nach unserem Ausstieg stärker ist als vor unserem Einstieg, nicht eines, das dauerhaft an uns hängt.

Der Unterschied zu klassischem Bodyleasing liegt in der Verantwortung. Wir vermitteln keine Einzelpersonen, die Stunden abrechnen, sondern übernehmen Ergebnisverantwortung für das vereinbarte Thema, inklusive der unbequemen Momente, in denen ein geplanter Ansatz sich als falsch herausstellt und das gesagt werden muss.

#Deployment, Review und Übergabe an Ihr Team

Arbeiten wir in einem bestehenden Repository, übernehmen wir dessen Regeln. Wo noch keine bestehen, schlagen wir einen Aufbau vor, der ohne schweres Werkzeug auskommt. Die Pipeline prüft in dieser Reihenfolge: Coding-Standard mit PHPCS gegen PSR-12, statische Analyse mit PHPStan auf dem für diese Codebasis vereinbarten Level, Unit- und Integrationstests, danach der Bau des Artefakts mit reinen Produktionsabhängigkeiten. Was rot ist, geht nicht weiter, auch nicht mit guter Begründung, denn eine einmal gewährte Ausnahme wird zur Regel.

Ausgeliefert wird ein unveränderliches Artefakt, das in Staging und Produktion identisch ist, mit einem Umschalten auf die neue Version ohne Wartungsfenster und mit einem Rückweg, der geprobt und nicht nur beschrieben ist. Datenbankmigrationen laufen getrennt vom Code-Deployment und in beide Richtungen verträglich, damit ein Rollback nicht an einer bereits geänderten Spalte scheitert. Für riskante Änderungen an laufenden Anwendungen sind Feature-Schalter das ruhigere Mittel als ein großes Release am Freitag.

Reviews halten wir klein. Ein Pull Request, der eine Sache tut, wird ernsthaft geprüft, einer mit vierzig geänderten Dateien wird durchgewinkt. Entscheidungen, die länger wirken als der laufende Sprint, landen als kurzer Text im Repository, mit Kontext, getroffener Wahl und den verworfenen Alternativen. Das kostet wenige Minuten und beantwortet Fragen, die sonst zwei Jahre später niemand mehr beantworten kann.

Am Ende steht die Übergabe, und sie besteht nicht aus Zugängen. Sie besteht aus einem Runbook für Deploy, Rollback und die wahrscheinlichsten Störungen, aus einer lokalen Umgebung, die ein neuer Entwickler an einem Vormittag zum Laufen bringt, aus einer benannten Liste der bekannten technischen Schulden mit Einschätzung ihrer Dringlichkeit und aus einer Sitzung mit Ihrem Team, in der Fragen am lebenden Code gestellt werden statt an einer Präsentation.

#DSGVO und TDDDG im Backend: Pflichten, die im Code landen

Datenschutz wird in vielen Projekten als Frontend-Thema behandelt: ein Consent-Banner, eine Datenschutzerklärung, fertig. Für ein PHP-Backend, das personenbezogene Daten verarbeitet, greift das zu kurz, und die Berliner Datenschutzaufsicht gehört nicht zu den nachsichtigsten.

Im Backend wird die DSGVO zu konkreten Engineering-Aufgaben. Datensparsamkeit heißt: Felder, für die kein dokumentierter Zweck existiert, werden nicht gespeichert, auch wenn sie “später vielleicht nützlich” wären. Löschkonzepte heißen: Aufbewahrungsfristen sind als automatisierte Jobs umgesetzt, die nachweisbar laufen, nicht als Absatz in einem Dokument. Auskunftsersuchen heißen: Die Daten einer Person lassen sich über alle Tabellen und angebundenen Systeme hinweg zusammenstellen, ohne dass ein Entwickler zwei Tage lang SQL schreibt. Auftragsverarbeitung heißt: Für jeden externen Dienst, den das Backend aufruft, ist dokumentiert, welche Daten ihn erreichen.

Das TDDDG ergänzt diese Pflichten an der Schnittstelle zum Endgerät: Zugriffe auf Informationen im Endgerät des Nutzers brauchen eine Einwilligung, und das Backend muss mit dem Consent-Status umgehen können, der aus dem Frontend ankommt. Praktisch heißt das: Einwilligungen kommen als prüfbare, zeitgestempelte Datensätze ins Backend, und Verarbeitungen, die an eine Einwilligung gebunden sind, prüfen diesen Status, statt ihn vorauszusetzen.

Wir bauen diese Anforderungen in die Architektur ein, bevor die erste Tabelle angelegt wird. Nachträglich eingezogener Datenschutz kostet ein Mehrfaches und bleibt lückenhaft.

#Drei typische Projektprofile mit technischen Zielwerten

Statt erfundener Erfolgsgeschichten: drei Projektprofile, wie sie in Berlin typischerweise vorkommen, mit den technischen Zielwerten, die wir für solche Projekte ansetzen. Ob ein konkretes Projekt diese Werte erreicht, hängt von seiner Ausgangslage ab, und genau das klärt die Bestandsaufnahme.

Profil eins, die geerbte Plattform: eine Buchungs- oder Marktplatzanwendung auf PHP 7.2, entstanden bei einer nicht mehr existierenden Agentur, ohne Tests, mit Composer-Paketen, die seit Jahren keine Updates gesehen haben. Zielwerte für die Modernisierung: PHP 8.3 mit aktiven Sicherheitsupdates, PHPStan mindestens Level 6 auf dem gesamten Bestandscode, Testabdeckung auf allen Pfaden, die Zahlungen oder personenbezogene Daten berühren, und ein Deploy-Weg, der ohne manuelle Schritte auf dem Server auskommt.

Profil zwei, das API-Backend für ein Scale-up: ein neues Symfony- oder Laravel-Backend hinter einem React-Frontend und einer nativen App. Zielwerte: OpenAPI-Dokumentation, die aus dem Code generiert wird, Antwortzeiten der API-Endpunkte im zweistelligen Millisekundenbereich unter realer Last, Idempotenz auf allen zustandsändernden Endpunkten und eine CI-Pipeline, die Lint, statische Analyse und Tests vor jedem Merge erzwingt.

Profil drei, die Team-Verstärkung: ein Inhouse-Team von drei bis acht Entwicklern, das eine PHP-Migration neben dem Tagesgeschäft nicht schafft. Zielwerte: Die Migration läuft in Etappen, die das Feature-Tempo des Teams nicht blockieren, jede Etappe geht einzeln in Produktion, und am Ende existiert eine Übergabedokumentation, mit der das Team die Anwendung ohne externe Hilfe weiterentwickelt.

#PHP-Projekt in Berlin anfragen

Wenn eines der drei Profile Ihrer Situation ähnelt oder Ihr Fall anders liegt, genügt für den Einstieg eine kurze Beschreibung: Was läuft heute, was soll sich ändern, welche Fristen bestehen. Auf dieser Basis schlagen wir den nächsten Schritt vor, in den meisten Fällen eine Bestandsaufnahme der vorhandenen Codebasis oder ein Architekturgespräch für den Neubau. Verwandte Leistungen für Berlin: WordPress-Entwicklung in Berlin für Projekte im WordPress-Umfeld und WooCommerce-Entwicklung in Berlin für Shop-Systeme, deren Backend-Logik wachsen soll.

Zuletzt aktualisiert: 26. August 2026