Ein Fullstack Developer remote baut Datenbank, Backend, Oberfläche und Deployment einer Web-App, ohne mit dem Auftraggeber im selben Büro zu sitzen. Ob das gut geht, entscheidet selten der Tech Stack. Es entscheiden drei Größen: wie viele Arbeitsstunden sich beide Seiten zeitlich überschneiden, wie schnell Rückfragen beantwortet werden und wem Repository und Hosting gehören. Alle drei lassen sich vor Projektbeginn messen – und die meisten gescheiterten Remote-Projekte hätten diesen Test nicht bestanden.
Was remote im Fullstack-Alltag tatsächlich anders läuft
Fullstack heißt: Eine Person verantwortet alle Schichten einer Anwendung – Datenbankschema, serverseitige Logik, Oberfläche und Auslieferung. Remote ändert daran fachlich nichts. Es ändert, wie Zwischenstände sichtbar werden. Im Büro schaut man auf einen Bildschirm; remote muss jeder Stand über eine Adresse erreichbar sein.
Die Kette vom Schema bis zum Deployment
| Schicht | Typisches Werkzeug (z. B. in meinen Projekten) | Was remote zusätzlich nötig ist |
|---|---|---|
| Datenbank | PostgreSQL, Supabase | Migrationen versioniert im Repository, nicht per Klick im Dashboard |
| Backend / API | Next.js Route Handler, Edge-freie Server-Funktionen | Schnittstellen schriftlich beschrieben, damit Rückfragen nicht im Call hängen |
| Frontend | React, Next.js, TypeScript | Preview-Deployments: eine eigene, temporäre URL pro Änderung, die der Auftraggeber selbst öffnet |
| Auslieferung | CI/CD-Pipeline, Hosting-Konto | Deploy nur aus dem Hauptzweig, Protokoll für den Auftraggeber einsehbar |
Der unterschätzte Punkt ist die dritte Zeile. Ohne Preview-URL wird jede Abstimmung zum Bildschirmteilen – und Bildschirmteilen braucht gemeinsame Stunden, die remote knapp sind.
Was sich nicht auslagern lässt
Fachentscheidungen, realistische Testdaten und die Abnahme bleiben beim Auftraggeber. Remote funktioniert, wenn auf Kundenseite genau eine Person benannt ist, die Rückfragen verbindlich beantworten darf. Drei Beteiligte mit halber Entscheidungsbefugnis sind schlechter als eine mit voller.
Zeitzonen entscheiden mehr als der Stundensatz
„Remote“ in einer Stellenanzeige oder einem Angebot sagt nichts darüber, wann die andere Seite arbeitet. Die folgende Rechnung nimmt an, dass beide Seiten jeweils 9 bis 17 Uhr Ortszeit arbeiten, gemessen gegen Hannover (MEZ, Winterzeit – also die Lage im November und Dezember).
| Standort der Entwicklerin / des Entwicklers | Versatz zu MEZ (Winter) | Arbeitszeit in MEZ | Gemeinsame Stunden |
|---|---|---|---|
| DACH | 0 h | 9–17 Uhr | 8 |
| Lissabon | −1 h | 10–18 Uhr | 7 |
| Bukarest | +1 h | 8–16 Uhr | 7 |
| Bengaluru | +4,5 h | 4:30–12:30 Uhr | 3,5 |
| New York | −6 h | 15–23 Uhr | 2 |
| San Francisco | −9 h | 18–2 Uhr | 0 |
Die Drei-Stunden-Regel
Unter drei gemeinsamen Stunden pro Tag sollte ein Projekt vollständig asynchron geplant werden: schriftliche Tickets, Preview-URLs, aufgezeichnete Demos statt Live-Termine. Das klappt, kostet aber Schreibarbeit auf beiden Seiten. Wer das nicht leisten will, bleibt besser bei Teams mit mindestens sieben überlappenden Stunden – also innerhalb Europas.
Zwischen Lissabon und Bukarest liegt kaum ein Unterschied. Zwischen Bukarest und New York liegt ein Unterschied von fünf gemeinsamen Stunden pro Tag, über zwölf Wochen sind das 300 Stunden, in denen eine Rückfrage sofort beantwortet werden könnte.
Rechenbeispiel: Was langsame Rückfragen ein 12-Wochen-Projekt kosten
Ein Modell, keine Messung – aber mit Zahlen, die sich auf das eigene Projekt übertragen lassen.
Annahmen
- Umfang: 240 Entwicklungsstunden, verteilt auf 12 Wochen (20 h pro Woche).
- Rückfragen: 3 pro Woche, also 36 im Projekt.
- Davon blockieren 25 % den Fortschritt am betroffenen Strang: 9 Fragen.
- Die Hälfte der Wartezeit lässt sich mit anderen Aufgaben überbrücken, die andere Hälfte geht verloren.
- Fester Abstimmungsaufwand: ein wöchentlicher Termin à 45 Minuten plus 20 Minuten schriftliches Protokoll.
Ergebnis
| Antwortverhalten des Auftraggebers | Wartezeit je blockierender Frage | Verlorene Arbeitstage (9 × Wartezeit × 0,5) | Verzug auf 12 Wochen |
|---|---|---|---|
| A: Antwort innerhalb von 4 Stunden | 0,25 Tage | 1,1 | ca. 2 % |
| B: Antwort nach durchschnittlich 1,5 Tagen | 1,5 Tage | 6,75 | ca. 11 % |
| C: Antwort nur im Wochentermin (Ø 2,5 Tage) | 2,5 Tage | 11,25 | ca. 19 % |
Der feste Abstimmungsaufwand liegt bei 12 × 65 Minuten = 13 Stunden, rund 5,4 % der Entwicklungszeit. Das ist der sichtbare Remote-Aufschlag. Der unsichtbare steht in Zeile C: Wer Fragen nur einmal pro Woche beantwortet, verliert mehr als zwei Wochen – ohne dass eine einzige Zeile Code langsamer geschrieben wurde.
Der Satz, den ich jedem Auftraggeber vorab sage: Die Antwortzeit auf Rückfragen bestimmt die Projektdauer stärker als die Zeitzone. Bei sieben gemeinsamen Stunden und Antwortverhalten C ist ein Remote-Projekt langsamer als eines mit zwei gemeinsamen Stunden und Antwortverhalten A.
Woran Remote-Projekte früh kippen
Vier Fehler sehe ich wiederholt, jeweils mit einem Frühzeichen, das sich in den ersten zwei Wochen zeigt:
- Repository und Hosting liegen beim Entwickler. Frühzeichen: Der Auftraggeber bekommt eine Einladung ins Repository, statt selbst Eigentümer zu sein. Bei Projektende wird daraus eine Übergabe mit offenem Ausgang. Richtig herum: Konten auf den Auftraggeber anlegen, Entwickler einladen.
- Keine entscheidende Person benannt. Frühzeichen: Rückfragen gehen an einen Verteiler und bleiben 48 Stunden ohne Antwort. Damit landet das Projekt in Zeile C des Rechenbeispiels.
- Erste klickbare Version zu spät. Frühzeichen: Bis Woche 3 gibt es keine Preview-URL. Dann wird das Ergebnis erst gesehen, wenn Änderungen teuer sind.
- Anforderungen nur mündlich. Frühzeichen: Nach dem Kick-off existiert kein Dokument, das beide Seiten freigegeben haben. Remote fehlt der Flurfunk, der solche Lücken im Büro nebenbei schließt.
Wie stark sich der Aufwand zusätzlich nach Kundentyp verschiebt – etwa durch längere Freigabewege in Praxen – rechnet der Vergleich Fullstack-Entwickler für Mittelstand, Praxen und SaaS mit 102, 136 und 180 Stunden für denselben Funktionskern durch.
Stelle oder Projekt: zwei Märkte unter demselben Suchbegriff
Wer nach „Fullstack Developer remote“ sucht, landet überwiegend auf Jobbörsen. Das ist ein anderer Markt als die projektweise Vergabe, und die Unterscheidung spart beiden Seiten Zeit.
Für Entwicklerinnen und Entwickler auf Stellensuche
Der deutsche Markt für vollständig remote ausgeschriebene Fullstack-Stellen ist überschaubar: zuhausejobs.com listet für Oktober 2026 rund 30 verifizierte 100-%-Remote-Stellen in Deutschland, mit Stacks von PHP/Laravel über Vue.js/Node.js bis Java/TypeScript und Next.js. Das ist eine Stichprobe eines Portals, keine Marktzahl.
Genau hinsehen lohnt sich bei der Einschränkung „remote“: Ein Listing auf itjobswatch.co.uk beschreibt eine Golang-Stelle als „Fully remote (UK based)“ mit 40.000 bis 60.000 £. Remote bedeutet in solchen Anzeigen: von zu Hause innerhalb eines Landes, nicht von überall. Vor der Bewerbung klären, welches Land und welche Kernarbeitszeit gemeint sind.
Für Unternehmen, die jemanden suchen
Die Entscheidungsregel, die ich vorschlage: Fallen nach dem Launch dauerhaft mehr als rund 20 Stunden Weiterentwicklung pro Woche an, ist eine Anstellung zu prüfen. Ist der Umfang abgrenzbar und endet mit einer dokumentierten Übergabe, passt ein Projekt zum Festpreis mit einem Freelancer besser. Dazwischen liegt ein Wartungsvertrag mit festem Stundenkontingent.
10-Punkte-Check vor dem Start
Jeder erfüllte Punkt zählt einen Punkt.
| # | Prüfpunkt | Erfüllt? |
|---|---|---|
| 1 | Mindestens drei gemeinsame Arbeitsstunden pro Tag – oder ein bewusst asynchroner Plan | ☐ |
| 2 | Eine Person auf Kundenseite mit Entscheidungsbefugnis, namentlich benannt | ☐ |
| 3 | Zugesagte Antwortzeit auf Rückfragen: höchstens ein Arbeitstag | ☐ |
| 4 | Repository im Konto des Auftraggebers | ☐ |
| 5 | Hosting- und Datenbank-Konten im Konto des Auftraggebers | ☐ |
| 6 | Schriftliche Anforderungen, von beiden Seiten freigegeben | ☐ |
| 7 | Preview-URL pro Änderung vereinbart, erste klickbare Version bis Woche 3 | ☐ |
| 8 | Fester Wochentermin plus schriftliches Protokoll | ☐ |
| 9 | Zugangsdaten über einen Passwortmanager geteilt, nicht per Mail | ☐ |
| 10 | Mit dem Datenschutzverantwortlichen geklärt, ob ein Auftragsverarbeitungsvertrag nötig ist | ☐ |
8 bis 10 Punkte: starten. 5 bis 7: die offenen Punkte vor Vertragsbeginn schließen, das dauert meist nur Tage. Unter 5: erst die Anforderungen und Zuständigkeiten klären, sonst bezahlt man Wartezeit.
Start im Januar: was im November und Dezember erledigt sein sollte
Wer ein Remote-Projekt zum Jahresbeginn plant, entscheidet die Projektdauer zum großen Teil in den Wochen davor. Drei Dinge lassen sich jetzt erledigen, ohne dass eine Entwicklungsstunde anfällt:
- Konten anlegen. Repository, Hosting und Datenbank auf das Unternehmen registrieren, solange die IT noch nicht im Jahresendstress steckt.
- Vertretung festlegen. Zwischen den Jahren ist die entscheidende Person oft nicht erreichbar. Nach dem Rechenbeispiel ist das Zeile C – also keine blockierenden Arbeitspakete in diese Wochen legen, sondern Dokumentation oder Tests.
- Anforderungen schriftlich freigeben. Ein Erstgespräch im November, ein freigegebenes Dokument im Dezember, Entwicklungsstart in der ersten Januarwoche: So beginnt das Projekt in Zeile A statt mit drei Wochen Klärung.
Häufige Fragen
Was macht ein Fullstack Developer remote anders als im Büro?
Die fachliche Arbeit ist dieselbe: Datenbank, Backend, Frontend und Deployment. Anders ist die Sichtbarkeit von Zwischenständen. Remote braucht jede Änderung eine eigene Preview-URL und jede Abstimmung ein schriftliches Protokoll, weil der Blick auf denselben Bildschirm fehlt.
Wie viele gemeinsame Arbeitsstunden braucht eine Remote-Zusammenarbeit?
Ab drei gemeinsamen Stunden pro Tag lassen sich Termine und schnelle Rückfragen gut unterbringen. Darunter sollte das Projekt bewusst asynchron organisiert werden. Innerhalb Europas liegen die Überschneidungen bei sieben bis acht Stunden, zur US-Ostküste bei zwei.
Festanstellung remote oder Freelancer auf Projektbasis?
Das hängt am Umfang nach dem Launch. Bei dauerhaft mehr als rund 20 Stunden Weiterentwicklung pro Woche ist eine Anstellung zu prüfen. Für ein abgegrenztes Projekt mit dokumentierter Übergabe passt ein Festpreis mit einem Freelancer, für die Zeit danach ein Wartungskontingent.