CTO as a Service

App, webapp eller begge?

En testbænk med telefoner og tablets i forskellige størrelser på stativer, alle med samme uskarpe app, og en hånd, der trykker på en af dem

Spørg, hvad brugeren skal kunne, og hvor brugeren står, når det sker. Skal produktet bruges ved et skrivebord, er en webapp, altså software der kører i browseren, næsten altid det rigtige at starte med. Skal det bruges på farten, med kamera, adviseringer eller uden forbindelse, kan en mobilapp være nødvendig. Vær opmærksom på, at en app binder jer til mere end en webapp: to platforme, app-butikkernes krav og brugere på gamle versioner. Og en app kan ændre, hvordan Cyber Resilience Act rammer jer. Mange ønsker en app, fordi det føles som et rigtigt produkt, så undersøg først, om brugerne faktisk har brug for den.

Valgmulighederne

Webapp. Kører i browseren på alle enheder. Én kodebase, ingen installation, og nye versioner når alle med det samme.

Progressiv webapp. En webapp, der kan lægges på hjemmeskærmen og opføre sig lidt som en app. Et godt mellemtrin, hvor mulighederne afhænger af telefonen og browseren.

Native app. Skrevet særskilt til iPhone og Android. Bedste adgang til telefonens funktioner og den mest flydende oplevelse. Kræver reelt to kodebaser og ofte to sæt kompetencer.

Krydsplatform-app. Én kodebase, der bliver til apps på begge platforme. Dækker de fleste behov og er ofte det fornuftige valg, når der skal en app til.

Det, der taler for en app

Tjek, om mindst ét af disse er vigtigt for brugeren:

  • Telefonens funktioner. Kamera, GPS, bluetooth og lignende, brugt hyppigt.
  • Adviseringer. Brugeren skal reagere med det samme.
  • Uden forbindelse. Produktet skal virke i kælderen, på byggepladsen eller i marken.
  • Daglig brug på farten. Få hurtige klik mange gange om dagen.
  • Forventning hos brugerne. I jeres marked findes man i app-butikken.

Har I ingen af dem, er en webapp, der virker godt på telefonen, som regel nok til at komme i gang. Bevis behovet med rigtige brugere først. Afgrænsningen af første version står i hvad skal med i første version.

Det, en app binder jer til

Beslutningen handler om meget mere end den første udviklingsopgave.

Vedligehold. Styresystemer opdateres, og apps skal følge med, også når I ikke selv har nyt at give. Et produkt, der ikke vedligeholdes, holder til sidst op med at virke.

App-butikkernes krav. Apple og Google gennemgår apps og stiller krav til indhold, privatliv og betalinger. Tjek deres gældende regler direkte, for de ændrer sig. Reglerne kan påvirke forretningsmodellen, især hvis der sælges noget inde i appen. En afvist opdatering kan desuden forsinke en vigtig rettelse.

Gamle versioner. Webapps opdateres for alle. Mobilapps opdateres, når brugeren vil. Serveren skal derfor kunne tale med flere versioner samtidig, og I skal kunne tvinge en opdatering, når det er nødvendigt.

Ejerskab af konti. Konti hos app-butikkerne skal stå i virksomhedens navn, for ellers er det svært at komme til senere. Tjek listen i ejer I koden og kontiene.

Test. Mange slags telefoner og flere styresystemer skal testes, og det tager tid.

En app kan ændre jeres stilling efter CRA

Cyber Resilience Act, forkortet CRA, er EU’s regler om cyberrobusthed og stiller krav til produkter med digitale elementer. Fabrikanter har siden 11. september 2026 haft pligt til at underrette, og de øvrige hovedkrav træder i kraft 11. december 2027.

I Kommissionens vejledning, som ikke er bindende, er en webapplikation, som brugeren alene tilgår i en browser, ikke i sig selv et produkt med digitale elementer, medmindre den understøtter funktionen af et sådant produkt. Det samme gælder progressive webapps, der kun tilgås i browseren. En app fra en app-butik kører derimod hos brugeren og nævnes som eksempel på et produkt. Installerer I en lokal klient, kan den fjerndatabehandling, klienten er afhængig af, altså jeres backend, blive en del af produktet.

Det betyder, at samme SaaS kan falde uden for reglerne som ren webapp og være omfattet, når den får en mobilapp. Det er Kommissionens opfattelse, og den endelige afgørelse ligger hos domstolene. Tag det med i beslutningen, og læs om en webapp er omfattet af CRA. Det konkrete svar for jeres produkt er et spørgsmål til en advokat.

En fornuftig rækkefølge

For de fleste forretningsprodukter ser vejen sådan ud:

  1. Byg en webapp, der virker godt på en telefon.
  2. Mål, hvad brugerne gør på mobilen, og spørg dem, hvad der mangler.
  3. Tilføj progressiv webapp, hvis det dækker behovet.
  4. Byg en krydsplatform-app, når behovet er vist, og I har råd til at vedligeholde den.

Er produktet derimod rettet mod forbrugere, der bruger det i farten hver dag, kan rækkefølgen vendes, så appen kommer først. Men hold server og forretningslogik adskilt fra selve appen, så en webudgave ikke kræver, at alt laves om.

Teknologien bør I vælge ud fra, hvad teamet kan, se teknologivalg til MVP’en. Får I bygget hos en leverandør, så skriv tydeligt ind, hvad der forventes af platforme og versioner, se før I beder om tilbud på en app.

Spørgsmål, der afgør det

  1. Hvor står brugeren, når produktet bruges?
  2. Hvilken telefonfunktion er uundværlig, og hvad sker der uden den?
  3. Hvem skal vedligeholde appen om to år?
  4. Skal der sælges noget inde i appen?
  5. Er vi klar til de krav, en app kan udløse?

Det skal I lade være med

· At bygge en app, fordi konkurrenten har en. Spørg først brugerne.
· At bygge to native apps fra starten uden en klar grund. Det er to produkter at holde i live.
· At glemme brugerne på gamle versioner. Backend skal kunne tale med dem.
· At lade app-butikskontoen stå i en udviklers navn. Den skal være virksomhedens.

Det skal I kræve af den eksterne

  • ☐ En anbefaling, der bygger på brugernes behov.
  • ☐ Et overslag over det løbende arbejde beskrevet i opgaver.
  • ☐ Et klart svar på, om valget ændrer jeres stilling efter reglerne, med forbehold for, hvad der er juridisk.
  • ☐ En plan for ejerskab af konti og for test på rigtige enheder.

Kilder

Senest gennemgået: november 2026.

Næste skridt

Læs også: Det skal I have klar, før I beder om et tilbud på en app · Cyber Resilience Act: hvad betyder den for jeres produkt?

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Mangler I en CTO?

Fortæl kort, hvad der fylder: produktet, teamet, leverandøren eller en kunde, der stiller krav. Rådgivningen er uvildig og uden bindinger til leverandører, så svaret tager udgangspunkt i jeres situation.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.