Fra AI-bygget prototype til et værktøj, andre kan bruge

Hvornår bruger man hvad?

De fleste apps kombinerer flere emner. Start med det problem, I skal løse, og vælg kun de teknologier, som passer til jeres data, brugere og eksisterende miljø.

Vi vil bruge AI direkte i kodeprojektet

Cursor kan hjælpe med at forstå og ændre kode. Brug Git som sikkerhedsnet, giv små afgrænsede opgaver, beskyt følsomme filer, og gennemgå altid diff og tests før udgivelse.

Webappen skal kunne installeres og håndtere ustabilt netværk

En PWA kan give ikon, selvstændigt vindue og udvalgte offline-funktioner fra én webkodebase. Vælg native app, hvis kernefunktionen kræver dyb platform- eller hardwareadgang.

Vi skal vælge, hvor webappen skal hostes

Netlify passer ofte til enkel frontendhosting, Vercel til Next.js, Firebase Hosting til Firebase-apps og Azure til Microsoft-miljøer. Vælg først efter appens runtime, backend og driftskrav.

Vi kan ikke se, om en fejl pludselig gør appen dyr

Kortlæg de handlinger, der driver database, compute, filer, netværk og eksterne API-kald. Kombinér budgetalarmer med tekniske forbrugsmål og afgrænsede grænser i appen.

Login virker, men vi kan ikke lukke stjålne sessioner eller gendanne en konto sikkert

Kortlæg MFA, sessioners levetid, genbekræftelse, tilbagekaldelse og kontogendannelse. Test også mistet enhed, flere aktive enheder og fratrådte brugere.

Vi skal købe domæne eller forbinde web, mail og hosting

Start med korrekt ejerskab og DNS. Dokumentér records, vælg forhandler, beskyt kontoen, og flyt aldrig navneservere uden at sikre mail og verifikationer.

Vi skal kunne genskabe appen efter sletning, fejl eller nedbrud

Lav en samlet plan for kode, data, filer, konfiguration og adgang. En backup giver først ro, når en gendannelse er afprøvet i et sikkert miljø og dokumenteret.

Vi skal kunne flytte appen eller skifte leverandør

Lav en exit-pakke med kode, data, filer, brugere og nødvendig konfiguration. Kontrollér platformens eksportgrænser, og test at materialet kan forstås og genbruges uden adgang til produktion.

Vi har API-nøgler, tokens eller databaseadgange i projektet

Kortlæg hvad der reelt er hemmeligt, hold secrets ude af frontend og Git, adskil miljøer, begræns rettigheder, og dokumentér rotation og lækhåndtering. Vælg opbevaring efter den cloud og hosting, appen allerede bruger.

Vi opdager først fejl, når en bruger fortæller os det

Kortlæg kritiske handlinger, brug hostingens logs, kontrollér appen udefra, og send få alarmer til en navngiven ansvarlig. Vælg værktøjer efter den stack, appen allerede bruger.

Brugeren møder en blank side eller ved ikke, om arbejdet blev gemt

Skeln mellem kendte og uventede fejl, giv et sikkert og handlingsklart svar, bevar input, og forbind brugerens reference med den tekniske hændelse uden at vise interne detaljer.

Alarmen er kommet, men ingen ved hvem der beslutter eller informerer

Lav et lille driftsberedskab med kriterier, roller, hændelseslog, sikre stabiliseringsvalg, fast statusrytme og kontrol af data og brugerrejser før hændelsen lukkes.

Loginlinks, kvitteringer eller andre vigtige app-mails forsvinder

Godkend afsenderdomænet, skeln mellem accepteret og leveret, beskyt tokens, håndtér bounces og suppression, og overvåg hele forløbet fra brugerhandling til modtagersystem.

Vi kan se den aktuelle værdi, men ikke hvem der ændrede eller slettede den

Et revisionsspor gemmer de kritiske forretningshændelser med aktør, objekt, resultat og relevante ændringer. Hold det adskilt fra almindelige fejllogs, og beskyt historikken mod fri redigering.

Kun én person ved, hvordan appen drives og overtages

Saml et systemkort, ansvar, deployment, rollback, runbooks og adgangsveje i versionsstyret dokumentation, og lad en anden person afprøve den uden mundtlige genveje.

Pakker og runtime bliver ældre, men ingen ejer opdateringerne

Kortlæg manifest, lockfile, runtime og deployment, aktivér sikkerhedsalarmer, og send hver opdatering gennem risikovurdering, review, test og en kontrolleret udgivelse.

Hver ændring går direkte live, og vejen tilbage er uklar

Adskil testdata og produktionsdata, brug platformens preview eller staging efter appens risiko, kør et fast smoke test, og dokumentér rollback for både deploy og data.

En risikabel funktion skal kunne åbnes gradvist eller stoppes uden nyt deploy

Brug et feature flag med en sikker standard, tydelig ejer, afgrænset målgruppe og målbare stopkriterier. Håndhæv stadig adgang på serveren, og øv nødstop for app, API og igangværende jobs.

Vi ved ikke, om en ændring har brudt en vigtig arbejdsgang

Lav en risikobaseret teststrategi for de kritiske brugerrejser. Vælg det rette testniveau, brug kontrollerede testdata, og kør de vigtigste kontroller automatisk før udgivelse.

Appen virker for én person, men vi kender ikke kapaciteten

Belastningstest efterligner et kritisk brugerforløb med realistisk samtidighed. Sæt mål ud fra arbejdsdagen, mål hele kæden, og kontrollér både svartid, fejl og data efter testen.

En administrator kan slette eller ændre mange data på én gang

Beregn en konkret forhåndsvisning på serveren, vis mål og følgevirkning, kontrollér rettighed og omfang igen ved udførelse, og planlæg atomisk ændring eller et sikkert job med revisionsspor og gendannelse.

To brugere kan redigere, booke eller gemme de samme data samtidig

Beskriv den forretningsregel, der ikke må brydes, og beskyt den med en atomisk kontrol. Brug transaktioner til samlet læsning og skrivning, versionskontrol mod overskrivning og idempotens mod gentagne requests.

Bookinger, deadlines eller planlagte jobs kan ramme forkert omkring sommertid

Skeln mellem et præcist øjeblik, en lokal aftale, en ren dato og en gentagelse. Bevar den navngivne tidszone, vælg lokal tid eller fast kadence bevidst, og test manglende, dobbelte og forsinkede kørsler.

Vi skal flytte Excel-, CSV- eller gamle systemdata ind i appen

Kortlæg felter og stabile kildenøgler, valider i et mellemområde, gør importen sikker at genkøre, og afstem antal, summer og relationer før brugerne overtager data.

Brugerne kan logge ind, men vi ved ikke præcist, hvem der må se og ændre hvad

Lav en adgangsmatrix for roller, virksomheder og dataposter. Håndhæv den ved API, database eller Security Rules, og test også de handlinger, som skal afvises.

Support skal kunne se brugerens problem uden permanent adgang til hele produktionen

Start med dataminimeret diagnostik, og åbn kun en navngiven, tidsbegrænset supportsession med konkret sag, mål og omfang. Bevar den virkelige aktør, vis supporttilstanden tydeligt, og log start, handlinger og afslutning.

API'et kan kaldes uden om formularen, og vi mangler grænser for input og misbrug

Kortlæg endpoints og webhooks, valider input og tilladte felter på serveren, vælg korrekt CORS- og CSRF-beskyttelse, og begræns størrelse, frekvens og dyre handlinger efter den konkrete stack.

En ny backend kan ramme gamle browsertabs, mobilapps eller integrationer

Beskriv API'ets requests, svar og adfærd som en kontrakt. Bevar gammel form under overgangen, test tidligere klient mod ny backend, og versionér kun når et reelt brud ikke kan undgås.

Offentlige formularer, bookinger eller dyre kald kan automatiseres og misbruges

Vurder skaden i hvert forretningsflow, og kombiner passende grænser pr. konto, virksomhed, session, flow og eventuelt IP. Håndhæv dem på serveren, brug botkontrol som ekstra lag, og mål både afvisninger, omkostning og legitime brugere, der rammes.

AI-funktionen læser tekst eller filer og kan bruge værktøjer i andre systemer

Behandl eksternt indhold som ubetroet, begræns data og værktøjer, validér modellens forslag på serveren, og kræv en konkret godkendelse før sletning, betaling, adgangsændring eller ekstern kommunikation.

Data fra brugere eller integrationer bliver vist i browseren, men vi har ikke gennemgået XSS og headers

Kortlæg hvor ubetroede værdier bliver til tekst, HTML, links eller scripts. Bevar frameworkets sikre rendering, sanitér nødvendig formateret tekst, og afprøv en tilpasset Content Security Policy før håndhævelse.

Appens server henter filer, previews eller webhookadresser fra en URL

Fjern den frie URL, når behovet kan løses med upload eller et kendt leverandør-id. Ellers skal protokol, destination, opløst IP og redirects kontrolleres, mens netværk, tid, størrelse og samtidighed afgrænses.

Betalings-, booking- eller statushændelser kommer via webhooks

Kontrollér leverandørens signatur på den rå request, gem eventet før kvittering, og gør behandlingen sikker ved dubletter, forsinkelse, forkert rækkefølge og genbehandling. Vælg endpoint og kø efter appens eksisterende stack.

Kunder skal betale i appen uden falsk status eller dobbelt levering

Lad betalingsudbyderen indsamle kortoplysninger, beregn ordren på serveren, behandl retur-siden som status, bekræft med signerede webhooks, og afstem lokale ordrer med de faktiske betalinger.

Appen kalder et eksternt system, men kan hænge eller gentage handlingen ved fejl

Sæt en timeout på hvert kald, retry kun fejl der kan være midlertidige, brug idempotens ved skrivning, og bevar en ærlig mellemstatus, når leverandørens resultat ikke kan bekræftes.

Appen bruger persondata, men ingen har samlet overblik over formål, leverandører og sletning

Kortlæg dataflowet fra formular til database, logs, integrationer, AI-tjenester og backup. Afklar ansvar, grundlag, dataminimering, slettefrister, brugerrettigheder, risici og håndtering af sikkerhedsbrud.

Vi har et cookiebanner, men ved ikke om statistik og marketing faktisk venter på valget

Kortlæg cookies, pixels, browserlagring og tredjepartsrequests. Adskil formål, blokér ikke-nødvendige tags før valg, gør afvisning og tilbagetrækning brugbar, og test den faktiske netværkstrafik i en ren browser.

Vi skal eje koden og kunne rulle tilbage

Brug GitHub til kode og historik. Beskyt den stabile branch med pull requests og relevante checks, hvis ændringer ikke må kunne gå direkte i drift.

Medarbejderne skal bruge deres arbejdskonto

Vælg Microsoft Entra SSO, hvis virksomheden bruger Microsoft 365. Firebase Auth kan passe til appens egne brugerkonti.

Vi skal hoste en webapp og gemme dokumentdata

Firebase Hosting og Firestore kan være en enkel samlet løsning til en frontend og en dokumentdatabase.

Appen bruger Supabase direkte fra browseren, men vi har ikke testet dataadgangen

Kortlæg nøgletyper og eksponerede tabeller, begræns grants, håndhæv RLS pr. bruger og virksomhed, og test afslag uden om brugerfladen. Gennemgå også Storage, views, funktioner og Realtime.

Vi skal modtage webhooks eller køre backendkode i Azure

Azure Functions passer til små API'er, integrationer, køer og planlagte opgaver i et Azure-miljø.

Vi skal gemme enkle opslag eller filer i Azure

Brug Table Storage til simple poster, der findes via kendte nøgler, og Blob Storage til PDF'er, billeder og andre filer. Vælg SQL, når data kræver relationer, joins eller fri rapportering.

Vi har strukturerede relationer, rapportering eller mange sammenhængende data

En SQL-database kan være bedre end en dokumentdatabase. SQL-guiden forklarer datamodel, constraints, sikker adgang, migreringer og forbindelser med PostgreSQL som praktisk eksempel.

Appen skal arbejde med en brugers Google Drive, Gmail eller Kalender

Brug Google OAuth til afgrænset samtykke uden at dele adgangskoder. Vælg målgruppe og mindst mulige scopes, beskyt callback og tokens, og adskil test- og produktionsklienter.

Medarbejdere eller kunder skal uploade dokumenter og billeder

Brug privat lager, afgræns typer og størrelse, kontrollér adgang til den enkelte fil, og læg risikable filer i karantæne før behandling eller deling. Teknologien kan være Firebase, Azure eller et andet objektlager.

Vælg den driftsopgave, der er relevant for jeres løsning

Emnerne er selvstændige opslag. Brug dem i den rækkefølge og kombination, som passer til jeres teknologi, risici og brugere.