20 idéer til portfolio-projekter, der viser reelle færdigheder

De bedste idéer til portfolio-projekter løser et reelt problem for en rigtig person, viser en eller to færdigheder tydeligt og er færdige: live, dokumenteret og forklarbare. Bedømmere bruger få minutter pr. portfolio, så en fungerende app til en rigtig bruger (en klubs bookingsystem, et dashboard med offentlige data, et redesign med research bag) slår endnu en kopi af et kendt produkt. Nedenfor er tyve idéer grupperet efter rolle, hver med hvad den viser, den første version at bygge og det ærlige svære.

Alle disse fungerer som en web-app eller side, du kan linke til. Når du har tre eller fire, dækker sådan bygger du en portfolio-hjemmeside, hvordan du præsenterer dem.

Hvad et stærkt portfolio-projekt har

Kvalitet	Hvorfor det betyder noget	Sådan viser du det
En reel bruger	Viser, at du forstår et problem	Navngiv, hvem det er til; citer deres feedback
Én tydelig færdighed	Let for en bedømmer at vurdere	Start beskrivelsen med den
Færdigt	De fleste projekter bliver aldrig færdige	Et live-link, der virker på telefon
Forklarede valg	Viser dømmekraft, ikke bare output	En kort ”hvorfor jeg valgte X frem for Y”
Ærlig om værktøjer	Skaber tillid	Sig, hvad du brugte, inklusive AI

Front-end-udviklere

1. Demo af et tilgængeligt formularbibliotek

Viser: Semantisk HTML, tastaturunderstøttelse, fejlbeskeder, test med skærmlæser.
Første version: Fem almindelige formularmønstre (tilmelding, adresse, datointerval, filupload, flertrins) bygget ordentligt, med en side, der forklarer hver tilgængelighedsbeslutning.
Det svære: At teste med en faktisk skærmlæser, ikke kun med et automatisk værktøj. Sådan gør du din hjemmeside tilgængelig har en tjekliste.

2. Genskabt virkelighedsside, derefter forbedret

Viser: Layout, responsivt design, opmærksomhed på detaljer.
Første version: Vælg en offentlig side med et tydeligt problem (et forvirrende skema, en rodet menu), genopbyg den, og udgiv derefter en version, der løser problemet, med før og efter.
Det svære: Respekt. Brug din egen tekst og billeder, mærk det som et koncept, og kopier ikke logoer eller præsentér det som virksomhedens arbejde.

3. Datatung tabel, der stadig er hurtig

Viser: Ydeevne, sortering, filtrering, paginering, indlæsningstilstande.
Første version: En tabel med over 10.000 rækker fra et offentligt datasæt med søgning, filtre og gemte visninger.
Det svære: At måle. Vis indlæsningstider før og efter dine ændringer.

4. Offline-venlig tjekliste-app

Viser: Service workers, lokal lagring, synkronisering når man er online igen.
Første version: Tjeklister, der virker uden signal og synkroniserer, når forbindelsen kommer tilbage. Native apps vs progressive web apps forklarer mulighederne.
Det svære: Synkroniseringskonflikter, når to enheder redigerer den samme liste.

Full-stack- og back-end-udviklere

5. Bookingsystem til en rigtig lille virksomhed

Viser: Datamodellering, login, mails, tidszoner, kantetilfælde.
Første version: Ydelser, tilgængelighed, bookinger, bekræftelsesmails og en administratorvisning. Bookingbyggeren kan opsætte det grundlæggende, så du kan fokusere på de svære regler.
Kan tjene: Hvis virksomheden bruger det, et lille månedligt gebyr.
Det svære: Dobbeltbookinger og annulleringer. Skriv om, hvordan du forhindrede dem.

6. Klientportal med flere brugere og roller

Viser: Autentificering, tilladelser, filuploads, sikkerhedstænkning.
Første version: Klienter logger ind og ser kun deres egne filer og beskeder; medarbejdere ser alt. Se sådan bygger du en klientportal og portal-byggeren.
Det svære: At bevise, at én klient ikke kan se en andens data. Tag dine tests med i beskrivelsen.

7. Lagerstyring med en revisionslog

Viser: Relationelle data, historiktabeller, rapporter.
Første version: Varer, lagerbevægelser, advarsler ved lavt lager og en log over, hvem der ændrede hvad. Start fra lagerbyggeren.
Det svære: At holde tællingerne korrekte, når to personer opdaterer lageret samtidig.

8. Offentlig API med dokumentation

Viser: API-design, validering, rate limiting, dokumentation.
Første version: En lille API over et datasæt, du holder af, med nøgler, grænser og en dokumentationsside. Sådan bygger du en REST API beskriver formen.
Det svære: Gode fejlbeskeder. Det er dem, brugere af en API bemærker mest.

9. Baggrundsjob-pipeline

Viser: Køer, genforsøg, planlagt arbejde, overvågning.
Første version: En app, der importerer en CSV-fil, behandler den i baggrunden og sender en rapport på mail, når den er færdig. Se sådan kører du baggrundsjob.
Det svære: Fejl. Vis, hvad der sker, når et job fejler halvvejs.

Data og analyse

10. Dashboard med offentlige data og ét spørgsmål

Viser: Oprydning af data, valg af diagrammer, at fortælle en historie.
Første version: Ét offentligt datasæt, ét tydeligt spørgsmål (”Hvilke busruter er oftest forsinkede?”), tre diagrammer og et skriftligt svar. Dashboard-byggeren klarer layoutet.
Det svære: At sige, hvad dataene ikke viser. Notér huller og forbehold.

11. Analyse af personligt forbrug

Viser: Kategorisering, tidsserier, bevidsthed om privatliv.
Første version: Importér en bankeksport (brug eksempel- eller anonymiserede data i den offentlige version), kategorisér automatisk og vis tendenser.
Det svære: Aldrig at offentliggøre rigtige økonomiske data.

12. KPI-oversigt for en lille virksomhed

Viser: At omsætte forretningsbehov til nøgletal.
Første version: Til en vens butik eller klub: fem nøgletal, de faktisk spørger om, opdateret fra et regneark. Sådan forbinder du Google Sheets til din app dækker forbindelsen.
Det svære: At vælge nøgletal sammen med ejeren, ikke for ejeren.

Designere

13. Redesign med research

Viser: Brugerresearch, problemformulering, iteration.
Første version: Interview tre brugere af en lokal virksomheds side eller app, find ét problem, og design og test en løsning. Præsentér resultater, ikke bare skærme.
Det svære: At få rigtige brugere. Tre korte samtaler er nok; sådan laver du kundeinterviews hjælper.

14. Designsystem til et lille produkt

Viser: Konsistens, komponenter, dokumentation.
Første version: Farver, typografi, afstande, ti komponenter med tilstande og en live-side, der viser dem i brug.
Det svære: At vise det i et rigtigt produkt, ikke bare som et prøveark.

15. En fungerende prototype, ikke bare mockups

Viser: At du forstår, hvordan design opfører sig med rigtige data.
Første version: Tag et af dine designprojekter og byg det som en fungerende webapp, selv en lille en. Et AI-byggeværktøj som Mythex kan omdanne din beskrivelse til en fungerende app med en live-forhåndsvisning, så du kan teste med rigtige data og rigtige brugere.
Det svære: At være ærlig om, hvad du selv byggede, og hvad et værktøj genererede.

Produkt- og no-code-roller

16. Case study fra problem til lancering

Viser: Opdagelse, prioritering, levering.
Første version: Find et lille problem i en gruppe, du er en del af, skriv en specifikation på én side, byg den simpleste løsning, lancér den og mål brugen. Sådan skriver du et produktkravdokument med AI har en skabelon.
Det svære: At måle noget reelt. Selv ”12 af 20 medlemmer brugte det i uge ét” er et resultat.

17. Internt værktøj, der erstatter et regneark

Viser: Procesforståelse, forandringsledelse.
Første version: Gør et rodet, delt regneark på et job, i en klub eller i en forening til en simpel app. Se sådan gør du et regneark til en app.
Det svære: At få folk til at skifte. Skriv om, hvad du gjorde for at få dem til det.

18. Feedback-portal med en offentlig køreplan

Viser: Indsamling og prioritering af brugerinput.
Første version: Brugere indsender og stemmer på idéer; du markerer dem som planlagt, i gang eller færdige. Se sådan bygger du en kunde-feedbackportal.
Det svære: At sige nej offentligt.

AI-fokuserede projekter

19. AI-værktøj til ét snævert job

Viser: Prompt-design, omkostningsbevidsthed, håndtering af dårligt output.
Første version: Én opgave gjort godt, for eksempel at omdanne en opskrift til en indkøbsliste, med gemte resultater og en måde at rette fejl på. Sådan bruger du LLM API'er dækker nøgler og omkostninger.
Det svære: At vise, hvordan du evaluerede det: ti testinput og hvor mange det fik rigtigt.

20. Søgning i dine egne dokumenter

Viser: Hentning, opdeling i bidder, citering af kilder.
Første version: Upload et sæt offentlige dokumenter (en klubs regler, et spils manual) og besvar spørgsmål med links til kildeafsnittet. Hvad er RAG forklarer tilgangen.
Det svære: At indrømme, når svaret ikke står i dokumenterne.

Sådan afslutter og præsenterer du et projekt

Vælg en reel bruger, før du starter. En ven, en klub, en tidligere arbejdsgiver, dig selv.
Lever en lille version på to uger, og forbedr den derefter ud fra det, brugeren siger.
Læg koden i Git. Selv hvis du startede i et AI-byggeværktøj, så eksportér den; sådan bruger du Git med en AI-bygget app viser hvordan. (På Mythex er kodeeksport og GitHub på Pro-planen.)
Læs og forstå koden. Hvis en AI skrev dele af den, hjælper sådan gennemgår du AI-genereret kode, så du kan forklare den i et interview.
Skriv det op. Problem, bruger, hvad du byggede, centrale valg, hvad gik i stykker, hvad er det næste. Én side.
Hold det live. Et ødelagt demo-link er værre end intet. Tjek dine links, før hver ansøgning.

For flere idéer, der ikke er rettet mod arbejdsgivere, se sideprojektidéer, du kan bygge med AI eller webapp-idéer.

Spørgsmål

Hvor mange projekter bør der være i en portfolio?

Tre til fem stærke, færdige projekter er typisk bedre end ti tutorials. Hvert projekt bør vise en anden færdighed, have et live-link eller tydelige skærmbilleder og en kort beskrivelse, der forklarer problemet, dine valg og hvad du ville gøre næste gang.

Er tutorial-projekter i orden i en portfolio?

Som træning, ja; som det vigtigste i din portfolio, ikke rigtig, fordi bedømmere ser de samme to-do-apps og vejr-apps igen og igen. Tag et tutorial-projekt og ændr det for en rigtig bruger eller et rigtigt datasæt, og skriv om, hvad du ændrede, og hvorfor.

Kan jeg bruge AI-værktøjer til at bygge portfolio-projekter?

Ja, og mange arbejdsgivere forventer nu, at du gør det, men vær åben om det, og sørg for, at du forstår hver del, du viser. Vær klar til at forklare koden, datamodellen og afvejningerne i et jobinterview. Et projekt, du ikke kan forklare, skader mere, end det hjælper.

Hvad bør en beskrivelse af et portfolio-projekt indeholde?

Hvem det er til, problemet, hvad du byggede, de vigtigste valg og afvejninger, hvad der gik galt, og hvordan du løste det, og hvad du ville gøre næste gang. Tilføj et live-link, en kort video eller skærmbilleder og et link til koden, hvis den er offentlig.