Portfolio Projects for Full Stack Developer

Du hast ein Zertifikat in React, eines in Node und trotzdem keine Einladung zum Gespräch. Das ist normal. Recruiter und Tech-Leads blättern bei Full-Stack-Bewerbungen zuerst zum Portfolio, und dort entscheidet sich in zwei Minuten, ob du weiterkommst.

Zertifikate belegen, dass du einen Kurs abgeschlossen hast. Projekte zeigen, dass du Probleme lösen, Code strukturieren und Entscheidungen begründen kannst. Genau das wird bezahlt.

Was Reviewer in einem Portfolio wirklich ansehen#

Niemand liest deinen Code Zeile für Zeile. Der Reviewer scannt drei Dinge: Ob das Projekt ein echtes Problem löst, ob der Code eine nachvollziehbare Struktur hat, und ob du technische Entscheidungen erklären kannst.

Die meisten scheitern am dritten Punkt. Sie zeigen eine fertige App und sagen: "Ich habe React und PostgreSQL verwendet." Das ist eine Einkaufsliste, keine Begründung.

Gute Reviewer klicken zuerst ins Repository, nicht auf die Live-Demo. Sie schauen auf die README, die Commit-Historie, die Behandlung von Fehlern und die Tests. Eine halb fertige App mit sauberer Dokumentation schlägt eine glänzende Demo ohne README.

Projekt 1: Buchungs-Tool mit Rollen und Berechtigungen#

Baue eine Terminbuchung für einen Friseursalon oder eine Physiotheraxie-Praxis. Kunden buchen Slots, Mitarbeiter verwalten ihren Kalender, ein Admin pflegt die Öffnungszeiten. Das klingt unspektakulär, und genau deshalb funktioniert es.

Der Grund: Fast jede Firma hat irgendeine Form von Buchung, Freigabe oder Rollentrennung. Du zeigst damit ein Problem, das echte Teams täglich lösen.

Baue ein, was die meisten Tutorials weglassen: Zeitzone des Users, Doppelbuchung verhindern, abgesagte Slots wieder freigeben, Audit-Log für Preisänderungen. Das sind die Stellen, an denen Reviewer sehen, dass du an Produktionsfall denkst.

Technik-Stack: React oder Vue, Node mit Express oder NestJS, PostgreSQL, dazu eine Auth-Lösung wie Keycloak oder ein selbst gebauter JWT-Flow. Deploye es irgendwo öffentlich erreichbar, Render oder Fly.io reichen.

Projekt 2: Daten-Pipeline mit sichtbarem Ergebnis#

Nimm öffentliche Daten, etwa Wetterdaten oder ÖPNV-Verbindungen, und mach etwas Brauchbares daraus. Eine kleine API, ein Dashboard, ein Export als CSV. Wichtig ist der Weg, nicht die Oberfläche.

Zeige einen echten ETL-Ablauf: Abruf mit Rate-Limit-Behandlung, Validierung der Rohdaten, Transformation, Speicherung, Umgang mit fehlenden Werten. Dokumentiere, was passiert, wenn die Quelle ausfällt oder das Schema sich ändert.

Dieses Projekt wirkt auf Backend-orientierte Reviewer stärker als ein weiteres To-do-Dashboard. Es zeigt außerdem, dass du mit unordentlichen Daten umgehen kannst. Genau das passiert in echten Jobs jeden Tag.

Projekt 3: Dein eigenes Werkzeug bauen#

Baue ein kleines Tool, das du selbst benutzt. Ein CLI-Tool, das deine Zeiterfassung ausliest. Ein Slack-Bot, der Standup-Fragen stellt. Ein Skript, das deine Bewerbungen trackt und eine Übersicht zeigt.

Der Vorteil: Du kannst im Interview ehrlich erzählen, warum du was gebaut hast. Das wirkt authentisch, weil es das ist. Reviewer merken sofort, ob ein Projekt nur für das Portfolio entstanden ist.

Halte es klein. Ein Wochenende reicht. Aber mach es öffentlich, dokumentiere die Installation und schreibe in die README, welche Funktionen du bewusst weggelassen hast.

Wie du Projekte im Lebenslauf zeigst#

Viele schreiben: "Portfolio-Projekt: E-Commerce-App mit React und Node." Das liest sich wie eine Zeile aus einem Kurskatalog. Besser ist ein Satz mit Problem, Lösung und Ergebnis.

Schlecht: "Full-Stack-Projekt: Buchungs-App mit React, Node.js, PostgreSQL."

Besser: "Entwickelte eine Buchungs-App für 3 Nutzerrollen mit Konflikterkennung bei Doppelbuchungen, deployed auf Render, Code auf GitHub mit README und 18 Unit-Tests."

Der zweite Satz zeigt Umfang, ein konkretes technisches Problem und liefert Belege, die man nachprüfen kann. Wenn du Hilfe beim Formulieren brauchst, hilft dir unser kostenloser Lebenslauf-Prüfer weiter.

Für die Bewerbung selbst lohnt ein Blick auf aktuelle Full-Stack-Stellen in unserem Stellenmarkt. Dort siehst du, welche Technologien in den Ausschreibungen wirklich verlangt werden, und kannst deine Projekte daran ausrichten.

So baust du das GitHub-Repository auf#

Die README ist die wichtigste Datei im Repo. Sie entscheidet, ob jemand länger als 30 Sekunden bleibt.

• Ein Satz oben, was das Projekt macht und für wen
• Screenshot oder kurzes GIF direkt unter der Beschreibung
• Abschnitt "Lokal starten" mit exakten Befehlen, Schritt für Schritt
• Auflistung der bewussten Designentscheidungen und Alternativen
• Abschnitt "Was ich gelernt habe" mit zwei, drei konkreten Punkten
• Hinweis auf bekannte Limitationen, ehrlich benannt
• Lizenz und Kontakt

Commit-Nachrichten sollten lesbar sein. "fix" und "update" sagen nichts. Schreib stattdessen "verhindere Doppelbuchung durch DB-Constraint". Reviewer schauen da rein.

Fehler, die Projekte nach Tutorial aussehen lassen#

Der häufigste Fehler: Das Projekt ist eine 1:1-Umsetzung eines YouTube-Tutorials, inklusive identischer Ordnerstruktur und identischer Farben. Reviewer erkennen das sofort. Übernimm die Idee, ändere aber Domain, Datenmodell und Oberfläche.

Der zweite Fehler: Keine Fehlerbehandlung. Was passiert bei einem 500er von der API? Was sieht der User, wenn das Passwort falsch ist? Fehlt das komplett, wirkt das Projekt wie eine Demo für den Sonntag.

Der dritte Fehler: Zu viele Technologien. Ein Projekt mit React, Next.js, GraphQL, Kubernetes, Redis und drei Cloud-Anbietern wirkt nicht beeindruckend, sondern unklar. Lieber zwei Projekte mit klarem Fokus als fünf mit Technik-Sammlung.

Vierter Fehler: Keine Tests, aber ein Abschnitt "Testing" in der README, der nur "kann hinzugefügt werden" sagt. Entweder du hast Tests, oder du schreibst ehrlich dazu, warum nicht.

Wie du im Interview über deine Projekte sprichst#

Erwarte die Frage: "Erzähl mir von einem Projekt, auf das du stolz bist." Bereite eine Antwort von 90 Sekunden vor. Struktur: Problem, dein Ansatz, eine schwierige technische Entscheidung, Ergebnis.

Konkretes Beispiel für Projekt 1:

"Ein Kunde sollte Termine buchen können, ohne dass zwei Personen denselben Slot bekommen. Ich habe erst versucht, das in der Anwendung zu lösen, aber bei gleichzeitigen Requests gab es trotzdem Doppelbuchungen. Also habe ich einen Unique-Constraint auf das Zeitfenster gelegt und die Fehlerbehandlung in den Frontend-Flow gezogen, damit der Nutzer sofort eine Alternative sieht. Seitdem haben wir keine Doppelbuchungen mehr, und ich habe gelernt, dass Race Conditions nicht im UI gelöst werden."

Diese Antwort zeigt ein echtes Problem, eine Fehlentscheidung und eine Korrektur. Genau das suchen Interviewer.

Halte für jedes Projekt eine zweite Antwort bereit: Was würdest du heute anders machen? Diese Frage kommt fast immer. Wer keine Antwort hat, hat das Projekt nicht verstanden.

Reihenfolge und Aufwand#

Wenn du wenig Zeit hast, baue Projekt 1 und Projekt 3. Projekt 1 zeigt Breite, Projekt 3 zeigt Eigeninitiative. Projekt 2 ist die Kirsche obendrauf für Rollen mit Backend-Fokus.

Rechne pro Projekt mit zwei bis vier Wochenenden, wenn du nebenberuflich arbeitest. Mehr braucht es nicht. Ein fertiges, sauber dokumentiertes Projekt schlägt drei angefangene.

Prüfe vor der Bewerbung, ob deine Projekte überhaupt die Anforderungen treffen. Ein Blick auf die Ausschreibung mit unserem kostenfreien Job-Decoder zeigt dir, welche Begriffe dort wirklich vorkommen, und du kannst deine Projektbeschreibungen entsprechend anpassen.

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie viele Portfolio-Projekte brauche ich für Full-Stack-Stellen?

Zwei bis drei reichen völlig, wenn sie sauber dokumentiert und öffentlich erreichbar sind. Fünf halbfertige Projekte wirken schwächer als zwei durchdachte mit README, Tests und Deployment.

Soll ich meine Projekte auch auf einer eigenen Website zeigen?

Eine einfache Seite hilft, ist aber nicht nötig. Wichtiger ist ein GitHub-Profil mit übersichtlicher Profil-README und angehefteten Repositories. Wenn du eine Seite baust, halte sie schlank und verlinke direkt auf die Repos.

Was mache ich, wenn mein Projekt auf kostenlosem Hosting läuft und oft schläft?

Das ist in Ordnung, schreib es in die README. Ein Satz wie "Die Demo läuft auf einem kostenlosen Plan und kann beim ersten Aufruf 30 Sekunden brauchen" wirkt professioneller als eine tote URL.

Darf ich Code aus Tutorials in mein Portfolio übernehmen?

Nur, wenn du ihn umbaust und klar kennzeichnest, woher die Grundidee kommt. Übernimm niemals ein komplettes Projekt unter deinem Namen. Reviewer googeln charakteristische Dateinamen und finden die Vorlage.

Wie aktuell muss mein Tech-Stack in den Projekten sein?

Er muss nicht das Neueste sein, aber er sollte dem entsprechen, was in Stellenanzeigen steht. Ein Blick auf aktuelle Full-Stack-Ausschreibungen in unseren Jobangeboten zeigt dir, ob dein Stack noch gefragt ist.#