Hvad koster det at lave en app?

Kort svar

At lave en velbygget native iOS-app koster typisk mellem 200.000 og 1.000.000 kroner. En fokuseret første version ligger i den lave ende, mens en funktionsrig app med en kompleks backend ligger meget højere. Prisen styres mest af, hvor mange funktioner du lancerer med, designet og backenden, ikke af hvor teamet sidder. Start fokuseret, og budgettér for vedligeholdelse, ikke kun selve bygget. Det giver også det pålidelige budget, en startup i København har brug for, før den forpligter sig.

Hvorfor prisen varierer så meget

Det første at forstå er, at en app ikke er én ting med én pris. Når nogen spørger, hvad en app koster, afhænger det ærlige svar af et modspørgsmål: hvad skal appen egentlig gøre? To personer kan begge sige, at de vil have en markedsplads-app, og mene meget forskellige produkter, ét med fem skærme og ét med halvtreds, ét der genbruger færdige dele og ét der kræver skræddersyet logik i kernen.

Derfor er ethvert realistisk spænd bredt. Prisen for at lave en app bestemmes næsten helt af omfanget, dybden i designet og kompleksiteten i backenden, og kun marginalt af geografien. Et team i København har en anden timepris end et værksted i udlandet, men antallet af timer, styret af hvad du vælger at bygge, flytter totalen langt mere end timeprisen. Definér omfanget godt, så følger prisen fornuftigt efter; lad det være vagt, så vokser tilbuddet for at dække det ukendte. Derfor er det mest nyttige, du kan gøre, før du spørger om pris, at blive tydelig på, hvad appen faktisk skal gøre.

Hvad der bestemmer prisen

Fem ting flytter prisen på en app mere end noget andet:

• Hvor mange funktioner du lancerer med. Hver skærm, hvert flow og hvert grænsetilfælde er design plus udvikling plus test. Den mest effektive måde at styre prisen på er at lancere med færre funktioner, godt udført.
• Dybden i designet. Et rent og gennemtænkt interface, der følger Apples retningslinjer for grænseflader, koster reel designtid, og det er det, der får brugerne til at stole på appen og blive ved med at bruge den.
• Kompleksiteten i backenden. En app, der blot viser indhold, er billig; en der koordinerer brugere, betalinger eller opdateringer i realtid, bærer størstedelen af den tekniske pris på serveren, ikke på skærmen.
• Integrationerne. Betalinger, kort og tredjepartstjenester lægger hver arbejde til, og hver er et sted, hvor noget kan gå i stykker og kræve vedligeholdelse.
• Kravene til lanceringen. At udgive i App Store betyder at bestå Apples retningslinjer for App Store, som belønner et ægte og gennemarbejdet produkt og afviser tynde eller ødelagte.

Mønstret bag alle fem er det samme: prisen følger substansen. Du betaler ikke for en app i det abstrakte, men for det specifikke arbejde, netop din app kræver.

Pris efter apptype

Type app	Vejledende pris (kroner)	Hvad du får
Fokuseret MVP	200.000 til 450.000	Kerneflow native, rent design, lancering i App Store
Vækst-app	450.000 til 750.000	Flere funktioner, ægte backend, integrationer, finpudsning
Fuldt produkt	750.000 til 1.000.000+	Mange funktioner, kompleks backend, klar til at skalere

To bemærkninger til tabellen. Den fokuserede MVP er udgangspunktet for næsten enhver satsning, fordi den gør en idé til noget, rigtige brugere kan prøve, for færrest mulige penge. Og springene mellem niveauerne handler mest om backend og funktioner, ikke om æstetisk finpudsning: du vælger hvilket niveau, du køber, ved at styre omfanget, ikke ved at skære i designkvaliteten, som er det forkerte sted at spare.

MVP: byg mindre først

Den dyreste fejl, en iværksætter kan begå, er at bygge hele visionen, før nogen har brugt den. Vejen, der sparer penge og reducerer risiko, er MVP’en: en første version, der gør den ene ting, appen skal gøre, godt nok til, at rigtige folk bruger og betaler.

1. Vælg kernen. Den ene opgave, appen findes for. Alt andet venter.
2. Design den ordentligt. En lille app, der føles rigtig, slår en stor, der føles grov. Byg den native i Swift, så den er hurtig og føles som en ægte iPhone-app.
3. Genbrug hvor du kan. Betalinger og login kommer fra afprøvede tjenester, ikke fra skræddersyet kode.
4. Lancér og lyt. Læg den i App Store, se hvad rigtige brugere gør, og lad det afgøre, hvad du bygger videre.

Sådan startede næsten alle succesfulde apps, små og fokuserede, og voksede derefter på grundlag af beviser. At udgive den kræver en Apple Developer Program-konto og at den består Apples gennemgang.

Skjulte omkostninger, og hvorfor billig kode koster mere

Byggetilbuddet er det største tal, men ikke det eneste, og de omkostninger, der overrasker iværksættere, kommer efter lancering. En app er et levende produkt, ikke et engangskøb, og at budgettere kun for bygget undervurderer den ægte total.

• Vedligeholdelse. Apple udgiver en ny iOS-version hvert år, telefoner ændres, og de tjenester, appen afhænger af, opdateres. Sæt cirka 15 til 20 procent af byggeprisen af om året for at holde appen kørende.
• Serveromkostninger. Servere og tjenester faktureres hver måned, og regningen vokser, når appen får succes, og flere bruger den.
• Apple Developer Program. Et årligt gebyr for at holde appen i App Store.
• EU-vilkår. Danmark er omfattet af EU’s Digital Markets Act, og Apple tilbyder derfor alternative forretningsvilkår i EU: apps kan distribueres via alternative markedspladser eller direkte fra din egen hjemmeside, og kommissionen på App Store er sat ned til 10 eller 17 procent for digitale varer, med et tillæg på 3 procent hvis du bruger Apples betalingsløsning. Det ændrer sjældent byggeprisen, men det forbedrer regnestykket for, hvad appen tjener, når den er live.

Den dybeste skjulte omkostning er dog selve det billige byg. En app lavet så billigt som muligt kommer ofte med rodet kode, der er langsom at ændre og dyr at rette, så besparelsen på tilbuddet bliver en større regning inden for et år. Billig kode er ofte den dyreste kode, når du regner hele levetiden med.

Sikkerhed i budget og tidsplan

Din situation	Fornuftig tilgang	Hvorfor
Tester en idé	Fokuseret MVP, den lave ende	Bevis efterspørgsel, før du bruger mere
Klart, ambitiøst produkt	Faseopdelt byg, etapevist budget	Lær og justér mens du bygger
Backend-tung app	Sæt mere af til serversiden	Der ligger den ægte omkostning
Langsigtet produkt	Tag vedligeholdelse med fra dag ét	Appen koster at drive, ikke kun at bygge

Danmark har en stærk it-sektor, og en startup i København vil have et pålideligt budget, ikke et gæt. Det får du bedst ved at bygge i faser i stedet for at satse alt på ét stort tal. En fast, betalt opdagelses- og designfase gør ideen konkret og danner det eneste ærlige grundlag for at prissætte resten. Derefter deles bygget i afgrænsede etaper med egen pris, som du godkender, før de starter. Sådan får du forudsigelighed på hver defineret del, reel fremgang du kan se, og mulighed for at justere kurs undervejs, i stedet for ét gæt på hele appen. Det er også sådan, du undgår de ubehagelige overraskelser, fordi lidt bygges, før det er forstået og aftalt.

Native eller hybrid: effekten på prisen

Et spørgsmål, der går igen i ethvert tilbud, er, om appen skal bygges native til iOS eller med en hybrid tilgang, der sigter mod både iPhone og Android med én kodebase. Valget har en reel effekt på prisen, men ikke sådan, som mange iværksættere venter.

Ved første øjekast virker hybrid billigere, fordi én kode til to systemer lover mindre arbejde. Har du virkelig brug for begge platforme fra dag ét, er det ofte tilfældet. Men på iPhone mærkes kvalitetsforskellen: en native app bygget i Swift er hurtigere, svarer bedre på berøring og bevægelser, og følger iPhonens konventioner naturligt, mens en hybrid app ofte føles en anelse malplaceret netop der, hvor Apple-brugere er mest kræsne, i de små detaljer, der adskiller en app, folk beholder, fra en, de sletter. De tekniske genveje, der sparer penge i starten, bliver ofte vedligeholdelsesomkostninger, når hver iOS-opdatering kræver justering.

Tommelfingerreglen er denne: er dit publikum mest på iPhone, eller er kvaliteten af oplevelsen central, betaler native sig som regel på totalen, ikke kun på det første tilbud. Har du brug for begge platforme med det samme og et stramt budget, er godt hybridarbejde et forsvarligt valg, forudsat at du ved, hvad du bytter væk. Den rigtige pris afhænger af, hvilken platform der faktisk betyder noget for dine brugere, ikke af hvilket tal der ser lavest ud i dag, og det er præcis den slags afvejning, du kan lægge tydeligt frem for en bestyrelse, der vil have et pålideligt budget.

Når du ikke har brug for en native app

Vær ærlig om, hvorvidt du virkelig har brug for en native app. Er ideen dybest set et indholdswebsted eller en simpel formular, kan et godt responsivt website tjene dig bedre og koste langt mindre end nogen app. En native app fortjener prisen, når du virkelig har brug for telefonen: notifikationer, brug uden net, funktioner i enheden, ægte ydeevne, eller en plads i App Store, hvor brugerne leder efter apps. Er ingen af disse centrale i din idé, er en app til flere hundrede tusinde kroner det forkerte første skridt, og en god partner siger det.

Når en native app er det rigtige valg, køber du en ægte, hurtig og veldesignet første version, som rigtige brugere kan prøve, bygget til at vokse i stedet for at blive smidt væk. Et team, der designer og bygger under samme tag, som os, afgrænser en MVP inden for dit budget, bygger den native og tager den til App Store i faser, du kan følge, med en pris du kan lægge frem linje for linje. Se eksempler i vores arbejde og få et ærligt, afgrænset estimat for din idé gennem en kort samtale.