App-udvikling i København

Af Weapp · Opdateret 2026-09-23

App-udvikling i København handler ofte om forbrugerapps i et marked hvor mobilen er standard, og hvor login med MitID og betaling med MobilePay er det brugerne kender. React Native giver én kodebase til både iOS og Android og dermed hurtigere lancering. Weapp bygger apps fra Göteborg, er ofte i København og holder gerne workshops hos jer.

For danske forbrugere er mobilen ikke en ekstra kanal, men den primære. Ifølge Dansk Erhvervs E-handelsanalyse for første halvår 2025 foretages mere end halvdelen af danskernes onlinekøb via smartphone, og mere end 4 ud af 10 køb gennemføres i en mobilapp. En app der skal konkurrere om de brugere, skal derfor kunne det samme som de bedste apps de allerede har på telefonen. Vi hos Weapp bygger apps fra Göteborg, og vi er ofte i København.

København: et marked hvor mobilen er standard

To ting præger app-udvikling til danske brugere. Den første er betaling: Ifølge Vipps MobilePay selv har MobilePay en markedsandel på 92 procent i Danmark blandt personer fra 15 år. Den anden er login: Ifølge Digitaliseringsstyrelsen var 86 procent af brugerne tilfredse med MitID i 2025. Når brugerne er vant til de to løsninger fra hverdagen, bliver de i praksis en del af kravene til en ny app.

Konkurrencen om brugernes opmærksomhed er samtidig international. En app til det danske marked bliver sammenlignet med de bedste danske og globale tjenester i samme kategori, ikke kun med lokale alternativer. Barren for design og flows ligger derefter. Det betyder også at tempo tæller: I forbrugersegmentet vinder den længste kravliste sjældent. Det gør den app der møder brugerne først og lærer hurtigst af dem.

React Native eller native iOS og Android?

Vi bygger begge dele, og valget styres af projektet. React Native lader én kodebase drive både iOS og Android, hvilket er det rette valg for de fleste produkter fordi det sænker udgiften til udvikling og vedligeholdelse uden at brugeren mærker forskel. Hver ny funktion efter lanceringen bygges én gang i stedet for to. Native udvikling i Swift eller Kotlin vælger vi når appen kræver det yderste af platformen: avanceret grafik, hardwarenære funktioner eller flows hvor ydelsen er kritisk.

For dig som kunde betyder valget også noget for organiseringen. Cross-platform giver som regel ét team, én backlog og én releaseproces. Native giver to spor der skal holdes i takt. Forskellen kan mærkes både i projektbudgettet og i den løbende drift. Vi har uddybet afvejningen i React Native vs. native app.

Sådan samarbejder vi med jer i København

Vores projekter kører med en fast rytm og fysiske møder hvor de gør mest gavn:

Opstartsworkshop hos jer i København, en dag hvor mål, målgruppe og de vigtigste krav fastlægges sammen.
Sprints på to uger med demo: I ser en fungerende app vokse frem i stedet for statusrapporter.
Daglig kontakt i Slack eller Teams og fuld indsigt i backlog, tidsregistrering og testversioner.
Fysiske møder ved større vejvalg: designretning, lanceringsbeslutning og næste etape.

Ifølge Øresundstogs køreplan tager direkte tog fra Göteborg til København H omkring 3,5 timer, og SAS flyver direkte fra Landvetter. Et møde på stedet er derfor et spørgsmål om planlægning, ikke et projekt i sig selv. Erfaringen er entydig: Det er rytmen og klarheden i samarbejdet der afgør kvaliteten, ikke afstanden.

Forbrugerapps som reference: Sejfa

Vil du se det niveau vi lægger os på i forbrugerprodukter, er Sejfa en god reference: en digital indboforsikring til unge voksne, hvor hele flowet fra download til tegnet forsikring er designet til at føles enkelt på mobilen. Det er de samme krav som forbrugerapps i København lever under: få friktioner i flowet, et højt designniveau og et teknisk fundament der kan vokse.

Scenarie: en app til en webshop i København

Forestil dig en webshop i København der vil supplere hjemmesiden med en app: login, personlige tilbud, push-notifikationer om lagerstatus og en hurtigere checkout. Med React Native og integration til den eksisterende e-handelsplatform bliver appen en ny brugerflade til den samme forretningslogik, ikke et parallelt system der skal vedligeholdes for sig. Login med MitID via en certificeret broker og betaling med MobilePay planlægges ind fra start fordi de former både flowet og backend. Tidsplanen afhænger mest af hvor mange særlige flows der skal bygges ud over standardintegrationen og hvor hurtigt der træffes beslutninger undervejs. Vi har skrevet mere om det i hvor lang tid tager det at udvikle en app.

Næste skridt

Fortæl os hvad du vil bygge, så vender vi tilbage med et forslag til opsætning, et prisniveau som interval og en ærlig vurdering af hvad der bør med i version ét. Priserne kan du læse mere om i guiden hvad koster det at lave en app. Har du allerede en kravliste, gennemgår vi den gerne og peger på det der kan vente til version to, for det er ofte der den største besparelse ligger. Kontakt os, og vi tager gerne det første møde hos jer i København.

Ofte stillede spørgsmål

Hvad koster det at få udviklet en app?

Det afhænger først og fremmest af hvor mange flows appen skal have og hvor mange systemer den skal tale med. En enkel app med få skærme er et helt andet projekt end en app med login, betaling og integration til et ERP-system. Vi har samlet prisniveauerne i en særskilt guide om hvad det koster at lave en app.

Kan appen bruge MitID og MobilePay?

Ja. MitID integreres ikke direkte, men via en certificeret MitID-broker, og MobilePay har API’er til betaling i apps. Begge dele er nemmest at planlægge ind fra start fordi de påvirker både brugerflowet og backend. Vi afklarer valget af broker og betalingsflow allerede i opstartsworkshoppen.

Skal bureauet have kontor i København?

Nej. App-udvikling fungerer fint på afstand med en fast digital rytm, og fysiske workshops lægges ind hvor de gør mest gavn, typisk ved opstart og større vejvalg. Vi er ofte i København og mødes gerne hos jer. Vælg bureau efter erfaring og arbejdsform frem for adresse.

Hvad skal jeg have med til et første møde?

Det vigtigste er det problem du vil løse, og for hvem. En færdig kravspecifikation er ikke nødvendig. Tag det med du har: skitser, en budgetramme, de systemer appen skal tale med, og hvordan du vil måle om den lykkes. Det er rigeligt som grundlag for en første vurdering.

Kan I overtage en app som et andet team har bygget?

Ja, det sker ofte. Vi starter med en teknisk gennemgang af kodebasen for at vurdere tilstand og dokumentation og lægger derefter en plan for overtagelse, stabilisering og videreudvikling. Det er en forudsætning at du som kunde ejer koden, så tjek det i din nuværende aftale.