20 idéer till portfolioprojekt som visar verkliga färdigheter

De bästa idéerna till portfolioprojekt löser ett verkligt problem för en verklig person, visar en eller två färdigheter tydligt och är färdiga: i drift, dokumenterade och förklarbara. Granskare ägnar några minuter åt varje portfolio, så en fungerande app för en riktig användare (ett klubbs bokningssystem, en instrumentpanel med offentlig data, en omdesign med research bakom) slår ännu en klon av en känd produkt. Nedan följer tjugo idéer grupperade efter roll, var och en med vad den visar, första versionen att bygga och det ärliga svåra.

Alla dessa fungerar som en webbapp eller webbplats du kan länka till. När du har tre eller fyra täcker hur du bygger en portfoliowebbplats hur du presenterar dem.

Vad ett starkt portföljprojekt har

Frontendutvecklare

1. Demo av ett tillgängligt formulärbibliotek

• Visar: Semantisk HTML, tangentbordsstöd, felmeddelanden, test med skärmläsare.
• Första versionen: Fem vanliga formulärmönster (registrering, adress, datumintervall, filuppladdning, flerstegsformulär) byggda ordentligt, med en sida som förklarar varje tillgänglighetsval.
• Det svåra: Att testa med en faktisk skärmläsare, inte bara ett automatiskt kontrollverktyg. Hur du gör din webbplats tillgänglig har en checklista.

2. Återskapad verklig sida, sedan förbättrad

• Visar: Layout, responsiv design, uppmärksamhet på detaljer.
• Första versionen: Välj en offentlig sida med ett tydligt problem (en rörig tidtabell, en överbelastad meny), bygg om den och publicera sedan en version som löser problemet, med före och efter.
• Det svåra: Respekt. Använd egen text och egna bilder, märk det som ett koncept och kopiera inte logotyper eller presentera det som företagets arbete.

3. Datatung tabell som fortfarande är snabb

• Visar: Prestanda, sortering, filtrering, paginering, laddningstillstånd.
• Första versionen: En tabell med över 10 000 rader från en offentlig datamängd med sökning, filter och sparade vyer.
• Det svåra: Mätningen. Visa laddningstider före och efter dina ändringar.

4. Offlinevänlig checklistapp

• Visar: Service workers, lokal lagring, synkronisering när du är online igen.
• Första versionen: Checklistor som fungerar utan signal och synkroniseras när anslutningen återkommer. Native kontra progressiva webbappar förklarar alternativen.
• Det svåra: Synkroniseringskonflikter när två enheter redigerar samma lista.

Fullstack- och backendutvecklare

5. Bokningssystem för ett verkligt litet företag

• Visar: Datamodellering, inloggning, mejl, tidszoner, kantfall.
• Första versionen: Tjänster, tillgänglighet, bokningar, bekräftelsemejl och en adminvy. Bokningsbyggaren kan sätta upp grunderna så att du kan fokusera på de svåra reglerna.
• Kan generera intäkter: Om företaget använder det, en liten månadsavgift.
• Det svåra: Dubbelbokningar och avbokningar. Skriv om hur du förhindrade dem.

6. Kundportal för flera användare med roller

• Visar: Autentisering, behörigheter, filuppladdningar, säkerhetstänkande.
• Första versionen: Kunder loggar in och ser bara sina egna filer och meddelanden; personal ser allt. Se hur du bygger en kundportal och portalbyggaren.
• Det svåra: Att bevisa att en kund inte kan se en annan kunds data. Ta med dina tester i beskrivningen.

7. Lagersystem med granskningslogg

• Visar: Relationsdata, historiktabeller, rapporter.
• Första versionen: Artiklar, lagerrörelser, varningar vid lågt saldo och en logg över vem som ändrade vad. Börja från lagerbyggaren.
• Det svåra: Att hålla antalen korrekta när två personer uppdaterar lagret samtidigt.

8. Publikt API med dokumentation

• Visar: API-design, validering, hastighetsbegränsning, dokumentation.
• Första versionen: Ett litet API över en datamängd du bryr dig om, med nycklar, gränser och en dokumentationssida. Hur du bygger ett REST-API beskriver formen.
• Det svåra: Bra felmeddelanden. Det är de användare av ett API märker mest.

9. Pipeline för bakgrundsjobb

• Visar: Köer, återförsök, schemalagt arbete, övervakning.
• Första versionen: En app som importerar en CSV-fil, bearbetar den i bakgrunden och mejlar en rapport när den är klar. Se hur du kör bakgrundsjobb.
• Det svåra: Fel. Visa vad som händer när ett jobb misslyckas halvvägs.

Data och analys

10. Offentlig datainstrumentpanel med en fråga

• Visar: Rensning av data, val av diagram, att berätta en historia.
• Första versionen: En offentlig datamängd, en tydlig fråga ("Vilka bussturer är oftast försenade?"), tre diagram och ett skrivet svar. Instrumentpanelsbyggaren sköter layouten.
• Det svåra: Att säga vad datan inte visar. Notera luckor och förbehåll.

11. Analys av personliga utgifter

• Visar: Kategorisering, tidsserier, medvetenhet om integritet.
• Första versionen: Importera en bankexport (använd exempeldata eller anonymiserad data i den offentliga versionen), kategorisera automatiskt och visa trender.
• Det svåra: Att aldrig publicera riktig finansiell data.

12. Nyckeltalsuppföljning för en liten verksamhet

• Visar: Att översätta affärsbehov till mätetal.
• Första versionen: För en väns butik eller klubb: fem mätetal som de faktiskt frågar efter, uppdaterade från ett kalkylblad. Så kopplar du Google Sheets till din app förklarar kopplingen.
• Det svåra: Att välja mätetal tillsammans med ägaren i stället för åt ägaren.

Designers

13. Omdesign med research

• Visar: Användarresearch, problemformulering, iteration.
• Första versionen: Intervjua tre användare av en lokal tjänsts webbplats eller app, hitta ett problem och designa och testa en lösning. Presentera resultaten, inte bara skärmarna.
• Det svåra: Att få riktiga användare. Tre korta samtal räcker; hur du gör kundintervjuer hjälper.

14. Designsystem för en liten produkt

• Visar: Konsekvens, komponenter, dokumentation.
• Första versionen: Färger, typografi, mellanrum, tio komponenter med tillstånd och en live-sida som visar dem i användning.
• Det svåra: Att visa det i en riktig produkt, inte bara ett provblad.

15. En fungerande prototyp, inte bara mockups

• Visar: Att du förstår hur design beter sig med riktig data.
• Första versionen: Ta ett av dina designprojekt och bygg det som en fungerande webbapp, även en liten. En AI-appbyggare som Mythex kan omvandla din beskrivning till en fungerande app med live-förhandsvisning, vilket låter dig testa med riktig data och riktiga användare.
• Det svåra: Att vara ärlig om vad du själv byggde och vad ett verktyg genererade.

Produkt- och no-code-roller

16. Fallstudie från problem till lansering

• Visar: Upptäckt, prioritering, leverans.
• Första versionen: Hitta ett litet problem i en grupp du är med i, skriv en specifikation på en sida, bygg den enklaste lösningen, lansera den och mät användningen. Hur du skriver ett produktkravdokument med AI har en mall.
• Det svåra: Att mäta något verkligt. Även "12 av 20 medlemmar använde det i vecka ett" är ett resultat.

17. Internt verktyg som ersätter ett kalkylblad

• Visar: Processtänkande, förändringsledning.
• Första versionen: Gör ett rörigt delat kalkylblad på ett jobb, i en klubb eller en välgörenhetsorganisation till en enkel app. Se hur du gör om ett kalkylblad till en app.
• Det svåra: Att få människor att byta. Skriv om vad du gjorde för att få dem att göra det.

18. Återkopplingsportal med en publik roadmap

• Visar: Att samla in och prioritera användarnas input.
• Första versionen: Användare skickar in och röstar på idéer; du markerar dem som planerade, pågående eller klara. Se hur du bygger en portal för kundåterkoppling.
• Det svåra: Att säga nej offentligt.

AI-fokuserade projekt

19. AI-verktyg för ett smalt jobb

• Visar: Promptdesign, kostnadsmedvetenhet, hantering av dålig output.
• Första versionen: En uppgift gjord väl, till exempel att göra om ett recept till en inköpslista, med sparade resultat och ett sätt att rätta fel. Hur du använder LLM-API:er förklarar nycklar och kostnader.
• Det svåra: Att visa hur du utvärderade det: tio testindata och hur många det fick rätt.

20. Sökning i egna dokument

• Visar: Hämtning, uppdelning i delar, källhänvisningar.
• Första versionen: Ladda upp en uppsättning offentliga dokument (en klubbs regler, ett spels manual) och besvara frågor med länkar till källpassagen. Vad är RAG förklarar metoden.
• Det svåra: Att erkänna när svaret inte finns i dokumenten.

Så avslutar och presenterar du ett projekt

1. Välj en verklig användare innan du börjar. En vän, en klubb, en tidigare arbetsgivare, dig själv.
2. Lansera en liten version på två veckor, förbättra sedan utifrån vad användaren säger.
3. Lägg koden i Git. Även om du började i ett AI-byggverktyg, exportera den; hur du använder Git med en AI-byggd app visar hur. (På Mythex ingår kodexport och GitHub i Pro-abonnemanget.)
4. Läs och förstå koden. Om en AI skrev delar av den hjälper hur du granskar AI-genererad kod dig att komma dit att du kan förklara den i en intervju.
5. Skriv ner det. Problem, användare, vad du byggde, viktiga beslut, vad som gick sönder, vad som kommer härnäst. En sida.
6. Håll det live. En trasig demolänk är värre än ingen alls. Kontrollera dina länkar före varje ansökan.

För fler idéer som inte riktar sig till arbetsgivare, se idéer till sidoprojekt du kan bygga med AI eller idéer till webbappar.

Frågor