Vad en skräddarsydd app egentligen kostar: en ärlig och transparent uppdelning
Offerter för en skräddarsydd app svänger från några tusen till sexsiffriga belopp, och nästan ingen förklarar varför. Här är kostnadens verkliga anatomi — vad du faktiskt betalar för, vad som blåser upp den och hur du håller den rimlig.

Fråga tre byråer vad en skräddarsydd app kostar och du får tre siffror som inte ens delar en enda siffra. En säger fyra tusen, en säger fyrtio, en säger lågmält att det beror på och bokar ett andra möte. Ingen av dem ljuger, egentligen — men ingen berättar det du faktiskt behöver veta, nämligen vart pengarna går och varför just din app hamnar där den hamnar. Så låt oss öppna huven.
Jag har skrivit fler appofferter än jag kan räkna, för företag som sträcker sig från en enmanshantverkare till en regional kedja. Den absolut vanligaste reaktionen på ett pris är inte chock över totalsumman — det är förvirring över spannet. Hur kan samma brief på tre ord (”en bokningsapp”) ge uppskattningar som skiljer sig med en faktor tio? Det ärliga svaret är att ”en bokningsapp” inte är en brief. Det är en önskan. Priset bor i de hundra små beslut som gömmer sig under den.
Den här texten är den uppdelning jag önskar att varje företagare hade haft inför sitt första samtal med en utvecklare. Ingen utfyllnad, ingen skrämseltaktik, ingen merförsäljning. Bara de verkliga kostnadsposterna, sakerna som lågmält dubblar en budget, och några ärliga sätt att spendera mindre utan att hamna med något du ångrar.
Varför två offerter för ”samma app” skiljer sig med 10x
Mjukvara är inte en produkt du plockar från en hylla — det är arbete, mätt i timmar av skickliga människor. Så priset på en skräddarsydd app är i grunden bara omfattning × timpris × risk. Allt annat är en fotnot till de tre sakerna. När två offerter divergerar kraftigt läses en av dessa tre siffror väldigt olika, och oftast har ingen sagt det högt.
Omfattning är den uppenbara. ”En bokningsapp” kan betyda en enda skärm där kunder väljer en tid — eller det kan betyda personalkalendrar, betalningar, påminnelser, kundinloggning, en admin-panel, återbetalningar och en rapport som ägaren läser på måndagen. Samma tre ord, tio gånger arbetet. Den billiga offerten antar ofta den lilla versionen; den dyra antar lågmält den stora. Ingen frågade vilken du menade.
Sedan finns risken, den del ingen gillar att prissätta. En vag brief, en kund som inte bestämt sig för vad den vill ha, en integration med ett knakande gammalt system — dessa lägger inte bara till timmar, de lägger till osäkerhet. Erfarna team lägger på en buffert för osäkerhet eftersom de bränt sig på den. En billigare offert har ofta inte prissatt risken alls, vilket är just därför den ibland sväller halvvägs in.
“”En bokningsapp” är ingen brief, det är en önskan. Priset bor i de hundra små beslut som gömmer sig under den.”

Vart pengarna faktiskt går
När folk föreställer sig apputveckling föreställer de sig kodning. Kodning är verklig, men den är sällan ens hälften av notan. En skräddarsydd app är närmare att bygga ett litet hus än att skriva ett dokument — det finns design, rördragning, besiktning och pappersarbete runt den synliga delen. Så här delas en typisk budget upp när du räknar in allt.
| Fas | Vad det täcker | Andel av budget |
|---|---|---|
| Förstudie & design | Att reda ut vad som ska byggas; skärmar, flöden, användarupplevelse | 15–25 % |
| Kärnutveckling | Den faktiska koden — frontend, backend, databas | 35–45 % |
| Integrationer | Betalningar, e-post/SMS, kalendrar, befintliga system | 10–20 % |
| Testning & rättningar | Att hitta och döda buggar innan dina kunder gör det | 10–15 % |
| Lansering & uppsättning | Inlämning till appbutik, servrar, drifttagning | 5–10 % |
Två saker brukar överraska folk i den tabellen. För det första hur mycket av budgeten som sker innan en enda rad funktionskod skrivits — förstudie och design är ingen lyx, de är den billigaste platsen att rätta ett misstag. Att ändra en skärm i en skiss kostar minuter; att ändra den efter att den byggts kostar dagar. För det andra hur verklig testraden är. Att hoppa över den sparar inga pengar, den flyttar bara kostnaden till din lanseringsvecka, med ränta.
Förstudie och design: delen alla vill hoppa över
Förstudien är där du förvandlar ”en bokningsapp” till en exakt lista över skärmar och regler. Det känns som omkostnad eftersom inget byggs ännu. Men varje timme här sparar flera längre fram, eftersom det är här tvetydighet dödas medan den fortfarande är billig. Ett team som ger dig ett pris utan förstudiefas antingen gissar, eller planerar att fakturera dig för förstudien senare under ett annat namn.
Kärnutveckling: den synliga motorn
Detta är koden som får din idé att fungera — skärmarna folk trycker på, logiken bakom dem, och databasen som lågmält minns allt. Det är den största enskilda biten, och den skalar nästan direkt med omfattningen. Varje funktion du lägger till är mer att bygga, mer att testa och mer att underhålla för alltid. Detta är raden där ”vore det inte fint om” blir dyrt snabbt.
Integrationer: den bedrägligt dyra biten
Att koppla din app till andra system — ta emot en kortbetalning, skicka en SMS-påminnelse, synka en kalender, hämta data från bokföringsprogrammet du redan använder — ser litet ut på en funktionslista och landar förvånansvärt tungt på fakturan. Varje koppling är ett litet projekt i sig, med sina egna egenheter och felsätt. En väluppfostrad betalningsintegration är okej. Fem tilltrasslade integrationer med ett åldrande internt system är där budgetar går för att dö.
Kostnaderna ingen sätter i offerten
Här får många ägare en otäck överraskning tolv månader in. Bygget är en engångssiffra; en app är inte en engångssak. Mjukvara är levande — telefoner uppdateras, regler ändras, ditt företag växer — och en levande sak behöver matas. Offerten du skriver under är priset för födelsen, inte priset för ägandet.
Inget av detta är en bluff eller en dold fälla — det är bara den del som inte ryms snyggt på en enkelsidig offert, så svagare partners utelämnar den för att se billigare ut. En bra berättar om den i förväg, även om det får deras första siffra att se större ut. Fråga uttryckligen: vad kostar det mig att driva detta i ett år efter lansering? Kvaliteten på svaret säger mycket om vem du har att göra med.

Vad som lågmält dubblar priset
Vissa saker lägger till kostnad i proportion till värdet de ger — rimligt nog. Andra lägger till kostnad helt oproportionerligt, oftast på grund av hur arbetet är strukturerat snarare än vad appen gör. Detta är spakarna värda att förstå, eftersom några av dem är helt inom din kontroll.
- Två plattformar istället för en. En nativ iPhone-app och en nativ Android-app är, grovt sett, två byggen. Plattformsoberoende verktyg eller en webbapp kan dra ihop det mot ett. Detta enda val kan flytta totalen mer än någon funktion.
- Skräddarsydd design framför vettiga standarder. Ett pixelperfekt, helt specialdesignat gränssnitt kostar riktiga pengar att designa och bygga. Ett rent, konventionellt som använder beprövade mönster är snabbare, billigare och ofta lättare för kunder att använda.
- Att ändra dig efter att bygget börjat. Beslut är billiga på en whiteboard och dyra i kod. Den vanligaste budgetöverdraget är inte dålig uppskattning — det är omfattning som fortsatte växa eftersom inget spikades.
- Realtid, offline eller tung data. ”Det ska fungera utan signal” eller ”uppdateringar måste synas direkt för alla” är rimliga önskemål som lågmält mångdubblar ingenjörsarbetet under.
- Att integrera med något gammalt och odokumenterat. Att koppla till ett modernt, välbyggt system är rutin. Att koppla till ett femton år gammalt internt verktyg utan dokumentation är arkeologi, och det faktureras per timme.
Ett verkligt exempel: offerten på 60 000 € som blev en app för 14 000 €
Några detaljer har ändrats för integriteten, men formen på detta är sann och helt typisk. Ett regionalt serviceföretag — tänk ett dussin fältarbetare och ett upptaget kontor — kom till oss frustrerade. De ville ha en skräddarsydd app där deras kunder kunde boka jobb, följa framsteg och betala. De hade redan fått en offert på annat håll på runt 60 000 €, plus en rejäl månadsavgift, och det hade skrämt dem från hela idén under den bättre delen av ett år.
När vi faktiskt kartlade vad de behövde — inte vad de fått offert på — såg bilden mycket annorlunda ut. Den första offerten hade antagit två helt nativa appar, en specialdesign från grunden, ett realtidssystem för utdelning av jobb och en skräddarsydd admin-plattform för att ersätta verktyg de redan ägde och lågmält var nöjda med. Det var, tekniskt, en alldeles utmärkt app. Det var också ett svar på en fråga de inte hade ställt.
Vad vi faktiskt gjorde
Vi ägnade de första sessionerna åt enbart förstudie — att plocka isär önskan i ”verksamheten faller utan detta” mot ”det vore trevligt någon gång”. Måstena var smalare än någon väntat sig: ett rent sätt för kunder att begära och följa ett jobb, automatiska påminnelser och onlinebetalning. Realtidsutdelningen och den skräddarsydda backofficen visade sig vara lösningar på problem som deras befintliga mjukvara redan hanterade bra.
- 1Skar omfattningen till det verkliga jobbetVi släppte funktionerna som löste problem de inte hade, och behöll en stram lista som verksamheten verkligen inte kunde köra utan.
- 2Valde ett plattformsoberoende byggeIstället för två separata nativa appar täckte en enda plattformsoberoende app både iPhone och Android — vilket ungefär halverade kärnutvecklingen.
- 3Använde beprövade designmönsterEtt rent, konventionellt gränssnitt istället för ett specialgjort. Kunderna fann det lättare att använda, och det skalade bort veckor från tidslinjen.
- 4Kopplade, ersatte inteVi länkade appen till kontorsmjukvaran de redan betalade för, istället för att bygga om den. Den dyra ’skräddarsydda admin-plattformen’ försvann helt enkelt ur omfattningen.
Resultatet blev ett bygge på runt 14 000 €, i drift på några månader, med löpande kostnader de kunde förutse. Den är inte lika vidsträckt som 60 000 €-versionen — och den behöver inte vara det. Den gör jobbet verksamheten faktiskt hade. Ett år senare har de lagt till två små funktioner ovanpå, betalda med pengarna den första versionen sparade dem. Det är hela mönstret: börja med det verkliga jobbet, förtjäna extrafunktionerna med resultat.

Hur du håller kostnaden rimlig utan att gena
Att spendera mindre på en skräddarsydd app handlar inte om att pruta ner timpriset eller hitta det billigaste teamet du kan. Så hamnar du med att betala dubbelt. Det handlar om att vara medveten med omfattning, ordningsföljd och beslut — de tre saker som verkligen flyttar siffran. Här bor de verkliga besparingarna.
För det första, bygg den minsta versionen som faktiskt är användbar, och låt den växa sedan. En fokuserad första release som gör ett jobb väl tar dig i drift snabbare, kostar en bråkdel av allt-i-ett-drömmen och — avgörande — lär dig vad du ska bygga härnäst från riktiga kunder istället för gissningar. För det andra, fatta dina beslut innan bygget börjar; obeslutsamhet är det dyraste du kan ta med till ett projekt. För det tredje, koppla till det du redan äger istället för att ersätta fungerande verktyg, och bygg bara om något när det verkligen håller dig tillbaka.
Vill du ha ett rakt svar på vad din app skulle kosta?
Ta med idén till oss, inte en kravspec. Vi kartlägger den med dig, säger ärligt vad som är värt att bygga först, och ger dig en siffra som kommer med skäl — inte ett möte för att diskutera ett möte.
Se hur vi bygger apparVanliga frågor
Vad kostar en skräddarsydd app för ett småföretag?
Varför är en offert så mycket högre än en annan för samma app?
Vilka löpande kostnader bör jag förvänta mig efter lansering?
Är det billigare att bygga en app för både iPhone och Android?
Hur kan jag minska kostnaden utan att hamna med en dålig app?

Have a nice day är en mjukvarustudio som hjälper små och medelstora företag att bli digitala — automatisering, AI och skräddarsydd mjukvara som fungerar i vardagen, inte bara på slides.