Hva koster det å utvikle en webapp?

Spørsmålet «hva koster en webapp» starter med et annet spørsmål: Hva skiller en webapp fra en vanlig nettside? En nettside viser innhold. En webapp gjør noe: Den lar brukerne logge inn, jobbe med data og få resultater tilbake. Det er den forskjellen som avgjør prisen, for en app krever egen logikk, database og innlogging som en informasjonsnettside klarer seg uten.

Prisspenn per kompleksitetsnivå

En enkel webapp har én avgrenset brukerflyt og en håndfull skjermbilder. En middels kompleks app har flere brukerroller, betaling og et par integrasjoner. En avansert plattform håndterer store datamengder, sanntid og dype koblinger mot andre systemer. Spennene er brede fordi detaljene avgjør. To apper som høres like ut i én setning, kan kreve svært ulik arbeidsmengde.

Hva som driver opp prisen, og hvorfor

Det er sjelden grensesnittet som er dyrest. Kostnaden ligger i det brukeren ikke ser:

• Antall brukerroller. En app der alle ser det samme, er enkel. Så snart ulike brukere skal se og ha lov til å gjøre ulike ting (kunde, saksbehandler, administrator), må tilganger bygges og testes for hver kombinasjon. Det vokser raskt.
• Datamodellen. Hvordan informasjonen henger sammen under overflaten, avgjør hvor mye som kan bygges ryddig, og hvor mye som blir unntak. En gjennomtenkt modell er en investering som betaler seg i lavere forvaltningskostnader. En forhastet modell blir dyr å leve med.
• Integrasjoner. Hver kobling mot et annet system er et eget lite prosjekt med egen feilhåndtering. Det andre systemet gjør sjelden akkurat det du ønsker, og det tar tid å bygge bro over det gapet.
• Ikke-funksjonelle krav. Ytelse ved mange samtidige brukere, sikkerhet rundt følsomme data og oppetid døgnet rundt vises ikke i en demo, men koster arbeid og er vanskelige å legge til i etterkant.

Hva du slipper, og hva du må løse selv

En webapp har en tydelig fordel sammenlignet med en mobilapp: Den slipper å gå gjennom appbutikkene. Ingen gjennomgang fra Apple eller Google, ingen butikkavgifter og ingen venting på at en oppdatering skal bli godkjent. Du publiserer en ny versjon, og alle har den med en gang. For et produkt som utvikles ofte, er det en reell fordel. Du kan rette og forbedre samme dag i stedet for å vente på en godkjenning.

Baksiden er at du selv må stå for det appbutikkene ellers tar seg av. Innlogging og kontohåndtering må bygges eller kjøpes inn som en tjeneste. Betaling kobles mot en betalingsløsning, med alt det innebærer av regler og testing. Og distribusjonen (å få brukerne til å finne frem og komme tilbake) er ditt ansvar og skjer via nettet i stedet for fra en butikkhylle. Det er ingen ulempe, men det er arbeid som må få plass i budsjettet.

Tre typer med priseksempler

Webapplikasjoner finnes i mange former. Tre vanlige:

• Kundeportal. «Min side», der kundene ser fakturaer, saker og avtaler. Prisen styres av hvor mange forretningssystemer portalen kobles mot. Regn med 750 000 kr–2,5 millioner kr.
• Internt verktøy. En app som erstatter et regneark eller en manuell prosess, for eksempel håndtering av bestillinger, lager eller saker. Ofte 500 000 kr–1,5 millioner kr, avhengig av antall arbeidsflyter.
• Dashbord. Et grensesnitt som samler og visualiserer data fra flere kilder. Kostnaden ligger i integrasjonene og datamodellen, ofte 620 000 kr–1,9 millioner kr.

Et konkret regneeksempel

La oss si at du vil erstatte en manuell ordreprosess med et internt verktøy: innlogging, et par brukerroller, en skjemaflyt og en kobling mot forretningssystemet i virksomheten. Det er en middels kompleks webapp. Regn med 1,1–1,7 millioner kr og 4–6 måneder. Legger du deretter til kundeinnlogging, betaling og et offentlig tilgjengelig dashbord, klatrer du mot toppen av spennet fordi hvert slikt tillegg fører med seg egen design, egen logikk og egen testing.

En måte å holde kostnaden nede på er å bygge i etapper. Start med det interne verktøyet som løser det mest akutte (den manuelle prosessen som stjeler mest tid), og legg til kundedelen når den første versjonen har bevist verdien sin. Da fordeles kostnaden over tid, og du bygger videre på noe du vet fungerer, i stedet for å gjette alt på forhånd.

Poenget er det samme som i alle utviklingsprosjekter: Hvert «kan vi også få …» har en pris, og det er billigere å prioritere før utviklingen enn underveis. Den feilen som er billigst å unngå, er å spesifisere for bredt fra start. En app som skal gjøre alt for alle, blir dyr å utvikle og vanskelig å bruke. Vil du ha et anslag for akkurat din idé? Se tjenestene våre, eller ta kontakt med en kort beskrivelse, så kommer vi tilbake med et prisspenn.