Så väljer du rätt byrå för apputveckling – en guide för beställare

1. När behöver du anlita en apputvecklingsbyrå?

En apputvecklingsbyrå är rätt val när du behöver bygga en mobil- eller webbapplikation men saknar antingen tid, tekniska resurser eller specialistkompetens internt. Typiska situationer där en byrå är rätt val:

• Du är en startup som behöver bygga en MVP (Minimum Viable Product) snabbt och inte har råd att rekrytera ett helt utvecklingsteam.
• Du är ett etablerat företag som behöver komplettera ditt interna team med specialistkompetens (t.ex. iOS, Android, AI/ML eller UI/UX-design).
• Du behöver bygga en app utanför ert kärnverksamhetsområde och vill undvika att bygga upp ett permanent team.
• Du har ett tidskritiskt projekt med fast deadline där du behöver få full bemanning på dag ett.

Det är däremot inte rätt val om du har en långsiktig produkt som ska utvecklas och förvaltas i många år, och har resurser att bygga ett internt team. På sikt blir intern utveckling nästan alltid billigare per timme, men det tar 6–12 månader att rekrytera och få igång ett fungerande team.

2. Byrå eller konsulter – vad passar dig?

Det här är det första vägvalet, och det avgör mycket av din budget och risk. Har du ingen techorganisation på plats är det ofta bäst att ta in en byrå som sköter hela leveransen åt dig.

Här kan du läsa våra förklaringar på projektleverans vs teamförstärkning med enstaka konsulter.

3. De åtta viktigaste kriterierna när du väljer byrå

Det här är de kriterier som avgör om projektet blir framgångsrikt.

3.1 Relevanta referensprojekt

Be att få se appar som byrån faktiskt har byggt, helst inom en bransch eller komplexitetsklass som liknar din. En byrå som byggt 30 enkla appar är inte nödvändigtvis rätt för en banktjänst med BankID-integration. Be specifikt om:

• Tre referenser, gärna med kontaktuppgifter du får ringa.
• Case stories, demos eller bilder från liknande projekt.
• Information om vilken roll byrån hade (helhet eller delleverans?).

3.2 Teknisk kompetens

En modern app består av betydligt mer än frontendkod. En kompetent byrå ska kunna leverera på alla dessa områden eller tydligt deklarera var de behöver underleverantörer:

• Frontend (iOS/Android native, React Native, Flutter eller webb).
• Backend (typiskt Node.js, Python, Go eller .NET).
• Databas och datamodellering.
• DevOps, CI/CD och molninfrastruktur (AWS, GCP, Azure).
• Säkerhet, GDPR och datakryptering.
• QA och testautomatisering.

3.3 Domänexpertis

Alla appbyråer kan utveckla appar. Det som skiljer dem åt är förståelsen för specifika industrier.

En byrå som tidigare byggt flertalet fintech-appar vet redan hur de bygger ett KYC-kompatibelt flöde, hur de integrerar mot dina system och var du kan automatisera manuellt arbete utan att öka risken. En generalistbyrå utan domänkunskap behöver lära sig det, på din bekostnad. Räkna med extra timmar i inlärningstid som du betalar för, plus risken att branschspecifika krav upptäcks sent och kräver omarbete.

Domänexpertis blir särskilt viktigt när din bransch är reglerad, integrationstung eller har starka etablerade UX-konventioner. För enklare appar utan särskilda branschkrav räcker generell teknisk kompetens.

“Domänexpertis är oerhört viktigt när du väljer appbyrå. Att jobba med någon som förstår förutsättningarna för din bransch gör att du får en produkt som fungerar optimalt med dina system och regleringar, och därmed skapar värde för dina kunder och din affär.”
– Jakob Råhlén, medgrundare och teknisk rådgivare på qte

3.4 Tydlig och transparent prismodell

En seriös byrå kan förklara hur de prissätter, vad som ingår och vad som tillkommer. Var skeptisk mot fasta priser på odefinierade scope. Antingen är priset uppblåst för att täcka risk, eller så kommer ändringsbeställningar att äta upp besparingen. De vanligaste prismodellerna:

• Tid och material (T&M): Du betalar för faktiskt nedlagd tid. Mest flexibelt, kräver löpande styrning.
• Fast pris per leverans: Bra för väl avgränsade scope, men svårt att ändra sig på vägen.
• Dedikerat team: Du hyr in ett team månadsvis. Bra för längre samarbeten.
• Sprint-baserat: Pris per sprint (typiskt 2 veckor) med tydligt scope per sprint.

3.5 Process för UX och produktdesign

Den vanligaste anledningen att appar misslyckas är inte tekniska problem, utan att man byggt fel sak – något som kunderna faktiskt inte efterfrågat. Fråga byrån hur de jobbar med:

• Användarintervjuer och behovsanalys innan appen börjar utvecklas.
• Wireframes och prototyper för validering.
• Designsystem och komponentbibliotek.
• Användartester under utvecklingen.

“Oavsett hur tekniskt perfekt en app är kan den misslyckas om den inte löser ett verkligt problem eller faktiskt gör livet enklare för användaren. Därför blir appar ofta kortlivade om de inte utgår från användarnas behov (psst, användare uttrycker oftast problem, inte faktiska behov).”
– Therese Banström, design manager på qte

3.6 Kommunikation och projektledning

Kräv en namngiven projektledare som är din primära kontakt. Säkerställ att ni har:

• Veckovisa avstämningar med agenda och anteckningar.
• En gemensam ärendehanterare (Jira, Linear eller liknande) som du har tillgång till.
• En tydlig process för om något går snett.

3.7 Ägarskap av kod och immateriella rättigheter

Säkerställ skriftligt att:

• Du äger all källkod som produceras, utan begränsningar.
• Du får tillgång till repon (GitHub, GitLab).
• Eventuella tredjepartskomponenter (open source eller licensierade) listas tydligt med sina licensvillkor.
• Designfiler (Figma, Sketch) tillhör dig.

3.8 Långsiktig förvaltningsmodell

Frågan ”vad händer efter lansering?” ska besvaras innan ni skriver kontrakt. En app utan löpande underhåll blir säkerhetsmässigt och tekniskt föråldrad inom 12–18 månader. Klargör:

• SLA (service level agreement) och responstider för buggfixar.
• Hur ofta byrån uppdaterar för nya iOS- och Android-versioner.
• Pris per timme för vidareutveckling efter lansering.
• Om du fritt kan byta byrå för förvaltningen.

4. Vad kostar det att utveckla en app i Sverige 2026?

Det finns inget exakt svar på hur mycket en app kostar. Det beror helt på funktionalitet, plattformar och designambition. Vi brukar säga att en app sällan kostar under 1 miljon kronor, men det beror på många faktorer som:

• Antal plattformar (både iOS och Android?).
• Designambition (en helt skräddarsydd design tar 30–50% längre tid än en som håller sig till bestämda, återanvändbara komponenter).
• Antal externa integrationer (varje API-koppling tar vanligtvis 40–120 timmar inklusive testning).
• Säkerhets- och regulatoriska krav (GDPR, AML eller DORA ökar projektets komplexitet markant).
• Realtidsfunktioner (chat, livenotifikationer, GPS-tracking) som kräver särskild backend-arkitektur.

Viktigt att veta: Räkna med att den löpande förvaltningen efter lansering typiskt kostar 15–25% av den ursprungliga utvecklingsbudgeten per år. En app som kostat 2 miljoner att bygga kommer alltså behöva 300 000–500 000 kr/år i underhåll och vidareutveckling för att fortsätta fungera optimalt.

Att stå inför valet att gå på en billgare vs en dyrare byrå är svårt. Här gäller det att förstå komplexiteten på det du vill bygga. En billigare byrå kan säkerligen leverera en app till dig, men du betalar för teknisk förståelse och för att få en grund som du kan bygga vidare på framöver.

Vi på qte klassar oss t.ex. som en något dyrare byrå. Det är för att vi arbetar med relativt komplexa applikationer. När vi bygger appar för banker blir det genast ett omfattande arbete, med höga krav på säkerhet och regulatorisk efterlevnad. De som väljer en byrå i vår prisklass gör det för att de uppskattar expertisen inom den specifika branschen eller ramverket.

Ska du bygga en enklare app bör du välja en byrå som matchar den kompetensen. Du ska inte betala för onödigt seniora utvecklare när det inte behövs.

5. Frågor du bör ställa innan du skriver under

Skicka gärna dessa frågor i förväg som en del av offertförfrågan. En bra byrå svarar tydligt och skriftligt:

• Hur sätter ni er in i vår affär och våra användare?
• Har ni erfarenhet från vår bransch?
• Kan ni visa liknande projekt som ni gjort?
• Hur prissätter ni?
• Vad händer om jag vill ändra scopet under tiden?
• Vem kommer vara min kontaktperson?
• Hur ofta får vi uppdateringar?
• Hur involverade förväntas vi vara?
• Hur hanterar ni det om en nyckelperson slutar mitt i projektet?
• Vad är er garanti om vi hittar buggar efter lansering?

6. Vad händer efter lansering?

Lansering känns ofta som målet, men i praktiken är det snarare startskottet. Efter lansering går din app in i en vidareutvecklingsfas, där man utvärderar resultatet med riktig användardata och optimerar appen utifrån det. Utöver optimering och att lägga till nya features behöver du veta vem som ska ansvara för:

• Buggfixar och säkerhetsuppdateringar. Kritiska säkerhetshål ska kunna fixas inom 24–48 timmar.
• Anpassningar till nya OS-versioner. Apple och Google släpper större uppdateringar varje höst som ofta kräver justeringar.
• Infrastruktur och driftskostnader. Servrar, databaser, externa tjänster (analytics, betalningar).
• App Store-relationer. Recensioner, ASO (App Store Optimization), uppdateringsgodkännanden.

Många beställare gör misstaget att förhandla hårt om utvecklingspriset men inte definiera förvaltningen. Resultatet kan bli att den ursprungliga byrån har monopol på underhållet och prissätta det hur de vill. Se till att diskutera förvaltningsvillkor innan du skriver på kontraktet.