Ti røde flag i tilbud på web/app/AI-udvikling (og hvordan et godt tilbud ser ud)
Når du hyrer et team til at bygge en hjemmeside, mobilapp eller en AI-funktion, kan tilbud se betryggende ens ud: en tidsplan, en pris og en liste over “inkluderet”. Men små huller i et tilbud bliver ofte til de største årsager til forsinkelser, budgetoverskridelser og dyr vedligeholdelse.
Jensen Technologies har leveret webprojekter i mange år, og vi ser de samme mønstre igen og igen-særligt når AI bliver føjet til ellers “klassiske” web- og app-løsninger. Her er ti praktiske røde flag at holde øje med, og hvad et solidt tilbud typisk bør indeholde.
1) Uklart scope (“Lav en app som X”)
Rødt flag: Tilbuddet beskriver resultatet i brede vendinger, men definerer ikke præcist, hvad der skal bygges.
Sådan ser godt ud: Konkrete user journeys/user stories, specifikke skærmbilleder og flows, hvad der er i scope vs. out of scope, samt en tydelig liste over antagelser. Derudover: en klar ændringsproces (hvordan nye ønsker estimeres og godkendes).
2) Én stor pris uden opdeling
Rødt flag: En samlet fast pris, der blander design, udvikling, test og launch uden indsigt i fordelingen.
Sådan ser godt ud: Opdeling i faser og leverancer (discovery, UX/UI, implementering, QA, launch), og hvad du modtager ved hver milepæl. Selv ved fast pris afslører opdelingen, om planen er realistisk.
3) Uklar ejerskab af kode, design og konti
Rødt flag: Det er uklart, hvem der ejer kildekode, Figma-filer, domæner, analytics og cloud-konti-eller du får at vide, at leverandøren “styrer det”, uden detaljer.
Sådan ser godt ud: Skriftlig bekræftelse på, at du ejer IP, og at du har admin-adgang til kritiske konti. En professionel partner kan godt drifte løsningen, men ejerskab og adgang bør ikke være til diskussion.
4) Ingen tydelig sikkerhedstilgang (især ved AI)
Rødt flag: “Sikkerhed” er én bullet-eller mangler helt. AI øger risiko, fordi der ofte er flere dataflows, leverandører og potentielt nye angrebsvektorer (fx prompt injection).
Sådan ser godt ud: En sikkerhedsbaseline: autentificering/autorisation, least privilege, secret management, dependency patching, og relevant audit logging. For AI: data retention, håndtering af persondata, leverandør-/modelrisiko og konkrete guardrails for uønskede outputs.
5) Test udskydes (“Vi tester til sidst”)
Rødt flag: QA er en lille linje til sidst uden testkriterier. Det giver ofte vanskelige releases og dyr rework.
Sådan ser godt ud: Teststrategi fra start: acceptance criteria pr. feature, automatiserede tests hvor det giver mening (unit/integration), og en defineret device/browser-matrix til manuel test. Der bør også være tid afsat til fejlretning-not bare fejlfinding.
6) Aggressiv tidsplan uden tradeoffs
Rødt flag: Hurtig levering loves uden forklaring af, hvad der forenkles, hvad der udelades, eller hvad der afhænger af dig (content/feedback).
Sådan ser godt ud: En tidsplan, der matcher teamstørrelse og kompleksitet, med tydelige afhængigheder (fx “tekster senest dato X”). Ved fast deadline bør tilbuddet beskrive, hvad der kan skæres væk for at ramme datoen (og konsekvenserne).
7) Ingen performance- eller stabilitetsmål
Rødt flag: Tilbuddet definerer ikke, hvad “hurtig” eller “stabil” betyder. Ved AI ignoreres ofte latens og omkostningsspidser.
Sådan ser godt ud: Mål som Core Web Vitals, crash-free sessions, API-responstid og oppetid-samt hvordan det måles (monitoring og alarmer). For AI: timeouts, fallback-oplevelser og cost controls (rate limiting, caching, usage caps).
8) AI som “magi” (“Bare tilføj GPT”)
Rødt flag: AI behandles som en plug-and-play feature uden evaluering, sikkerhed eller drift. Resultatet bliver let uforudsigelige svar, utilfredse brugere og dyre overraskelser.
Sådan ser godt ud: Klart use case (hvilket problem løser AI?), evalueringsplan (hvordan måles kvalitet?), fallback-UX (hvad når AI tager fejl/er nede), og en plan for iteration. Mange gode AI-løsninger inkluderer også human-in-the-loop for edge cases.
9) Ingen plan for deployment, DevOps eller handover
Rødt flag: Launch er “vi deployer”, uden environments, rollback, backups eller dokumentation.
Sådan ser godt ud: En releaseplan: CI/CD, dev/stage/prod, backups, logging og rollback-strategi. Handover bør inkludere dokumentation, runbooks og basal træning af dit team.
10) Vedligehold er uklart eller “valgfrit”
Rødt flag: Efter launch bliver det uklart, hvem der patcher sårbarheder, opdaterer dependencies, overvåger oppetid eller håndterer kritiske bugs.
Sådan ser godt ud: En realistisk plan efter launch: svartider, supportproces og prioritering mellem bugfix og roadmap. Selv små apps kræver sikkerhedsopdateringer, platformændringer (iOS/Android) og løbende dependency-vedligehold.
Hvad gør du, hvis du spotter røde flag?
Ikke alle røde flag betyder, at du skal gå væk-ofte betyder det blot, at tilbuddet er ufuldstændigt. Nøglen er at få afklaringer på skrift. Stærke teams har intet imod at definere scope, sikkerhed, test, ejerskab og driftsansvar.
Et godt tilbud lover ikke bare levering. Det reducerer risiko, gør tradeoffs tydelige og sætter dig i stand til at forbedre produktet efter launch.
Vil du have en second opinion på et tilbud, du har fået-eller hjælp til at formulere et udbud, som leverandører kan prissætte præcist? Kontakt gerne Jensen Technologies. Vi tager gerne en snak om dine mål og hjælper med at vælge den mest sikre og omkostningseffektive vej for din forretning.