React-Agentur finden: Woran du gute React-Entwicklung im Code erkennst

Wer eine React-Agentur sucht, bekommt überall dieselben Signale: schicke Referenzseiten, ein paar Logos, „langjährige Erfahrung“. Nur sagt nichts davon etwas darüber aus, wie der Code aussieht, den du am Ende bezahlst und pflegen lassen musst. Das Problem: Die teuren Fehler in React-Projekten sind unsichtbar. Man sieht sie nicht auf der Referenzseite, sondern im zweiten Jahr – wenn ein kleines Feature drei Tage kostet, das Frontend bei Google nicht auftaucht oder ein Upgrade das halbe Projekt umwirft. Deshalb hier die Prüfliste, die ich selbst anlege, wenn ich ein fremdes React-Projekt übernehme: sechs Dinge, die du im Code nachsehen oder erfragen kannst, bevor du unterschreibst – auch ohne selbst zu entwickeln.

Welche React-Agentur würde ich empfehlen? Die ehrliche Antwort

Die ehrliche Antwort lautet: keine bestimmte – aber eine mit drei Eigenschaften. Sie fragt zuerst, was du bauen willst, bevor sie React vorschlägt. Sie zeigt dir Code, nicht nur Screenshots. Und sie gibt dir Repository und Zugänge von Tag eins, ohne dass du danach fragen musst.

Alles andere – Teamgröße, Standort, Zahl der Referenzen – ist nachrangig. Ich habe große Agenturprojekte übernommen, die technisch verwahrlost waren, und Ein-Mann-Projekte, die nach fünf Jahren noch sauber liefen. Was den Unterschied macht, sind Entscheidungen, die man im Code sehen kann. Genau die stehen weiter unten.

Wofür React die richtige Wahl ist – und wann eine Website ohne React besser fährt

Bevor du eine React-Agentur suchst, solltest du wissen, ob du überhaupt React brauchst. Denn der teuerste Fehler passiert vor der ersten Zeile Code.

React lohnt sich, wo Nutzer arbeiten statt nur lesen. Dashboards mit Filtern und Live-Daten. Konfiguratoren, in denen sich bei jeder Eingabe die halbe Seite ändert. Portale hinter einem Login. Buchungsstrecken mit mehreren Schritten und Zwischenzuständen. Überall dort löst React ein echtes Problem: Es hält eine komplexe Oberfläche und die Daten dahinter zuverlässig synchron, ohne dass jemand von Hand DOM-Elemente umbaut.

Für eine Firmen-Website mit fünfzehn Unterseiten ist React die falsche Wahl. Da hast du am Ende ein System, das ohne Entwickler nicht pflegbar ist, mehr Wartung braucht und im Zweifel schlechter lädt als eine simple, vorgerendrete Seite aus einem CMS. Wenn Inhalte vor allem gelesen und redaktionell gepflegt werden, ist ein gutes CMS die günstigere und langlebigere Antwort – wir haben die Varianten in Headless CMS vs. WordPress gegenübergestellt.

Der Test für die Agentur: Erzähl im Erstgespräch, was du vorhast, und schau, ob sie dir React ausredet, wenn es nicht passt. Wer jedes Projekt in dieselbe Technik packt, verkauft dir seinen Werkzeugkasten, nicht deine Lösung.

Prüfpunkt 1: Server-Rendering oder alles im Browser?

Das ist der Punkt mit den größten finanziellen Folgen, weil daran hängt, ob deine Inhalte bei Google überhaupt existieren.

Eine klassische Single-Page-App liefert dem Browser zuerst ein fast leeres HTML-Dokument und baut die Seite danach im Browser zusammen. Für einen Login-Bereich ist das völlig in Ordnung. Für alles, was gefunden werden soll, ist es ein Risiko: Der Crawler bekommt eine leere Hülle und muss darauf hoffen, dass er das JavaScript später nachrendert.

So prüfst du es selbst: Öffne die Referenzseite der Agentur, drück Strg + U (Mac: Cmd + Alt + U) und such im Quelltext nach einem Satz, den du auf der Seite lesen kannst. Findest du ihn: gut, es wird serverseitig gerendert. Findest du nur ein leeres <div id="root"> und eine Liste von Skripten: Die Seite entsteht komplett im Browser.

Und jetzt der Teil, den nur jemand mit React-Erfahrung dazusagt: Bei Next.js reicht dieser Test nicht. Dort wird auch eine Client-Komponente für den ersten Aufruf serverseitig vorgerendert – der Text steht also im Quelltext, obwohl im Browser trotzdem das komplette Bauteil noch einmal geladen und „hydratisiert“ wird. Die aussagekräftigere Frage an die Agentur lautet deshalb: Wie viele Dateien im Projekt beginnen mit 'use client' – und warum? Im App Router ist alles standardmäßig eine Server-Komponente. Wenn trotzdem fast jede Datei zur Client-Komponente erklärt wurde, hat jemand die Fehlermeldung weggeklickt, statt die Architektur zu klären. Das kostet dich Ladezeit auf jeder einzelnen Seite.

Prüfpunkt 2: Wie groß ist das JavaScript, das dein Kunde lädt?

JavaScript ist die teuerste Art von Bytes. Ein Bild muss nur geladen und angezeigt werden – JavaScript muss geladen, geparst und ausgeführt werden, und das auf dem Telefon deines Kunden, nicht auf dem MacBook des Entwicklers.

So misst du es: Referenzseite im Inkognito-Fenster öffnen, Entwicklertools mit F12, Reiter Netzwerk, Filter auf JS, Seite neu laden. Unten steht, wie viel übertragen wurde. Wiederhol das mit der Drosselung auf „Fast 4G“ – dann siehst du, was ein Besucher im Zug erlebt.

Ich nenne dir hier bewusst keine Grenze in Kilobyte, weil sie ohne Kontext nichts wert ist: Ein Dashboard darf mehr laden als eine Textseite. Die belastbare Frage ist nicht wie viel, sondern wofür. Wenn eine Seite, die im Wesentlichen Text zeigt, ein Megabyte JavaScript herunterlädt, wurde eine App gebaut, wo eine Seite gereicht hätte. Häufigste Ursachen in unseren Übernahmen: eine Animationsbibliothek für zwei Einblendeffekte, eine komplette UI-Bibliothek für vier Buttons, ein Datums-Paket in drei Versionen gleichzeitig, weil verschiedene Abhängigkeiten es mitbringen.

Was am Ende zählt, misst Google mit den Core Web Vitals – der größte sichtbare Inhalt soll in unter 2,5 Sekunden stehen. Wie du diese Werte selbst erhebst und welche Bremsen am häufigsten dahinterstecken, steht in Core Web Vitals verbessern.

Prüfpunkt 3: Welche React- und Next.js-Version – und wann war das letzte Upgrade?

React und Next.js entwickeln sich in einem festen Takt weiter: Next.js 15 erschien am 21. Oktober 2024, Next.js 16 genau ein Jahr später am 21. Oktober 2025; React 19 wurde am 5. Dezember 2024 stabil. Ungefähr ein großer Versionssprung pro Jahr – wer zwei Majors zurückliegt, ist also rund zwei Jahre hinterher.

Das ist keine Kosmetik. Ein Projekt, das zwei Jahre nicht aktualisiert wurde, hat drei Probleme auf einmal: Sicherheitsmeldungen in Abhängigkeiten, die niemand mehr sauber schließen kann; neue Entwickler, die sich in Mustern zurechtfinden müssen, die es so nicht mehr gibt; und ein Upgrade, das irgendwann zwangsläufig kommt und dann als großer Brocken statt in kleinen Schritten bezahlt wird.

Frag konkret: „Welche React- und Next.js-Version läuft in dem Projekt, das ihr mir zeigt? Und wann war das letzte Framework-Upgrade – zeigt mir bitte den Commit.“ Eine Agentur mit gepflegten Projekten beantwortet das in dreißig Sekunden. Kommt stattdessen „das läuft doch stabil“, weißt du, was die Antwort war.

Dieselbe Frage stellen wir übrigens auch bei Bestandsprojekten, die wir übernehmen. Wie so ein Audit abläuft und was es kostet, haben wir am Beispiel Laravel in Laravel-Agentur wechseln aufgeschrieben – das Vorgehen im Frontend ist identisch.

Prüfpunkt 4: Funktioniert das Formular ohne JavaScript?

Formulare sind der Ort, an dem sich Sorgfalt am schnellsten zeigt. Und der Punkt ist nicht so dogmatisch, wie er klingt – es geht nicht darum, dass jedes Formular ohne JavaScript funktionieren muss. Es geht darum, ob jemand darüber nachgedacht hat.

Der eigentliche Prüfpunkt ist die Validierung. Prüfungen im Browser sind Bedienkomfort, mehr nicht: Sie sagen dem Nutzer freundlich, dass die E-Mail-Adresse fehlt. Sicherheit entsteht ausschließlich auf dem Server. Wenn jemand die Anfrage direkt an die Schnittstelle schickt und dabei ein Feld weglässt, den Preis manipuliert oder eine fremde Kundennummer einträgt – was passiert dann? Wenn dabei etwas durchgeht, lag die Regel an der falschen Stelle. Genau daran hängt auch die saubere Grenze zwischen Frontend und Backend: Das Backend besitzt Daten und Regeln, das Frontend stellt dar und sammelt Eingaben.

Ich bin da ehrlich: Unser eigenes Kontaktformular ist eine React-Komponente und braucht JavaScript. Dafür prüft der Server jedes Feld noch einmal komplett neu, unabhängig davon, was der Browser geschickt hat – inklusive Längenbegrenzungen, Spam-Bewertung und Rate-Limit pro IP. Das ist die Reihenfolge, auf die es ankommt.

Dazu gehört der zweite Blick: Bedienbarkeit ohne Maus. Geh mit der Tabulatortaste durch das Formular der Referenzseite. Springt der Fokus sichtbar von Feld zu Feld? Kannst du den Absenden-Button mit der Tastatur erreichen und auslösen? In React geht das besonders leicht verloren, weil Bedienelemente oft selbst gebaut werden – ein div mit Klick-Handler sieht aus wie ein Button, ist aber keiner. Seit dem Barrierefreiheitsstärkungsgesetz ist das für viele Angebote nicht mehr nur eine Stilfrage.

Prüfpunkt 5: Gibt es Tests – und laufen sie?

„Wir testen natürlich“ heißt in der Praxis alles zwischen „wir klicken vor dem Deployment kurz durch“ und „bei jedem Push läuft eine Suite durch, und rote Tests blockieren die Auslieferung“.

Die Frage, die den Unterschied sichtbar macht: „Zeig mir den letzten grünen CI-Lauf.“ Entweder es gibt einen Link auf eine Pipeline mit Datum und Dauer – oder es gibt Erklärungen.

Eine hohe Testabdeckung ist dabei kein Selbstzweck. Niemand braucht Tests für jeden Button. Gebraucht werden sie an den Stellen, an denen Geld, Rechte oder Daten hängen: Preisberechnung, Rabattlogik, Berechtigungen, Checkout, alles mit Zahlungen. In unseren Projekten ziehen wir die Grenze genau dort, und wir schreiben Tests zuerst für die Fehler, die schon einmal passiert sind. Das ist billiger als jede Abdeckungsquote und verhindert das, was wirklich wehtut: denselben Fehler zum zweiten Mal.

Prüfpunkt 6: Wem gehört das Repository?

Der unspektakulärste Punkt und der, der im Ernstfall über Wochen entscheidet.

Prüfe vor Projektstart, nicht danach:

Das ist kein Misstrauen, sondern Normalität. Agenturen gehen insolvent, Entwickler wechseln den Job, Zusammenarbeit endet – manchmal im Guten, manchmal nicht. Ist das Repository in deiner Hand, ist ein Wechsel ein Wochenendthema. Liegt der Code nur auf dem Produktionsserver und die Domain auf einem Agentur-Account, wird daraus eine Verhandlung.

Sag es im Erstgespräch offen. Die Reaktion darauf ist einer der besten Charaktertests, die es gibt: Eine gute Agentur nickt und legt die Organisation direkt auf deinen Namen an.

Was React-Entwicklung kostet: 79 €/h, Pilot ab 3.900 €

Preise sind bei uns kein Geheimnis. Wir arbeiten zu 79 €/h nach Aufwand, und für einen abgegrenzten ersten Schritt gibt es einen Piloten ab 3.900 € – ein echtes, lauffähiges Stück Anwendung statt eines Konzeptpapiers. Laufende Betreuung inklusive Updates und Monitoring startet ab 119 €/Monat. Alle Pakete stehen offen auf unserer Preisübersicht.

Was ein React-Projekt am Ende teuer oder günstig macht, entscheidet sich nicht am Stundensatz, sondern an den sechs Punkten oben. Ein Projekt mit sauberer Backend-Grenze, wenigen Abhängigkeiten und laufenden Tests kostet im ersten Jahr vielleicht etwas mehr – und im dritten deutlich weniger. Wenn du wissen willst, wie sich der Aufwand bei einer kompletten Anwendung zusammensetzt, findest du die Rechnung in Web-App entwickeln lassen.

Wie diese Website gebaut ist – als Beispiel, nicht als Werbung

Damit die Prüfpunkte nicht abstrakt bleiben: Diese Seite hier läuft auf Next.js 16 mit React 19, und du darfst sie gegen die Liste halten.

• Gerendert wird vorab. Jede Seite – auch dieser Artikel – wird beim Build zu fertigem HTML gebaut. Es gibt keinen Server, der bei deinem Aufruf noch etwas berechnet.
• Animationen kosten hier kein JavaScript. Die Einblendungen sind bewusst reine div-Container ohne Animationsbibliothek. Das war eine ausdrückliche Entscheidung gegen den Effekt und für die Ladezeit des größten sichtbaren Inhalts.
• Abhängigkeiten sind gezählt, nicht gesammelt. 38 direkte Pakete, 704 im gesamten Abhängigkeitsbaum. Ich nenne die zweite Zahl bewusst mit: Auch ein bewusst schlankes Projekt schleppt einen erheblichen Unterbau mit. Wer behauptet, sein React-Projekt käme mit einer Handvoll Pakete aus, hat nie in die Lockfile geschaut.
• Terminierte Veröffentlichung ohne Datenbank. Artikel mit Datum in der Zukunft sind nicht abrufbar; ein täglicher Rebuild schaltet sie frei. Genau deshalb liest du diesen Text heute und nicht früher.

Und die ehrliche Gegenprobe: Für eine reine Firmen-Website wäre React hier nicht nötig gewesen. Der Grund für diese Wahl sind die Teile, die keine Website mehr sind – die Artikel-Pipeline mit eigenen Komponenten, die mehrseitige Plugin-Dokumentation mit Volltextsuche, der Preis-Konfigurator und ein vollständig zweisprachiger Seitenbaum. Ohne diese Anforderungen hätten wir ein CMS genommen und dir dasselbe empfohlen.

Fazit: Prüfen statt vertrauen

Eine React-Agentur auszuwählen ist keine Bauchentscheidung, wenn du die richtigen sechs Fragen stellst: Wird serverseitig gerendert? Wie viel JavaScript lädt ein echter Besucher? Welche Version läuft und wann war das letzte Upgrade? Validiert der Server, nicht nur der Browser? Laufen Tests automatisch? Und gehören dir Repository, Hosting und Domain?

Keine dieser Fragen verlangt, dass du selbst programmieren kannst. Sie verlangen nur, dass jemand auf der anderen Seite sitzt, der sie ohne Ausweichen beantwortet.

Du hast ein React-Projekt in der Planung oder eines, bei dem du das Gefühl hast, es läuft schleifend? Schick uns kurz, worum es geht – wir schauen uns in einem kostenlosen Erstgespräch gemeinsam an, wo dein Frontend steht, und du bekommst eine ehrliche Einschätzung. Auch dann, wenn sie lautet, dass du für dein Vorhaben gar kein React brauchst. Als React- und Next.js-Entwickler sagen wir dir das lieber vorher als nach dem dritten Rechnungsblock. Melde dich einfach – unverbindlich und ohne Verkaufsdruck.

Häufige Fragen