Moderne Frontend und Full Stack Projektideen, die Ihr Portfolio stärken

Welche Projektideen für Webentwickler stärken ein Portfolio wirklich?

Gute Projektideen für Webentwickler sind kleine, fertige Anwendungen, die jeweils eine klare Fähigkeit belegen, als Live Demo erreichbar sind und ihre Entscheidungen in einer README erklären. Sie beginnen mit sauberem HTML, CSS und JavaScript, gehen dann zu APIs und State Management über und enden mit Login, Datenbank und Deployment.

In diesem Beitrag sortiere ich Projektideen für Webentwickler nach Niveau und nenne zu jedem Projekt die Fähigkeit, die es trainiert. Seit 2012 arbeite ich in Webdesign Projekten eng mit Entwicklern zusammen, und ich habe bei Einstellungen auch Portfolios geprüft. Deshalb bevorzuge ich Projekte, über die Sie im Vorstellungsgespräch sprechen können. Eine allgemeine Lernroadmap behandle ich an anderer Stelle. Hier geht es konkret um zwei Fragen: Was bauen Sie, und wie präsentieren Sie es?

Wie sieht eine Projektkarte nach Niveau aus?

Die folgende Tabelle fasst die Projekte zusammen, die ich im weiteren Text erkläre. Die Zeitangaben beruhen auf Praxiserfahrung. Sie sind also ein Startwert und keine Garantie; Ihr Tempo hängt von Ihrer verfügbaren Zeit pro Woche ab.

Sie müssen nicht jede Zeile abarbeiten. Allerdings zeigt ein Projekt pro Niveau eine klare Entwicklung. Zudem liefert es Ihnen eine natürliche Geschichte für das Gespräch: Zuerst habe ich das gelernt, danach dieses Problem gelöst.

Welche Einsteigerprojekte zeigen solide Grundlagen?

Bei Einsteigerprojekten zählt Sauberkeit, nicht Effekt. Wer Ihr Portfolio prüft, schaut auf Ihre Tags, Ihr CSS Layout und die mobile Ansicht. Deshalb schlägt eine kleine, saubere Seite fast immer eine große, unordentliche.

• Persönliche Landingpage. Sie trainiert semantische Tags, ein barrierearmes Menü und eine einfache Typografie.
• Speisekarte eines Restaurants. Sie trainiert CSS Grid für Kategorien und ein Layout nach dem Prinzip Mobile First.
• Kontaktformular mit Validierung. Es trainiert Formularattribute, direkte Fehlermeldungen und korrekte Labels.
• Fotogalerie. Sie trainiert Flexbox, Grid, Seitenverhältnisse und Lazy Loading.

Zum Beispiel können Sie bei der Farbwahl für Ihre Landingpage mit dem HTML Farbcodes Tool schnell Kontraste testen. Außerdem entspricht ein Entwurf in Figma vor dem Coden einem echten Kundenprozess. Diesen Ablauf beschreibe ich in meinem Beitrag über Webdesign mit Figma.

Noch ein Tipp: Verzichten Sie hier auf Frameworks. Eine Seite aus reinem HTML, CSS und JavaScript beweist, dass Sie die Grundlagen wirklich beherrschen.

Was lernen Sie mit kleinen API Projekten?

API Projekte markieren den Schritt von statischen Seiten zu echten Daten. Die wichtigste Lektion lautet: Was passiert, wenn etwas schiefgeht? Ladezustände, leere Ergebnisse und Netzwerkfehler sind also die eigentliche Fähigkeit.

Konkret ein paar Ideen dazu. Ein Währungsrechner holt Kurse von einem offenen Dienst und prüft die Eingaben. Eine Wetter App braucht dagegen eine Standortfreigabe und Einheitenumrechnung. Eine Such App für Filme oder Bücher trainiert verzögerte Suchanfragen (Debounce) und Paginierung.

Legen Sie niemals einen API Schlüssel in den Client Code. Braucht ein Dienst einen Schlüssel, leiten Sie den Aufruf über eine kleine Serverfunktion und speichern den Schlüssel in einer Umgebungsvariable. So zeigen Sie früh einen Sicherheitsreflex. Der MDN Leitfaden Using the Fetch API ist eine verlässliche Referenz für Anfragen und Fehlerbehandlung.

Kurz gesagt entscheidet das Verhalten im schlechten Fall über den Wert eines API Projekts. Beschreiben Sie diese Fälle deshalb in Ihrer README.

Wie wählen Sie fortgeschrittene Frontend Projekte aus?

Auf dieser Stufe sollten Sie sich für ein Framework entscheiden. React, Vue oder Svelte funktionieren gleichermaßen. Die Frage lautet nun nicht mehr, ob die App läuft. Stattdessen zählt, ob sie beim Wachsen stabil bleibt. Wählen Sie daher ein Projekt, das Ihr State Management fordert.

1. Kanban Board. Drag and Drop zwischen Spalten, Sortierung und dauerhafter Zustand. Es zeigt, wie Sie Komponenten aufteilen.
2. Produktliste mit Warenkorb. Kategoriefilter, Preissortierung und Filter in der URL. Es trainiert teilbaren Zustand.
3. Analyse Dashboard. Diagramme mit Testdaten oder offenen Daten, Datumsauswahl und Ladeskelette. Es trainiert die Balance zwischen Darstellung und Tempo.
4. Mehrstufiges Formular. Fortschrittsanzeige, Prüfung pro Schritt und Entwurfsspeicherung. Es trainiert komplexe Formularlogik.

Richten Sie das Projekt an Ihrem Wunschjob aus. Bewerben Sie sich zum Beispiel bei E-Commerce Agenturen, passt der Warenkorb ideal. Firmen, die interne Werkzeuge entwickeln, schätzen dagegen eher das Dashboard.

Egal, wofür Sie sich entscheiden: Halten Sie den Umfang klein. Außerdem sollten Sie ein Projekt vollständig abschließen, bevor Sie das nächste beginnen.

Warum fällt ein Projekt mit Fokus auf Barrierefreiheit auf?

Weil nur wenige Bewerber sie bewusst zeigen. Eine Oberfläche, die sich komplett per Tastatur bedienen lässt und im Screenreader sinnvoll klingt, hebt Sie aus der Masse. Zudem fragen viele Unternehmenskunden inzwischen vertraglich nach Barrierefreiheit.

Ihr Bezugspunkt sind die WCAG Richtlinien des W3C. Kontrast, sichtbarer Fokus, Alternativtexte und Formularlabels sind konkrete, prüfbare Kriterien. Somit können Sie jeden Punkt einzeln testen und in der README auflisten.

Eine praktische Idee: Bauen Sie ein barrierearmes Modal und ein Dropdown Menü. Fokusfalle, Schließen per Escape und ARIA Attribute kommen in diesem kleinen Baustein zusammen. Danach ergänzen Sie ein kurzes Video, in dem Sie die Komponente mit einem Screenreader testen.

Mit diesem Projekt können Sie im Gespräch einen starken Satz sagen: Ich habe die Komponente mit Tastatur und Screenreader getestet. Nach meiner Erfahrung sagen das nur wenige Bewerber.

Wie belegt ein Performance Projekt Ihr Wissen über Core Web Vitals?

Ein Performance Projekt ist eine Vorher und Nachher Studie. Sie nehmen eine langsame Seite und machen sie schnell. Die Core Web Vitals von Google liefern dafür eine gemeinsame Sprache. Laut web.dev gelten als gute Schwellen 2,5 Sekunden für LCP, 200 Millisekunden für INP und 0,1 für CLS.

So können Sie vorgehen. Zunächst bauen Sie eine Demoseite mit riesigen Bildern, blockierenden Schriften und aufgeblähtem JavaScript. Dann messen Sie mit Lighthouse und sichern die Ergebnisse. Danach komprimieren Sie Bilder, ziehen kritisches CSS nach vorn, teilen den Code auf und messen erneut.

Die Messschritte erkläre ich in meinem Beitrag zum Lighthouse Test. Vergessen Sie außerdem die mobile Seite nicht; die Prüfpunkte aus dem Artikel Mobilfreundlichkeit testen gehören ebenfalls in Ihre README.

Die Zahlen selbst sind also weniger wichtig als Ihre Erklärung. Es reicht nicht, dass LCP gesunken ist; beschreiben Sie, welche Änderung warum gewirkt hat.

Welche Fähigkeiten belegen erste Full Stack Projektideen für Webentwickler?

Erste Full Stack Projekte zeigen, dass Sie den Vertrag zwischen Frontend und Backend beherrschen. Sie entwerfen eine API, speichern Daten, liefern verständliche Fehler und betreiben alles unter einer echten Adresse.

• Link Kürzer. Eindeutige Codes, Weiterleitungen, Klickzähler und einfache Statistik. Für lesbare Codes lohnt ein Blick darauf, wie ein Slug Generator Text bereinigt.
• Notiz oder Lesezeichen App. Registrierung, Login, Passwort zurücksetzen und Daten pro Nutzer. Sie trainiert die Grundlagen der Authentifizierung.
• Terminbuchung. Freie Zeiten, Überschneidungsprüfung, Zeitzonen und E-Mail Hinweise. Sie zeigt früh, wie schwierig Datumslogik ist.
• QR Speisekarte. Ein Lokal pflegt seine Karte im Panel, Gäste öffnen sie per QR Code. Ihr Ergebnis können Sie mit einem QR Code Generator vergleichen.

Bei solchen Projekten stelle ich zuerst eine Frage: Komme ich an die Daten eines anderen Nutzers? Ändere ich die ID in der Adresszeile und sehe fremde Notizen, schadet Ihnen das Projekt im Gespräch. Bauen Sie deshalb in jeden Endpunkt eine Prüfung der Eigentümerschaft ein und testen Sie diese.

Warum lohnen sich Echtzeitfunktionen?

Echtzeitprojekte zeigen, dass Sie über das einfache Anfrage und Antwort Modell hinausgehen. Ein Chat, eine Live Umfrage oder ein gemeinsames Whiteboard braucht WebSockets oder Server Sent Events.

Dabei lernen Sie mehrere praktische Dinge: Wiederverbindung nach Abbruch, Reihenfolge der Nachrichten, Onlinestatus und Zähler für Ungelesenes. Außerdem ist ein Test in zwei Browsertabs gleichzeitig der einfachste Weg, Nebenläufigkeitsfehler zu finden.

Eine Live Umfrage ist zum Beispiel klein, aber lehrreich. Der Server sammelt Stimmen, schickt allen sofort das Ergebnis und verhindert doppelte Stimmabgaben. Somit zeigen Sie Echtzeitkommunikation und einen einfachen Missbrauchsschutz in einem Projekt.

Springen Sie trotzdem nicht zu früh auf diese Stufe. Wackelt Ihre einfache CRUD App noch, wird die Fehlersuche in Echtzeit sehr mühsam.

Welche Projektideen für Webentwickler eignen sich auf Profiniveau?

Auf Profiniveau verlassen Sie die Demo für einen einzelnen Nutzer und stellen sich echten Produktfragen. Datentrennung, Hintergrundjobs, Monitoring und Kosten kommen jetzt hinzu.

1. Kleines SaaS für mehrere Mandanten. Jede Firma hat eigene Daten und Rollen. Sie müssen erklären, wie Sie die Mandanten trennen.
2. Anbindung an eine Zahlungs Sandbox. Ein Aboablauf im Testmodus eines Anbieters, Prüfung von Webhooks und ein Szenario mit fehlgeschlagener Zahlung.
3. Such und Filtermaschine. Volltextsuche, Facettenfilter und Paginierung über tausende Einträge. Sie trainiert Datenbankindizes.
4. Warteschlange für Hintergrundjobs. Lange Aufgaben wie Berichte oder Massenmails in eine Queue legen und ihren Status verfolgen.

Hier zählt die Dokumentation Ihrer Architekturentscheidungen genauso viel wie der Code. Interessiert Sie die Aufteilung großer Frontends auf mehrere Teams, bietet mein Beitrag über Micro Frontends eine fortgeschrittene Diskussion. Allerdings sollten Sie dieses Muster nicht in ein Portfolioprojekt zwingen. Zu erklären, warum Sie es nicht nutzen, zeigt ebenfalls Reife.

Wie stärkt ein Projekt für ein echtes Unternehmen Ihr Portfolio?

Vor allem ein Projekt mit echten Nutzern überzeugt mehr als zehn Demos. Denn echte Nutzer bringen unerwartete Eingaben, ehrliches Feedback und echte Fristen mit. Folglich erleben Sie Probleme, die eine Demo nie zeigt.

Sie könnten für ein Café in der Nachbarschaft, einen Verein oder ein kleines Unternehmen eine einfache Website oder ein Buchungstool bauen. Halten Sie den Umfang allerdings schriftlich fest. Legen Sie Termin und Wartungsverantwortung fest. Sonst entwickelt sich ein Gefallen zu endlosem Support.

Denken Sie bei solchen Projekten auch an Suche und Vorschau beim Teilen. Titel und Beschreibungen setzen Sie mit dem Meta Tag Generator, Unternehmensdaten beschreiben Sie mit Schema Markup. So liefern Sie nicht nur Code, sondern echten Nutzen.

Stimmt der Kunde zu, ergänzen Sie ein kurzes Zitat in der README. Haben Sie ein messbares Ergebnis, nennen Sie die Quelle. Fehlt eine solche Zahl, erfinden Sie keine.

Helfen Klonprojekte im Portfolio?

Ja, aber nicht allein. Der Nachbau einer bekannten Oberfläche zeigt, dass Sie Abstände und Layout treffen. Allerdings haben Prüfer denselben Klon schon oft gesehen; er hebt Sie also kaum ab.

Wertvoll wird ein Klon deshalb erst durch Ihre eigene Entscheidung. Haben Sie zum Beispiel eine Musik App nachgebaut, ergänzen Sie eine Offline Playlist oder barrierearme Player Steuerung. Dann sagen Sie nicht, dass Sie kopiert, sondern dass Sie verbessert haben.

Vermeiden Sie zudem Markenlogos und urheberrechtlich geschützte Inhalte. Nutzen Sie eigene Platzhalter und frei lizenzierte Medien. Auch dieses Detail signalisiert professionelle Arbeitsweise.

Kurz gesagt ist ein Klon eine Aufwärmrunde. In die Mitte Ihres Schaufensters gehört das Projekt aus eigener Idee oder mit echten Nutzern.

Warum sind Tests in einem Portfolioprojekt so wichtig?

Zunächst sind Tests Ihr Versprechen, dass der Code auch morgen noch funktioniert. Die meisten Portfolioprojekte enthalten überhaupt keine Tests. Deshalb heben Sie schon wenige sinnvolle Tests hervor.

Testen Sie allerdings nicht alles. Wählen Sie zunächst den Kern Ihrer Logik, etwa die Warenkorbsumme, die Überschneidungsprüfung bei Terminen oder die Rechteprüfung. Dann ergänzen Sie ein oder zwei End to End Tests; ein Nutzer registriert sich zum Beispiel, meldet sich an und sieht nur seine eigenen Notizen.

Richten Sie anschließend eine einfache Continuous Integration ein, die bei jedem Push alle Tests ausführt. Ein grüner Haken auf der Repository Seite ist ein kleines, aber starkes Vertrauenssignal. Nebenbei üben Sie Konfigurationsdateien, Umgebungsvariablen und den Umgang mit geheimen Schlüsseln.

Schreiben Sie schließlich den Testbefehl in die README und erklären Sie in zwei, drei Sätzen, was Sie testen und warum.

Sollten Sie Ihre Portfolioseite selbst als Projekt behandeln?

Ja, denn Ihre Portfolioseite ist das erste Projekt, das Besucher sehen. Eine langsame, fehlerhafte oder unordentliche Seite mindert den Wert der guten Arbeit darin. Geben Sie ihr also dieselbe Sorgfalt wie Ihren übrigen Projekten.

Eine gute Portfolioseite enthält eine kurze Vorstellung und drei oder vier ausgewählte Projekte. Zu jedem Projekt gehören eine kurze Zusammenfassung sowie Links zu Demo und Quellcode. Kontaktdaten und ein Lebenslauf als PDF beschleunigen zudem den Bewerbungsprozess.

Nutzen Sie zum Beispiel auf jeder Projektkarte den Dreiklang Problem, Lösung und Technik. Besucher lesen diese drei Zeilen und entscheiden dann, ob sie klicken. Saubere Titel und Beschreibungen helfen außerdem Menschen, die gezielt nach Ihrem Namen suchen.

Halten Sie das Design daher schlicht. Animationen sollten nie mit Ihren Projekten konkurrieren; ein Schaufenster zeigt das Produkt.

Wie finden Sie Projekte, die Teamarbeit zeigen?

Solo Projekte belegen technisches Können, aber keine Teamfähigkeit. Diese Lücke schließen Sie am besten mit einem Projekt, das Sie gemeinsam mit anderen gebaut haben.

Es gibt mehrere Wege. Erstens können Sie zu einem Open Source Projekt einen kleinen Bugfix oder eine Verbesserung der Dokumentation beitragen; Issues mit dem Label good first issue eignen sich gut. Zweitens bauen Sie mit zwei oder drei Freunden ein Hackathon Projekt. Drittens tun Sie sich mit einer Designerin oder einem Designer zusammen und setzen deren Entwurf in Code um.

Am wichtigsten sind hier Ihre Pull Request Beschreibungen und Review Kommentare. Dort sehen Prüfer nämlich, wie Sie auf Feedback reagieren. Formulieren Sie deshalb klar, höflich und begründet.

Zusammengefasst verwandelt schon ein einziger angenommener Beitrag den Satz, dass Sie teamfähig sind, in einen sichtbaren Beweis.

Wie viele Projekte reichen, und in welcher Reihenfolge?

Konkret empfehle ich drei bis fünf starke Projekte. Vier fertige Projekte wirken immer besser als zehn halbe. Folgende Reihenfolge schlage ich vor:

1. Starten Sie mit einer sauberen, responsiven Seite in reinem HTML, CSS und JavaScript.
2. Ergänzen Sie eine API App, die Fehler und leere Zustände gut behandelt.
3. Bauen Sie ein fortgeschrittenes Framework Projekt, etwa ein Dashboard oder einen Warenkorb.
4. Veröffentlichen Sie eine Full Stack App mit Login, Datenbank und Live Deployment.
5. Optional folgt ein Spezialprojekt zu Barrierefreiheit, Performance oder Echtzeit.

Diese Reihenfolge verhindert, dass Sie sich in endlosen Projektideen für Webentwickler verlieren. Jedes Projekt nutzt außerdem die Fähigkeiten des vorherigen, sodass Sie aufbauen statt wiederholen.

Verwenden Sie zudem eine einheitliche Gestaltung über alle Projekte hinweg. Gleiche Typografie und Farben lassen das Portfolio wie ein einziges Produkt wirken.

Was gehört in eine gute README?

Die README ist die Verkaufsseite Ihres Projekts. Prüfer lesen sie oft, bevor sie eine einzige Datei öffnen, und entscheiden dort. Laut der GitHub Dokumentation zu READMEs erscheint die Datei auf der Startseite des Repositorys. Der erste Eindruck entsteht also genau dort.

• Eine Zeile dazu, was das Projekt tut und für wen.
• Link zur Live Demo und bei Bedarf Zugangsdaten für ein Testkonto.
• Screenshot oder kurze animierte Vorschau.
• Verwendete Technik und der Grund für jede Wahl.
• Installationsschritte mit Klonen, Umgebungsvariablen und Startbefehl.
• Herausforderungen und wie Sie diese gelöst haben.
• Bekannte Lücken und nächste Schritte.

Lassen Sie den Abschnitt zu Herausforderungen nicht weg. Er bereitet Antworten auf Fragen vor, die im Gespräch sicher kommen. Außerdem zeigt er Ihre Denkweise, bevor jemand Ihren Code liest.

Schreiben Sie in der Sprache Ihrer Zielstellen. Für internationale Rollen ist Englisch die sichere Wahl, für den deutschen Markt reicht oft Deutsch.

Wie veröffentlichen Sie eine Live Demo, und worauf achten Sie?

Eine Live Demo beseitigt die Ausrede, dass es auf Ihrem Rechner funktioniert hat. Für statische Projekte genügt kostenloses Hosting wie GitHub Pages. Full Stack Projekte brauchen dagegen eine Plattform für Server und Datenbank.

Achten Sie auf einige Punkte. Erstens schicken kostenlose Tarife Apps manchmal in den Ruhezustand; erwähnen Sie in der README, dass der erste Aufruf dauern kann. Zweitens stellen Sie ein Testkonto bereit, damit Prüfer sich nicht registrieren müssen. Schließlich halten Sie die Demodaten realistisch, aber fiktiv.

Öffnen Sie Ihre Demos außerdem regelmäßig. Ein abgelaufener API Schlüssel oder eine pausierte Datenbank kann Ihr Portfolio über Nacht beschädigen. Eine kaputte Demo hinterlässt einen schlechteren Eindruck als gar keine.

Nutzen Sie dann nach Möglichkeit eine eigene Domain. Eine kurze, einprägsame Adresse wirkt im Lebenslauf und auf LinkedIn professioneller.

Wie machen Sie Ihr GitHub Profil zum Schaufenster?

Ihr GitHub Profil ergänzt Ihre Portfolioseite. Heften Sie Ihre besten Projekte an und archivieren Sie abgebrochene Experimente. So sehen Besucher Ihre stärkste Arbeit auf den ersten Blick.

Auch eine Profil README ist eine gute Chance. Legen Sie ein öffentliches Repository mit Ihrem Benutzernamen an und fügen Sie eine README hinzu, dann zeigt GitHub diesen Text oben auf Ihrem Profil. Eine kurze Vorstellung, Ihre Schwerpunkte und Links zu drei Projekten genügen.

Prüfer lesen außerdem die Commit Historie. Klare Commit Nachrichten und kleine, regelmäßige Änderungen sprechen für Disziplin. Ein einziger riesiger Upload kann dagegen Zweifel an der Herkunft des Codes wecken.

Ergänzen Sie schließlich Topics und Beschreibungen für Ihre Repositorys. Diese Details machen Ihr Profil leichter auffindbar.

Dürfen Sie KI Assistenten beim Programmieren von Portfolioprojekten nutzen?

Ja, solange Sie das Ergebnis verstehen. Viele Teams arbeiten heute mit Werkzeugen, die Code vorschlagen; ein kompletter Verzicht ist also kaum realistisch. Entscheidend ist, ob Sie jede Zeile erklären können.

Im Gespräch wählt ein Prüfer vielleicht eine zufällige Funktion und fragt, warum Sie sie so geschrieben haben. Können Sie das nicht beantworten, kostet Sie das Projekt Vertrauen statt Punkte. Lesen, testen und vereinfachen Sie daher jeden Vorschlag, bevor Sie ihn übernehmen.

Ehrlichkeit hilft zudem auch hier. Ein kurzer Hinweis in der README, an welchen Stellen Sie einen Assistenten genutzt haben, wirkt reif. Zudem macht er aus einer heiklen Frage ein entspanntes Gespräch.

Kurz gesagt beschleunigt das Werkzeug Ihre Arbeit. Entscheidungen, Architektur und Fehlersuche bleiben trotzdem Ihre Verantwortung.

Wie stellen Sie ein Projekt im Vorstellungsgespräch vor?

Die Projektvorstellung gehört zu den stärksten Teilen eines technischen Interviews. Trotzdem machen viele Bewerber daraus eine Liste von Technologien. Folgen Sie stattdessen dem Muster Problem, Entscheidung und Ergebnis.

Zum Beispiel: In meiner Terminbuchung entstanden doppelte Termine. Ich habe eine eindeutige Bedingung in der Datenbank ergänzt und im Client einen Ablauf gebaut, der optimistische Updates zurückrollt. Danach traten keine Doppelungen mehr auf. Diese Geschichte zeigt Fachwissen und Ihre Art, Probleme zu lösen.

Bereiten Sie sich außerdem auf die Folgefrage vor: Was würden Sie heute anders machen? Wer ehrlich und konkret antwortet, wirkt lernbereit. Notieren Sie deshalb für jedes Projekt mindestens einen Punkt, den Sie neu bauen würden.

Öffnen Sie schließlich Ihre Demo direkt vor dem Gespräch. Eine Demo, die beim Bildschirmteilen abstürzt, überschattet selbst eine gut vorbereitete Geschichte.

Welche Fehler sehe ich in Portfolios am häufigsten?

In den Portfolios, die ich prüfe, wiederholen sich dieselben Fehler. Wer sie kennt, wählt aus jeder Liste von Projektideen für Webentwickler klüger aus.

• Keine mobilen Tests, sodass das Layout auf dem Smartphone zerfällt.
• Repositorys ohne README oder mit unveränderter Vorlage.
• API Schlüssel oder Passwörter im Repository.
• In jedem Projekt ein neues Framework, aber nirgends Tiefe.
• Kaputte Demo Links und leere Datenansichten.

Der gemeinsame Kern: Nach dem Fertigstellen fehlt der Blick durch die Augen der Nutzer. Bitten Sie deshalb vor der Veröffentlichung eine Freundin oder einen Freund, das Projekt auf dem Handy zu öffnen, und schauen Sie zu. So sehen Sie in fünf Minuten, was Ihnen wochenlang entgangen ist.

Wenn Sie später Websites für Kunden liefern möchten, ist genau diese Gewohnheit der Job. In meinem Webdesign Service mache ich vor jeder Übergabe dieselben Prüfungen zu Mobilansicht, Barrierefreiheit und Tempo.

Womit sollten Sie heute anfangen?

Beginnen Sie mit Ihrer persönlichen Landingpage, aber bauen Sie sie als schnelles und barrierearmes Beispiel statt als simple Visitenkarte. Danach folgen eine API App, ein Framework Projekt und eine Full Stack App.

Stellen Sie bei jedem Projekt drei Fragen. Welche Fähigkeit belegt es? Erklärt die README das? Läuft die Demo stabil? Lautet jede Antwort ja, spricht Ihr Portfolio durch Qualität und nicht durch Länge.

Kurz gesagt gibt es unendlich viele Projektideen für Webentwickler, aber Ihre Zeit ist begrenzt. Wählen Sie wenige, erklären Sie sie gut, sorgen Sie dafür, dass sie funktionieren, und ergänzen Sie den Rest mit der Zeit.