6 røde flag i et webudviklingstilbud (og de præcise spørgsmål, der afslører dem)
De fleste web- og mobilprojekter fejler ikke på grund af “dårlig kode”. De fejler, fordi forventninger aldrig blev gjort tydelige: hvad er inkluderet, hvad er ikke, hvem ejer hvad, og hvad betyder “klar til lancering” egentlig?
Hos Jensen Technologies har vi bygget hjemmesider og apps i mange år. Vi har set tilbud, der ser flotte ud på overfladen, men som gemmer risiko i vage formuleringer. Her er seks klassiske røde flag-og de enkle spørgsmål, der hurtigt skiller en stærk leverandør fra et usikkert valg.
1) Uklare leverancer
Rødt flag: Tilbuddet lover fx “en moderne hjemmeside” eller “en komplet app” uden en detaljeret opdeling.
Hvorfor det betyder noget: Uden en leveranceliste kan du ikke sammenligne leverandører, styre scope eller vide, hvad du betaler for. Uklarhed er dér, budgetoverløb opstår.
Spørg: “Kan I opliste alle leverancer (sider, templates, komponenter, integrationer) og definere, hvad ‘færdig’ betyder for hver?”
Sådan ser godt ud: En konkret oversigt (antal sidetyper, genbrugelige komponenter, CMS-content types, specifikke integrationer) samt acceptkriterier.
2) Hosting, ejerskab og adgang er uklart
Rødt flag: Det er uklart, hvem der ejer domæne, hostingkonto, kildekode, designfiler, analytics eller app store-konti.
Hvorfor det betyder noget: Ejerskab og adgang afgør, om du kan skifte leverandør, tage noget in-house eller blot fortsætte driften, hvis samarbejdet ændrer sig.
Spørg: “Dag 1 og dag 100-hvilke konti står i vores virksomheds navn, og hvordan ser overdragelse ud?”
Sådan ser godt ud: Din virksomhed ejer de kritiske konti, adgang er dokumenteret, og overdragelse er en normal (og testbar) del af leverancen.
3) Scope creep er uundgåeligt-men tilbuddet håndterer det ikke
Rødt flag: Mange “out of scope”-forbehold, men ingen praktisk ændringsproces.
Hvorfor det betyder noget: Krav ændrer sig. Spørgsmålet er ikke, om du får nye indsigter undervejs-men om processen forbliver fair, forudsigelig og hurtig.
Spørg: “Hvordan håndterer I ændringer-godkendelsesflow, typisk prisniveau, og hvem skriver under?”
Sådan ser godt ud: En enkel change-control: skriftligt estimat, påvirkning af tidsplan, tydeligt godkendelsespunkt og en fælles backlog over beslutninger.
4) Test, performance og tilgængelighed er mangelfuldt beskrevet
Rødt flag: QA er ét punkt, tilgængelighed nævnes ikke, og performance antages at “virke af sig selv”.
Hvorfor det betyder noget: Fejl og langsomme oplevelser er dyrere efter lancering. Tilgængelighed og grundlæggende kvalitet er lettere (og billigere), når det planlægges tidligt.
Spørg: “Hvad er jeres testplan (enheder/browsere), performance-budget og tilgængelighedsmål (fx WCAG 2.1 AA)?”
Sådan ser godt ud: En tydelig QA-proces, definerede minimumsbrowsere/enheder, performance-mål og en tilgængeligheds-tilgang, der passer til din målgruppe og risiko.
5) Tidsplan uden milepæle (eller uden dine afhængigheder)
Rødt flag: En slutdato uden faser, checkpoints og uden liste over, hvad kunden skal levere.
Hvorfor det betyder noget: Mange forsinkelser er afhængighedsforsinkelser: indhold, godkendelser, brand-assets, juridiske tekster, app store-login, stakeholder-signoff.
Spørg: “Hvilke milepæle er der, hvad skal I have fra os hvornår, og hvad sker der, hvis input er forsinket?”
Sådan ser godt ud: En milepælsplan (discovery, wireframes, design, build, QA, launch) og en gensidig liste over afhængigheder, der beskytter begge parter.
6) Support efter lancering og SLA’er er uklare
Rødt flag: “Support er muligt” uden svartider, overvågning, forventninger til sikkerhedsopdateringer eller release-rytme.
Hvorfor det betyder noget: Lancering er starten på virkeligheden: trafikspidser, edge cases, browseropdateringer, sårbarheder, OS-ændringer og brugerfeedback.
Spørg: “Hvilke supportniveauer tilbyder I, hvilke svartider, hvilke monitoreringsværktøjer, og hvad er jeres patch/release cadence?”
Sådan ser godt ud: Tydelige supportmuligheder (inkl. nødvej), monitorering/alarmer samt en aftalt proces for opdateringer og forbedringer.
En enkel måde at bruge tjeklisten på
- Send spørgsmålene i én mail til alle leverandører, du overvejer.
- Sammenlign klarheden i svarene-ikke kun prisen.
- Vær opmærksom på defensiv eller vag kommunikation. Stærke teams trives med tydelighed.
Hvis du vil vende nogle af punkterne-eller du ønsker en second opinion på et tilbud, du har fået-så tag gerne fat i Jensen Technologies. Vi hjælper gerne med et pragmatisk reality-check, så dit projekt får en rolig build og en sikker lancering.