Guide

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.

Have a nice dayHave a nice day13 min läsning
Vad en skräddarsydd app egentligen kostar: en ärlig och transparent uppdelning

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.
vad jag säger till varje ägare på första samtalet
En isbergsillustration där en liten synlig appskärm flyter ovanför vattenytan och en stor massa av dolda komponenter — databas, betalningar, inloggning, admin-panel, testning — ligger under, tecknad i en ren redaktionell platt stil
Skärmen kunden ser är toppen. Det mesta av kostnaden bor under vattenytan.

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.

FasVad det täckerAndel av budget
Förstudie & designAtt reda ut vad som ska byggas; skärmar, flöden, användarupplevelse15–25 %
KärnutvecklingDen faktiska koden — frontend, backend, databas35–45 %
IntegrationerBetalningar, e-post/SMS, kalendrar, befintliga system10–20 %
Testning & rättningarAtt hitta och döda buggar innan dina kunder gör det10–15 %
Lansering & uppsättningInlämning till appbutik, servrar, drifttagning5–10 %
En grov uppdelning av vart en app-budget tenderar att gå. Verkliga projekt varierar, men formen håller.

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.

Ett kalenderrutnät där första dagen visar ett enda stort mynt märkt ’bygge’ och de följande månaderna var och en visar mindre återkommande mynt märkta hosting, underhåll och support, illustrerat i en varm platt stil
Bygget är en betalning. Ägandet är en liten, jämn trumvirvel efter det.

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.

  1. 1
    Skar omfattningen till det verkliga jobbet
    Vi släppte funktionerna som löste problem de inte hade, och behöll en stram lista som verksamheten verkligen inte kunde köra utan.
  2. 2
    Valde ett plattformsoberoende bygge
    Istället för två separata nativa appar täckte en enda plattformsoberoende app både iPhone och Android — vilket ungefär halverade kärnutvecklingen.
  3. 3
    Använde beprövade designmönster
    Ett 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.
  4. 4
    Kopplade, ersatte inte
    Vi 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.

En sida-vid-sida-jämförelse: till vänster ett uppblåst appkoncept täckt av många funktionsetiketter med en stor prislapp, till höger en slimmad fokuserad app med tre kärnfunktioner och en liten prislapp, tecknad i en ren platt redaktionell stil
Samma företag, samma mål. Skillnaden i pris var nästan helt omfattning — inte kvalitet.

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 appar

Vanliga frågor

Vad kostar en skräddarsydd app för ett småföretag?
Det finns ingen ärlig enskild siffra, eftersom det helt beror på omfattningen — men en fokuserad första version av en verkligt användbar affärsapp landar vanligen i de lägre till mellersta femsiffriga beloppen, inte de sexsiffriga som allt-i-ett-plattformarna antyder. De avgörande faktorerna är hur många funktioner du verkligen behöver dag ett, om du bygger för en plattform eller två, och hur mycket du kopplar till kontra bygger om. Börja smått så håller sig siffran rimlig.
Varför är en offert så mycket högre än en annan för samma app?
Nästan alltid för att de lågmält offererar olika omfattningar. Den billigare kan anta en slimmad enplattformsapp; den dyra kan anta två nativa appar, skräddarsydd design och system du egentligen inte behöver. Innan du jämför priser, låt varje offert beskriva exakt vad den inkluderar — då ser du att de aldrig egentligen prissatte samma sak.
Vilka löpande kostnader bör jag förvänta mig efter lansering?
En app är inte ett engångsköp. Räkna med hosting och servrar, regelbundet underhåll för att hålla den fungerande när telefoner och operativsystem ändras, utvecklaravgifter för appbutiken, support, och de ändringar du oundvikligen kommer att vilja ha när riktiga kunder använder den. En rimlig tumregel är 15–20 % av byggkostnaden per år. En bra partner berättar detta i förväg.
Är det billigare att bygga en app för både iPhone och Android?
Oftast, ja. Två separata nativa appar är grovt sett två byggen. En enda plattformsoberoende app — eller i vissa fall en webbapp — kan täcka båda från en kodbas, vilket ofta flyttar totalen mer än något enskilt funktionsbeslut. Nativt förtjänar bara sin extrakostnad när du verkligen behöver djup, plattformsspecifik prestanda eller hårdvarufunktioner.
Hur kan jag minska kostnaden utan att hamna med en dålig app?
Jaga inte ett billigare team — det kostar oftast mer i slutändan. Skär istället omfattning, inte kvalitet: bygg den minsta versionen som faktiskt är användbar, fatta dina beslut innan utvecklingen börjar, använd beprövade designmönster istället för specialgjorda, och koppla till verktyg du redan äger istället för att bygga om dem. Lägg sedan till funktioner senare, finansierade av resultat.
Have a nice day
Have a nice day
Redaktionen

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.

Relevanta tjänster