Tjekliste til aftale om webudvikling
De fleste tvister i webprojekter handler ikke om kvalitet, men om forventninger der aldrig blev skrevet ned. En aftale, der navngiver de rigtige ting, forebygger næsten dem alle, og det tager en time at læse den.
Denne guide gennemgår, hvad der bør stå i den, hvorfor hvert punkt findes, og hvilke klausuler du bør insistere på i tvivlstilfælde.
Omfang: den del der skaber flest tvister#
«Bygge siden» er ikke et omfang. Dette bør stå udtrykkeligt.
- Antal unikke skabeloner, ikke antal sider. Halvtreds sider på fire skabeloner er et lille projekt.
- Hvad der er med: design, byg, indtastning af indhold, migrering, integrationer, test.
- Hvad der ikke er med — det er den vigtigste sætning i hele aftalen.
- Hvem der skriver teksterne, og hvem der leverer billederne.
- Antal designrunder og hvad der tæller som en runde.
- Understøttede browsere og enheder samt det forudsatte tilgængelighedsniveau.
- Ydeevnemål hvis de er vigtige, udtrykt i målbare værdier.
- Hvilke sprog, og hvem der leverer oversættelserne.
En leverandør, der af egen drift skriver ned hvad der ikke er med, har som regel været gennem en omfangstvist — hvilket er et godt tegn.
Ejerskab, adgange og exit#
Disse punkter føles abstrakte, indtil du vil skifte leverandør, og så er de de eneste, der tæller.
| Punkt | Hvad aftalen skal sige |
|---|---|
| Kildekode | Overgår i sin helhed til dig ved slutbetaling |
| Designfiler | Også dine, inklusive kildefilerne |
| Domæne | Registreret i din virksomheds navn, med din adgang |
| Hosting | På din konto, eller overførbar på anmodning |
| Tredjepartskonti | Analytics, mail, betaling — i dit navn |
| Tredjepartslicenser | Hvilke, og hvem der betaler dem bagefter |
| Overdragelse | Dokumentation og overdragelse af adgange ved ophør |
| Porteføljebrug | De må vise det; rimeligt at tillade |
Domæne og hosting i leverandørens navn er den hyppigste måde, virksomheder bliver låst fast. Tjek det før underskrift, ikke ved exit.
Betaling, frister og ændringer#
Disse tre hænger sammen: hvem betaler hvornår, hvad sætter datoen, og hvad sker der, når omfanget vokser.
- Betaling i etaper koblet til leverancer, ikke til kalenderdatoer.
- En udbetaling er normal; fuld forudbetaling er ikke.
- En slutbetaling efter levering, stor nok til at betyde noget.
- Gensidige afhængigheder: tidsplanen forskydes, hvis du leverer tekster sent, og det bør stå der.
- En ændringsprocedure: hver tilføjelse får et skriftligt estimat, før arbejdet begynder.
- Timepris for arbejde uden for omfanget, fastlagt på forhånd.
- Hvad der sker ved forsinkelse fra begge sider — ikke kun din.
- Ophørsbetingelser: hvordan man afslutter, og hvad der så betales og overdrages.
Garanti, drift og ansvar#
Den del der handler om perioden efter lanceringen, og den der oftest mangler.
| Punkt | Rimelig aftale |
|---|---|
| Rettelsesperiode | Tredive til halvfems dages gratis rettelse |
| Hvad en fejl er | Virker ikke som aftalt — ikke: nyt ønske |
| Svartid | Hverdage ved almindelige henvendelser, hurtigere ved nedbrud |
| Drift | Separat aftale, med udtrykkelig opremsning |
| Sikkerhedssårbarheder | Hvem retter, inden for hvilken frist |
| Persondata | Databehandleraftale hvis de behandler data |
| Ansvar | Begrænsning til aftalens værdi er sædvanlig |
| Tvister | Hvilken lov, hvilken domstol — kort men til stede |
Skellet mellem «fejl» og «nyt ønske» skaber mest friktion efter lanceringen. Én sætning der definerer det, sparer måneders diskussion.
Ofte stillede spørgsmål
Har jeg brug for en aftale ved et lille projekt?
Ja, om end kort. To sider der fastlægger omfang, pris, betalingstidspunkter, ejerskab og hvad der ikke er med, dækker størstedelen af det, der går galt. De små projekter er netop dem, hvor ingen skriver noget ned, og hvor omfanget derfor ubemærket fordobles.
Hvad hvis leverandøren vil beholde ejerskabet af koden?
Det er en grund til at spørge videre. Ved skræddersyet kode bør koden være din efter betaling. Undtagelsen er en egen platform eller et eget framework hos leverandøren — så får du en licens frem for ejerskab, hvilket kan være rimeligt, forudsat at aftalen siger, hvad der sker hvis du forlader, eller hvis de lukker.
Hvor meget skal jeg betale forud?
En udbetaling på en fjerdedel til en tredjedel er sædvanlig og rimelig. Fuld forudbetaling er ikke, fordi det fjerner enhver tilskyndelse til at færdiggøre. Kobl resten til leverancer, du kan se — godkendt design, leveret byg, side live — frem for til kalenderdatoer, der kan flytte sig.
Hvad skal en garantiperiode dække?
Fejl i det leverede: ting der ikke virker som aftalt. Ikke: nye ønsker, ændringer forårsaget af en browseropdatering måneder senere, eller problemer forårsaget af dine egne ændringer. Tredive til halvfems dage er sædvanligt. Sørg for at aftalen definerer, hvad en fejl er, ellers diskuterer du det på det værst tænkelige tidspunkt.
aftale webudviklingkontrakt hjemmesideomfang webprojektejerskab kildekodebestille hjemmesidegaranti hjemmeside
