Apputvikling i Oslo

Av Weapp · Oppdatert 2026-09-24

Apputvikling for virksomheter i Oslo handler ofte om apper som skal nå brukerne på både iOS og Android raskt. React Native gir én kodebase for begge plattformene, og native utvikling bruker vi når appen krever det. Weapp bygger apper fra Göteborg med en fast rytme av sprinter og demoer, og vi tar gjerne møter hos dere i Oslo.

Nesten halvparten av dem som jobber med IT-tjenester i Norge, har arbeidsstedet sitt i Oslo. Ifølge SSB gjaldt det 34 097 personer i fjerde kvartal 2025. For en virksomhet som skal lage en app, betyr det et stort utvalg av byråer og konsulenter å velge mellom. Vi i Weapp er et digitalt produktbyrå i Göteborg med rundt 38 utviklere, designere og strateger. Vi kan jobbe i Oslo og møte dere der, mens selve utviklingen skjer i teamet vårt i Göteborg.

Oslo: stort utvalg og høye krav fra brukerne

Et stort utvalg gjør ikke valget enklere. Tilbudene skiller seg ofte mer i innhold enn i pris, og timeprisen alene sier lite om hva appen til slutt koster. Hvor byrået sitter, blir da et mindre viktig spørsmål enn hva som faktisk er med i tilbudet, hvem som gjør jobben, og hvordan dere får innsyn underveis. Vi har skrevet mer om hva dere bør se etter, i hvordan velge apputvikler.

Konkurransen om brukernes oppmerksomhet er samtidig internasjonal. En app for brukere i Oslo blir sammenlignet med de beste norske og globale tjenestene i samme kategori, ikke bare med lokale alternativer. Det stiller høye krav til design og flyt. Det betyr også at tempo teller: I forbrukersegmentet vinner sjelden den lengste kravlisten. Det gjør appen som møter brukerne først og lærer raskest av dem.

React Native eller native iOS og Android?

Vi bygger begge deler, og prosjektet styrer valget. React Native lar én kodebase drive både iOS og Android, og det er riktig valg for de fleste produkter fordi det senker kostnaden til utvikling og vedlikehold uten at brukeren merker forskjell. Hver ny funksjon etter lansering bygges én gang i stedet for to. Native utvikling i Swift eller Kotlin velger vi når appen krever det ytterste av plattformen: avansert grafikk, maskinvarenære funksjoner eller brukerflyter der ytelsen er kritisk.

For dere som kunde betyr valget også noe for organiseringen. En felles kodebase gir som regel ett team, én backlog og én publiseringsprosess. Native gir to spor som må holdes i takt. Forskjellen merkes både i prosjektbudsjettet og i den løpende driften. Vi har utdypet avveiingen i React Native eller native app.

Slik samarbeider vi med dere i Oslo

Prosjektene våre følger en fast rytme, med fysiske møter der de gjør mest nytte:

Oppstartsworkshop hos dere i Oslo, en dag der mål, målgruppe og de viktigste kravene fastsettes sammen.
Sprinter på to uker med demo: Dere ser en app som fungerer, ikke statusrapporter.
Daglig kontakt i Slack eller Teams og full innsikt i backlog, timeføring og testversjoner.
Fysiske møter ved større veivalg: designretning, lanseringsbeslutning og neste etappe.

Fra Göteborg til Oslo er det rundt tre og en halv time med tog, ifølge Vy. Et møte hos dere er derfor et spørsmål om planlegging, ikke et prosjekt i seg selv. Erfaringen vår er entydig: Det er rytmen og tydeligheten i samarbeidet som avgjør kvaliteten, ikke avstanden.

Forbrukerapper som referanse: Sejfa

Vil dere se hvilket nivå vi sikter mot i forbrukerprodukter, er Sejfa en god referanse: en digital innboforsikring for unge voksne, der hele flyten fra nedlasting til tegnet forsikring er designet for å føles enkel på mobilen. Det er de samme kravene som forbrukerapper for brukere i Oslo møter: lite friksjon i flyten, høyt designnivå og et teknisk fundament som tåler vekst.

Scenario: en app for en nettbutikk i Oslo

Si at en nettbutikk i Oslo vil supplere nettsiden med en app: innlogging, personlige tilbud, pushvarsler om lagerstatus og en raskere vei til kassen. Med React Native og integrasjon mot den eksisterende e-handelsplattformen blir appen et nytt grensesnitt mot den samme forretningslogikken, ikke et parallelt system som må vedlikeholdes for seg. Innlogging med BankID via en godkjent leverandør og betaling med Vipps planlegges inn fra start fordi de former både brukerflyten og backend. Tidsplanen avhenger mest av hvor mange spesialflyter som bygges i tillegg til standardintegrasjonen, og hvor raskt beslutningene tas underveis. Vi har skrevet mer om det i hvor lang tid tar det å lage en app.

Neste steg

Fortell oss hva dere vil bygge, så kommer vi tilbake med et forslag til opplegg, et prisspenn og en ærlig vurdering av hva som bør være med i versjon én. Prisnivåene står i guiden hva koster det å lage en app. Har dere allerede en kravliste, går vi gjerne gjennom den og peker på det som kan vente til versjon to, for det er ofte der den største besparelsen ligger. Kontakt oss, så tar vi gjerne det første møtet hos dere i Oslo.

Ofte stilte spørsmål

Hva koster det å få utviklet en app?

Det avhenger først og fremst av hvor mange brukerflyter appen skal ha, og hvor mange systemer den skal snakke med. En enkel app med få skjermbilder er et helt annet prosjekt enn en app med innlogging, betaling og integrasjon mot et ERP-system. Vi har samlet prisnivåene i en egen guide om hva det koster å lage en app.

Kan appen bruke BankID og Vipps?

Ja. BankID kobles inn via en godkjent leverandør, og Vipps har API-er for betaling. Begge deler er enklest å planlegge inn fra start fordi de påvirker både brukerflyten og backend. Vi avklarer leverandør og betalingsflyt allerede i oppstartsworkshopen.

Må byrået ha kontor i Oslo?

Nei. Apputvikling fungerer godt på avstand med en fast digital rytme, og fysiske workshoper legges inn der de gjør mest nytte, typisk ved oppstart og større veivalg. Vi kan jobbe i Oslo og tar gjerne møter hos dere. Velg byrå etter erfaring og arbeidsform heller enn etter adresse.

Hva bør vi ha med til et første møte?

Det viktigste er problemet dere vil løse, og for hvem. En ferdig kravspesifikasjon er ikke nødvendig. Ta med det dere har: skisser, en budsjettramme, målene for appen og en liste over systemene den skal snakke med. Det er godt nok som grunnlag for en første vurdering.

Kan dere ta over en app som et annet team har bygget?

Ja. Vi starter med en teknisk gjennomgang av kodebasen for å vurdere tilstanden og dokumentasjonen. Deretter lager vi en plan for overtakelse, stabilisering og videreutvikling. Det forutsetter at dere som kunde eier koden, så sjekk det i avtalen dere har i dag.