Den som söker på vad en app kostar hittar ofta prisintervall som spänner över flera tiopotenser. Det beror inte på att byråer gissar, utan på att ordet ”app” kan betyda allt från ett par skärmar som visar information till en tjänst med inloggning, betalningar, adminverktyg och tusentals användare. I den här guiden sätter vi inga egna siffror – vår prissättning är alltid fast pris efter offert – men vi förklarar vad som gör att en app blir dyr eller billig, så att ni kan styra kostnaden själva.
1. Omfattning: antal flöden, inte antal skärmar
Den enskilt största faktorn är hur mycket appen ska kunna göra. Ett bättre mått än antal skärmar är antal flöden – saker användaren gör från början till slut, som att registrera sig, boka en tid, betala, chatta eller ladda upp en bild. Varje flöde innebär gränssnitt, logik, felhantering och test.
- Användarkonton – registrering, inloggning, glömt lösenord, radera konto (som Apple kräver om man kan skapa konto i appen).
- Roller – har appen olika typer av användare, till exempel kunder och personal, blir det i praktiken flera appar i en.
- Innehåll som ändras – behöver någon kunna redigera innehållet utan att släppa en ny version krävs ett admingränssnitt.
- Realtid – chatt, liveuppdateringar och positionsspårning är mer arbete än vanliga formulär.
- Offline – att appen fungerar utan uppkoppling och synkar sedan är bland det mer krävande att bygga rätt.
Det effektivaste sättet att sänka kostnaden är därför att skära i första versionen. Bygg de flöden som behövs för att någon ska få värde av appen, och vänta med resten tills ni vet hur den används.
2. Plattformar: iOS, Android, webb
Förr innebar en app för både iPhone och Android två separata kodbaser och i stort sett dubbel kostnad. Med ramverk som React Native och Expo, som vi använder, skrivs det mesta en gång och körs på båda plattformarna. Det blir ändå inte exakt samma arbete som för en plattform: testning sker på båda, vissa funktioner beter sig olika och båda butikerna har egna krav vid publicering.
Ska det också finnas en webbversion ökar omfattningen igen, men delar av logiken kan ofta delas. Fundera på om alla plattformar verkligen behövs från dag ett.
3. Backend – den osynliga halvan
Nästan alla appar som gör något mer än att visa statisk information behöver en server: ett API, en databas, inloggning, filer, e-post och push-notiser. Det syns inte i appen men står ofta för en stor del av arbetet.
- Finns det redan ett system? Om appen ska använda data från ett befintligt affärssystem kan backend bli enklare – eller svårare, beroende på hur tillgängligt systemet är.
- Adminpanel – någon behöver ofta se användare, hantera ärenden eller ändra innehåll. Det är en liten webbapp i sig.
- Säkerhet och personuppgifter – behörigheter, loggning och GDPR-hantering tar tid att göra ordentligt.
4. Integrationer: BankID, Swish, betalningar
Integrationer mot externa tjänster drar ofta mer tid än man tror, eftersom de kräver avtal, certifikat, testmiljöer och hantering av alla fall där något går fel.
- BankID – kräver avtal via bank eller förmedlare, ett serveranrop och ett smidigt flöde mellan er app och BankID-appen. Se BankID i app.
- Swish – kräver avtal med banken och certifikat, plus hantering av callbacks och återbetalningar. Se Swish-integration.
- Kort och prenumerationer – med Stripe eller liknande.
- Köp i appen – säljer ni digitalt innehåll inne i appen kan Apples och Googles egna köpsystem krävas, vilket påverkar både utvecklingen och era intäkter.
- Övriga API:er – kartor, betalningslösningar, CRM, affärssystem.
Vi har byggt BankID-inloggning och Swish-utbetalningar i vår egen app FolkPanelen, och skriver mer om det på sidan betalningar och BankID.
5. Design
Design kan vara allt från att använda plattformarnas standardkomponenter med er logotyp och färger, till en helt egen visuell identitet med animationer och illustrationer. Båda kan vara rätt. Standardkomponenter är billigare och känns ofta mer naturliga för användaren; egen design kostar mer men kan behövas för en konsumentapp som ska sticka ut. Klickbara prototyper innan utvecklingen börjar kostar lite men sparar mycket, eftersom ändringar är billigast innan koden är skriven.
6. Löpande kostnader som ofta glöms bort
Utvecklingskostnaden är bara början. Det här tillkommer varje år:
- Apple Developer Program – 99 USD per medlemsår enligt Apple. Utan aktivt medlemskap kan appen inte ligga kvar i App Store.
- Google Play – en engångsavgift på 25 USD för att registrera ett utvecklarkonto, enligt Googles hjälpsidor för Play Console.
- Provision på köp i appen – Apple och Google tar en andel av digitala köp och prenumerationer som går via deras köpsystem. Storleken beror på deras villkor och era intäkter.
- Hosting och drift – servrar, databas, filer, e-postutskick och push-notiser. Kostnaden växer med antalet användare.
- Avgifter för integrationer – BankID, Swish och kortbetalningar kostar per avtal, månad eller transaktion beroende på leverantör.
- Uppdateringar – Apple och Google släpper nya versioner av iOS och Android varje år och höjer kraven på appar i butikerna. Även en app utan nya funktioner behöver underhållas för att fortsätta fungera och få publicera uppdateringar.
- Support och övervakning – någon behöver se när något går fel och svara användare.
Be alltid om en uppskattning av löpande kostnader i samband med offerten. En app som är billig att bygga men dyr att driva är sällan ett bra köp.
Fast pris eller löpande räkning?
Det finns två vanliga sätt att ta betalt för apputveckling.
Fast pris
Ni vet vad det kostar innan arbetet börjar, och leverantören bär risken för att det tar längre tid än beräknat. Det kräver att omfattningen är tydligt beskriven, och att ändringar under projektet hanteras som tillägg. Det är så vi arbetar: fast pris efter offert, med en skriftlig beskrivning av vad som ingår.
Löpande räkning
Ni betalar för nedlagd tid. Det är flexibelt och passar när omfattningen är oklar eller förändras mycket, men risken ligger hos er. Om ni väljer löpande räkning – be om ett kostnadstak, regelbunden rapportering och en uppskattning per funktion.
Ett vanligt mellanläge är att börja med en kortare, avgränsad förstudie eller prototyp till fast pris, och sedan ge fast pris på själva bygget när omfattningen är klarlagd.
Så får ni en bra offert
- Beskriv problemet, inte bara lösningen. Vem ska använda appen, och vad ska de få gjort?
- Lista flödena i första versionen och markera vad som är ett måste och vad som är önskemål.
- Berätta om befintliga system som appen ska prata med.
- Nämn integrationer – BankID, Swish, kortbetalning, SSO, kartor.
- Ange tidsram och budgetspann om ni har det. Det hjälper leverantören att föreslå rätt nivå i stället för att gissa.
- Fråga vad som inte ingår. Design, backend, adminpanel, publicering, butikstexter, drift och support är vanliga gränsdragningar.
- Fråga vem som äger koden och kontona. Appen bör publiceras under ert eget utvecklarkonto och ni bör få tillgång till källkoden.
Jämför offerter på rätt sätt
Två offerter med olika slutsumma beskriver ofta olika saker. Lägg dem bredvid varandra och kontrollera att båda innehåller samma flöden, samma plattformar, backend, adminpanel, design, test och publicering. Fråga också hur buggar efter leverans hanteras, och vad det kostar att lägga till en funktion senare. Den billigaste offerten blir ibland den dyraste när det som saknas ska läggas till.
Vill ni veta mer om hur vi bygger appar, se apputveckling. Funderar ni på om en webbtjänst räcker, läs Vad kostar en hemsida? – samma principer gäller där.