Når du ber om tilbud på en app, dukker ordene raskt opp: API, backend, database, adminpanel, integrasjoner. De står i tilbudene, de driver prisen, og de er ofte det som skiller to tilbud som ser like ut.
Du trenger ikke kunne programmere for å forstå dem. Men du trenger å vite hva de betyr for din app, fordi det er du som kjenner svarene på spørsmålene som avgjør hvor mye som må bygges. Denne artikkelen forklarer delene i et vanlig app-prosjekt, når du trenger dem, og hva du bør ha tenkt gjennom før utviklingen starter.
Hva er et API i et app-prosjekt?
En app består som regel av to deler. Den ene er det brukeren ser: skjermene, knappene og teksten på telefonen. Den andre kjører på en server og kalles backend. Den lagrer data, sjekker hvem brukeren er, og bestemmer hva hver bruker får se og endre.
API-et er avtalen mellom de to. Når appen skal vise dagens bestillinger, spør den API-et. Når brukeren lagrer et skjema, sender appen dataene til API-et, som sjekker dem og lagrer dem. Appen snakker aldri direkte med databasen, alt går gjennom API-et.
Et enkelt bilde er en restaurant. Gjestene er appen, kjøkkenet er databasen, og servitøren er API-et. Gjestene bestiller fra en meny, servitøren tar bestillingen videre, og ingen gjester går inn på kjøkkenet selv.
Det samme API-et kan betjene flere klienter. iPhone-appen, Android-appen, et webpanel og et eksternt system kan alle snakke med den samme backenden. Det er derfor et godt planlagt API er en av de viktigste delene av løsningen. Det er grunnmuren alt annet bygger på.
Når trenger appen backend?
Ikke alle apper trenger backend. En app som lagrer alt lokalt på telefonen, klarer seg uten. Det gjelder flere ideer enn man skulle tro: kalkulatorer, sjekklister, dagbøker og enkle registreringsverktøy for feltarbeid. Slike apper er raskere og rimeligere å lage, og de koster nesten ingenting å drifte.
Du trenger backend når minst ett av disse er sant:
- Dataene skal følge brukeren. Hvis brukeren bytter telefon eller logger inn på nettbrettet, skal alt være der.
- Flere skal dele data. En kollega skal se det du registrerte, en kunde skal se status på bestillingen sin, eller en leder skal se hele teamets arbeid.
- Innhold skal endres uten ny app. Menyer, priser, nyheter eller åpningstider skal kunne oppdateres uten å sende en ny versjon til App Store.
- Appen skal snakke med andre systemer. Betaling, regnskap, et fagsystem eller en nettbutikk.
- Noe skal skje når appen er lukket. Push-varsler, påminnelser, e-poster eller nattlige jobber.
Hvis svaret er nei på alle fem, kan appen sannsynligvis klare seg uten backend, i alle fall i første versjon. Det er et av de viktigste spørsmålene å avklare tidlig, fordi det flytter prosjektet et helt nivå i pris.
Database, brukere og rettigheter
Databasen er der dataene bor. Tenk på den som et sett med tabeller: én for brukere, én for bestillinger, én for produkter, og koblinger mellom dem. Hvordan tabellene henger sammen, kalles datamodellen. Den er usynlig for brukerne, men den bestemmer mye av hva appen kan gjøre senere.
En god datamodell krever at noen forstår virksomheten. Kan en kunde ha flere adresser? Kan en bestilling deles mellom to avdelinger? Kan en ansatt jobbe for flere selskaper? Slike spørsmål virker små, men er dyre å endre når appen er i drift med ekte data. Derfor bruker vi tid på dem før utviklingen starter.
Så snart det finnes brukere, finnes det også rettigheter. Den enkleste modellen er at hver bruker ser sine egne data. Det blir mer krevende når det finnes organisasjoner, avdelinger eller roller: en leder som ser hele teamet, en administrator som kan endre alt, en kunde som bare ser sine egne saker.
Rettighetene må håndheves i backend, ikke bare skjules i appen. At en knapp ikke vises, betyr ikke at handlingen er stengt. API-et må sjekke hver eneste forespørsel: hvem spør, og har de lov til akkurat dette? Feil i tilganger er blant de mest alvorlige feilene en forretningsapp kan ha, fordi de kan gi noen tilgang til andres data.
Innlogging er den delen brukerne ser. E-post og passord er enklest. Innlogging med Google eller Apple gjør det lettere for brukerne og er rimelig å legge til. Vipps og BankID gir sterkere identifisering, men krever avtaler og mer arbeid.
Adminpanel: hvem skal styre innhold og data?
Når appen er i drift, må noen hos dere kunne gjøre ting: legge inn nytt innhold, hjelpe en bruker som har låst seg ute, se over bestillinger, eller trekke ut en rapport. Et adminpanel er verktøyet for dette, som regel en egen webløsning som snakker med samme API som appen.
Det er den posten som oftest mangler i budsjettet, og som oftest viser seg å være nødvendig. Spørsmålet er når.
Med få brukere i starten kan mye gjøres manuelt eller direkte i databasen. Det er ikke elegant, men det frigjør penger til å finne ut om appen fungerer. Når det begynner å ta tid hver dag, vet dere også nøyaktig hva panelet trenger å gjøre.
Noen ganger er panelet selve kjernen. Hvis appen er for ansatte i felt og kontoret skal planlegge jobber, følge opp og fakturere, er webløsningen like viktig som appen. Da bygger dere i praksis to løsninger på felles backend, og det bør planlegges slik fra start. Vi har skrevet mer om skreddersydde webapplikasjoner for slike behov.
Et godt spørsmål å stille deg selv: hvem hos oss skal jobbe med dataene i appen, og hva gjør de i dag? Svaret avgjør om dere trenger et panel, og hvor stort det bør være.
Integrasjoner mot eksterne systemer
De fleste bedriftsapper må snakke med noe dere allerede har. Et regnskapssystem, et CRM, en nettbutikk, et lagersystem eller et fagsystem for bransjen. I tillegg kommer standardtjenester som betaling, kart, e-post og SMS.
Integrasjoner går nesten alltid via backend, ikke direkte fra appen. Det er tryggere, fordi nøklene til de andre systemene aldri ligger på telefonen, og det er mer robust, fordi backend kan prøve på nytt hvis det andre systemet er nede.
Hvor mye arbeid en integrasjon er, avhenger nesten bare av det andre systemet. Et moderne system med god dokumentasjon, et testmiljø og et ordentlig API går raskt. Et eldre system uten dokumentasjon, der tilgang må bestilles og testdata ikke finnes, kan ta flere ganger så lang tid.
Tre ting gjør integrasjoner enklere:
- Start med tilgangene tidlig. Avtaler, API-nøkler og testmiljø tar ofte uker å få på plass. Det er her mange prosjekter blir stående og vente.
- Avklar hvilken vei dataene går. Skal appen bare lese fra systemet, eller også skrive tilbake? Og hvilket system eier sannheten hvis de er uenige?
- Vurder om det må være sanntid. En synkronisering hver natt er ofte nok, og mye enklere enn at alt skal oppdateres i samme sekund.
Hvis systemet dere bruker ikke har et API, er det ikke nødvendigvis stopp. Noen ganger holder en fil som eksporteres og importeres automatisk. Det er verdt å spørre leverandøren av systemet tidlig.
Vanlige sikkerhetshensyn i API-er
Et API er åpent mot internett, og det må behandles deretter. Det betyr ikke at det er farlig, men at noen ting må være på plass fra første dag.
- All trafikk krypteres. Kommunikasjonen mellom app og API går over HTTPS, slik at ingen kan lese den underveis.
- Hver forespørsel sjekkes. API-et sjekker både hvem som spør og om de har lov, hver gang. Det holder ikke at appen bare viser riktige knapper.
- Ingen hemmeligheter i appen. Nøkler til betalingsløsninger, regnskapssystemer og andre tjenester ligger i backend. Alt som ligger i appen, kan i prinsippet hentes ut av en som vil.
- Begrens antall forsøk. Innlogging og andre sårbare deler bør ha grenser for hvor mange forsøk som tillates, slik at ingen kan prøve seg fram til et passord.
- Valider alt som kommer inn. API-et skal aldri stole på at dataene fra appen er riktige. De sjekkes før de lagres.
- Logg og overvåk. Uvanlig trafikk og feil skal gi beskjed, slik at noen kan reagere før brukerne merker det.
I tillegg kommer personvern. Du må vite hvilke personopplysninger som lagres, hvor serverne står, hvem som har tilgang, og hvor lenge dataene beholdes. For mange norske bedrifter er det et krav at dataene lagres i EU eller EØS, og det er noe av det første en større kunde spør om.
Hva bør avklares før utvikling starter?
Du trenger ikke en teknisk spesifikasjon for å be om tilbud. Men jo flere av disse spørsmålene du kan svare på, desto mer presise og sammenlignbare blir tilbudene:
- Hvem er brukerne? Kunder, ansatte, eller begge? Hvor mange, omtrent, det første året?
- Skal brukerne logge inn? Og i så fall hvordan: e-post, Google og Apple, eller BankID og Vipps?
- Hvilke roller finnes? Ser alle det samme, eller har noen tilgang til mer?
- Hvem skal administrere innhold og brukere? Og hva gjør de i dag?
- Hvilke systemer skal appen snakke med? Lag en liste, med navn på systemene og hvem som leverer dem.
- Hvor følsomme er dataene? Helseopplysninger, økonomi eller personnummer stiller høyere krav.
- Hva skal skje uten at appen er åpen? Varsler, påminnelser, rapporter eller automatiske jobber.
- Hvem skal eie løsningen? Kildekode, serverkontoer og data bør eies av bedriften, ikke av leverandøren.
Har du ikke svar på alt, er det helt normalt. Det er nettopp det de første samtalene med en leverandør bør handle om. Men et tilbud som ikke stiller disse spørsmålene, har sannsynligvis gjettet på svarene.
Slik påvirker backend pris og tidsbruk
Det er backenden som flytter et prosjekt fra ett nivå til det neste. En app uten innlogging og backend ligger hos oss typisk på 50 000 til 100 000 kroner og tre til fem uker. Med innlogging og backend er nivået 80 000 til 300 000 kroner og seks til fjorten uker, avhengig av hvor mye som skal med.
Utover det kommer delene i denne artikkelen som egne poster. Et adminpanel ligger typisk på 70 000 til 130 000 kroner. Hver integrasjon ligger på 30 000 til 70 000 kroner, og spennet handler nesten bare om det andre systemet. En full plattform med app, webpanel, flere roller og integrasjoner starter rundt 200 000 kroner og tar tre til seks måneder. Vi har gått gjennom tallene i detalj i prisguiden for apputvikling.
En backend koster også penger i drift. Servere, database, lagring og utsending av varsler koster gjerne noen tusen kroner i måneden for en app med moderat bruk, og mer når antall brukere vokser. I tillegg kommer vedlikeholdet, som vi har beskrevet i drift av app etter lansering.
Den viktigste besparelsen ligger i rekkefølgen. Start med det backenden må gjøre for at den første versjonen skal fungere, og legg til panel og integrasjoner når dere vet at de trengs. Et godt planlagt API gjør at det er enkelt å bygge videre, uten å måtte bygge om.
Vil du se hvordan vi jobber med apputvikling med backend, eller trenger du hjelp til å finne ut hva din løsning faktisk krever? Diskuter teknisk løsning med oss.