Från idé till lanserad app: så bygger du din första portfölj som utvecklare
Senast uppdaterad: July 11, 2026 Lästid: 5 min
En rekryterare i Stockholm lägger i snitt några få sekunder på varje kandidat innan hon bestämmer sig för att läsa vidare eller stänga fliken. Det är där din portfölj som utvecklare avgör spelet — inte antalet kurser du gått, utan de projekt du faktiskt kan visa upp och prata om.
Om du är på väg in i tech utan flera års erfarenhet är portföljen ditt starkaste kort. Ett CV berättar vad du säger att du kan. En portfölj bevisar det. Här går vi igenom hur du bygger en som håller för granskning från en teknisk intervjuare i Göteborg lika väl som från en icke-teknisk HR-person.
varför portföljen väger tyngre än betyg för juniora roller
Många som söker sitt första jobb som frontend-utvecklare eller data scientist stirrar sig blinda på certifikat. Certifikat är fina, men de säger sällan något om hur du löser problem. En arbetsgivare vill se att du kan ta en oklar idé och göra den körbar.
Tänk dig att du söker en junior utvecklarroll på ett fintech-bolag i Malmö. Två kandidater har samma utbildning. Den ena har ett GitHub-konto med tre färdiga projekt, tydliga README-filer och en app som faktiskt går att öppna i webbläsaren. Den andra har bara ett CV. Valet är enkelt, och det handlar inte om talang — det handlar om bevis.
vad ett starkt projekt faktiskt innehåller
Ett bra portföljprojekt löser ett riktigt, litet problem. Det behöver inte vara nästa Spotify. Det behöver vara något du kan förklara på två minuter och som visar att du behärskar hela kedjan från kod till körbar produkt.
Ett konkret exempel: en app som håller koll på vilka böcker du lånat på biblioteket och påminner dig innan de ska lämnas tillbaka. Det finns en databas (lånen), logik (uträkning av återlämningsdatum), ett gränssnitt (listan du ser) och en notis (påminnelsen). En rekryterare förstår direkt vad appen gör, och du kan berätta om varje val du gjort på vägen.
Vad som brukar imponera i praktiken:
- Projektet är driftsatt någonstans, till exempel på Vercel eller Netlify, så att det går att klicka sig in utan att klona koden.
- Det finns en README som förklarar vad appen gör, hur du kör den lokalt och vilka tekniska val du gjort.
- Koden är läsbar, med begripliga variabelnamn och commits som berättar en historia snarare än "fix" tjugo gånger.
kvalitet slår kvantitet — men hur många projekt behövs?
En vanlig fråga från blivande utvecklare i Sverige är hur många projekt portföljen bör innehålla. Svaret är färre än du tror, men bättre gjorda än du hoppas.
Tre genomarbetade projekt slår tolv halvfärdiga varje dag i veckan. Rekryteraren orkar ändå inte titta på alla. Välj bredd som visar olika förmågor: ett projekt som visar att du kan bygga ett gränssnitt, ett som visar att du kan jobba mot ett API, och ett som visar att du kan hantera data.
| Aspekt | Ett stort, färdigt projekt | Många små, halvfärdiga projekt |
|---|---|---|
| Signalerar till rekryterare | Uthållighet och djup | Osäkerhet och avbrutna försök |
| Berättar en historia i intervjun | Ja, tydligt | Svårt att välja vad du ska prata om |
| Tid att underhålla | Lägre per projekt | Hög, sprids tunt |
| Risk för buggar vid granskning | Lägre om du polerat det | Högre, ofta obruten kod |
strukturera din GitHub så att den går att läsa
Din GitHub-profil är ofta det första en teknisk intervjuare öppnar. Fäst dina bästa repositorier överst så att de syns direkt. Ett tomt eller rörigt konto sänker intrycket snabbare än en saknad rad i CV:t.
Skriv commit-meddelanden som en människa kan följa. "Lade till validering av e-postfält" säger något. "asdf" säger att du inte tänkte på att någon skulle läsa det. Och ta bort döda projekt — den där halvfärdiga to-do-appen från första veckan gör ingen nytta bland dina utvalda arbeten.
Om du fortfarande lär dig grunderna och vill ha en tydlig väg genom projekt och teori kan ett strukturerat program hjälpa. Titta på hur en webbutvecklingskurs hos Code Labs Academy är upplagd, eller jämför upplägget i Code Labs Academys hela kursutbud för att hitta det spår som matchar din målroll.
så beskriver du projekten så att icke-tekniker fattar
Du kommer att intervjuas av både utvecklare och personer utan teknisk bakgrund. Skriv därför varje projektbeskrivning i två lager. Först en mening om vad appen löser i klartext. Sedan en kort teknisk not om hur.
Exempel: "En app som hjälper föreningar att boka lokaler utan dubbelbokning. Byggd i React med en Node-backend och PostgreSQL, driftsatt på Railway." Den första meningen förstår vem som helst. Den andra ger den tekniska granskaren något att haka på.
Undvik att lista tjugo teknologier bara för att du klickat på dem en gång. Skriv det du faktiskt kan förklara. Om någon frågar "varför valde du PostgreSQL och inte MongoDB?" ska du ha ett svar, även ett enkelt.
vanliga misstag som sänker portföljen
Det första är att bara visa handledda projekt. Om alla dina appar är exakt den övning som tusen andra elever byggt märks det. Ta samma grund och lägg till en egen funktion, ändra temat, koppla på ett annat API — visa att du kan gå utanför instruktionen.
Det andra är trasiga länkar. En rekryterare som klickar på din live-demo och möter en felsida drar en slutsats direkt. Testa alla länkar dagen innan du skickar din ansökan.
Det tredje är att förklara för mycket eller för lite. En README på tio ord hjälper ingen. En README på tre skärmar orkar ingen läsa. Sikta på att en främling ska förstå och kunna köra projektet på under fem minuter.
en enkel plan för de närmaste veckorna
Börja litet. Välj ett problem du själv har — något i din vardag som en liten app kan lösa. Bygg det klart, driftsätt det, skriv en README och be någon utan koll på kod att öppna länken och berätta vad de tror att appen gör. Deras svar avslöjar om ditt projekt kommunicerar det du tänkt.
När det första projektet sitter, upprepa med ett som tänjer på en ny förmåga. Vill du gå mot data i stället för webb finns liknande logik i ett datadrivet spår — kolla vad Code Labs Academys prisalternativ och betalupplägg omfattar innan du bestämmer dig för hur du vill studera.
En portfölj är aldrig helt klar, och det är själva poängen: den växer med dig. Bygg tre projekt du är stolt över, driftsätt dem, och se till att varje länk fungerar innan du trycker på skicka. Vill du ha en tydlig struktur att bygga den kring, utforska Code Labs Academys kurser och hitta rätt spår för din målroll.