Leverancer fra udviklere, som alle ikke-tekniske kunder bør insistere på
Når du investerer i en ny hjemmeside eller en mobilapp, køber du ikke kun et sæt funktioner. Du køber muligheden for at drive løsningen, forbedre den over tid og-hvis det bliver nødvendigt-skifte leverandør uden at din forretning går i stå.
Hos Jensen Technologies har vi i mange år leveret web- og appprojekter. De mest smertefulde problemer, vi bliver bedt om at løse efterfølgende, handler sjældent om “dårlig kode” i sig selv. De handler typisk om manglende leverancer: uklart ejerskab, ingen deploymentsbeskrivelse, utilgængelig kildekode eller en overdragelse, der reelt består af “skriv til os, hvis noget går i stykker.”
Her får du en praktisk checkliste, du kan bruge før du underskriver et tilbud, under leverancen og især ved overdragelse.
1) Adgang & ejerskab (gør det ikke til forhandling)
Hvis du ikke kontrollerer adgangen, kontrollerer du ikke produktet. Sørg for at du får (og tester) følgende:
- Adgang til domæneregistrator og kontrol over DNS (eller skriftlig bekræftelse på, at du ejer domænet og kan flytte det når som helst).
- Adgang til hosting/cloud (AWS/Azure/GCP/Vercel/Netlify m.fl.), helst under en konto ejet af din virksomhed.
- Adgang til kildekode-repository (GitHub/GitLab/Bitbucket) under din organisation, ikke et privat repo kun leverandøren kontrollerer.
- Admin-adgang til relevante værktøjer: CMS, analytics, tag manager, e-mail-service, betalingsløsning og tredjepartsintegrationer.
- Adgang til app stores (Apple Developer / Google Play Console) ved mobilapps-igen ejet af din virksomhed.
Praktisk tip: nøjes ikke med at modtage logins; planlæg en kort “adgangstjek”-session, hvor du logger ind og bekræfter at du kan se det, du har brug for.
2) En brugbar kodebase, ikke bare en zip-fil
Du bør kunne sætte projektet op igen om seks måneder uden gætterier.
- README-dokumentation der forklarer, hvordan man kører projektet lokalt, og hvordan det buildes.
- Dokumentation af miljøvariabler: hvilke værdier findes, hvad gør de, og hvor påvirkes de.
- Klarhed om dev/staging/production (også hvis staging er en enkel løsning). Du har brug for et sikkert sted at teste ændringer før kunderne påvirkes.
Når nogen siger: “Det virker kun på min computer,” er det ofte miljøopsætning og dokumentation, der mangler.
3) Designleverancer, du faktisk kan genbruge
Selv hvis du “er færdig med design,” vender du tilbage: nye kampagnesider, nye flows, nye features.
- Endelige designfiler (typisk Figma) med komponenter og styles-not kun eksportbilleder.
- Brand essentials: farver, typografi, spacing-regler, ikoner og korte brugsnoter.
- Liste over centrale brugerflows (sign-up, checkout, booking osv.), så fremtidigt arbejde ikke utilsigtet ødelægger dem.
4) Testevidens (ikke bare “vi har testet”)
Test bør ikke være en sort boks. Bed om tydelig dokumentation for, hvad der er testet-og hvad der ikke er.
- Smoke test-checkliste til launch day (kritiske flows der skal virke).
- Automatiserede tests hvor det giver mening (unit/integration/end-to-end). Selv en lille startpakke hjælper mod regressions.
- Support-erklæring for browsere/enheder: hvad er inkluderet, hvad er ikke, og hvorfor.
5) Deployment, rollback og “hvor kigger vi når noget fejler”
Mange overdragelser fejler i det øjeblik, du har brug for tempo: en produktionsfejl, en kampagne, en hurtig post-launch ændring.
- Trin-for-trin deployment-proces: hvem gør hvad, med links til pipelines eller scripts.
- Rollback-procedure der genskaber en kendt, stabil version.
- Logning og monitorering: hvor logs findes, hvilke alerts der er sat op, og hvad “normal drift” ser ud.
6) Sikkerhed og compliance-basis
Du behøver ikke en juridisk afhandling, men du skal have klarhed.
- SSL/TLS aktiveret og relevante sikkerhedsindstillinger hvor det er passende.
- Roller og rettigheder dokumenteret (hvem kan deploye, se data, administrere brugere osv.).
- Noter om datahåndtering: hvilke persondata indsamles, forventet retention og backup-politik.
7) Vedligeholdelsesoverdragelse (så løsningen forbliver sund)
Launch er starten på drift, ikke slutningen på udvikling. En god leverandør gør de løbende ansvar tydelige.
- Plan for opdateringer (månedligt eller kvartalsvist) og hvordan sårbarheder håndteres.
- Backups: frekvens, retention og bekræftelse på at restores er testet.
- Overvågning/uptime-alarmer og en klar modtagerliste.
- En “første uge efter launch”-plan for bug-triage, smårettelser og performance-tuning.
Enkle røde flag i tilbud
- “Vi hoster under vores konto for nemheds skyld” uden eksplicit ejerskab og vilkår for eksport/flytning.
- Ingen nævnelse af dokumentation, tests eller deployment-kun features og design.
- Utydelig vedligeholdelse som “efter behov” uden scope, svartider eller hvad der er ekskluderet.
- Ingen leveranceliste udover “hjemmeside/app,” hvilket gør accept subjektiv og rodet.
En god overdragelse føles næsten kedelig: adgang er på plads, dokumentation findes, og en anden leverandør kan tage over, hvis dine behov ændrer sig.
Hvis du vil drøfte dit projekt, kan Jensen Technologies hjælpe dig med at definere de rigtige leverancer til din stack (web, mobil og AI-baserede produkter), gennemgå tilbud eller sikre en ren overdragelsesproces. Tag gerne fat i os, hvis du vil vende det-eller har brug for hjælp til at omsætte det til din forretning.