Sjekkliste for avtale om webutvikling
De fleste tvister i nettprosjekter handler ikke om kvalitet, men om forventninger som aldri ble skrevet ned. En avtale som navngir de riktige tingene, forebygger nesten dem alle, og det tar en time å lese den.
Denne guiden går gjennom hva som bør stå i den, hvorfor hvert punkt finnes, og hvilke klausuler du bør insistere på i tvilstilfeller.
Omfang: den delen som skaper flest tvister#
«Bygge siden» er ikke et omfang. Dette bør stå uttrykkelig.
- Antall unike maler, ikke antall sider. Femti sider på fire maler er et lite prosjekt.
- Hva som er med: design, bygging, innlegging av innhold, migrering, integrasjoner, testing.
- Hva som ikke er med — det er den viktigste setningen i hele avtalen.
- Hvem som skriver tekstene, og hvem som leverer bildene.
- Antall designrunder og hva som teller som en runde.
- Støttede nettlesere og enheter samt det forutsatte tilgjengelighetsnivået.
- Ytelsesmål om de er viktige, uttrykt i målbare verdier.
- Hvilke språk, og hvem som leverer oversettelsene.
En leverandør som av eget initiativ skriver ned hva som ikke er med, har som regel vært gjennom en omfangstvist — noe som er et godt tegn.
Eierskap, tilganger og exit#
Disse punktene føles abstrakte til du vil bytte leverandør, og da er de de eneste som teller.
| Punkt | Hva avtalen skal si |
|---|---|
| Kildekode | Overgår i sin helhet til deg ved sluttbetaling |
| Designfiler | Også dine, inkludert kildefilene |
| Domene | Registrert i din bedrifts navn, med din tilgang |
| Drift | På din konto, eller overførbar på forespørsel |
| Tredjepartskontoer | Analyse, e-post, betaling — i ditt navn |
| Tredjepartslisenser | Hvilke, og hvem som betaler dem etterpå |
| Overdragelse | Dokumentasjon og overdragelse av tilganger ved opphør |
| Porteføljebruk | De kan vise det; rimelig å tillate |
Domene og drift i leverandørens navn er den vanligste måten bedrifter blir låst fast. Sjekk det før signering, ikke ved exit.
Betaling, frister og endringer#
Disse tre henger sammen: hvem betaler når, hva setter datoen, og hva skjer når omfanget vokser.
- Betaling i etapper knyttet til leveranser, ikke til kalenderdatoer.
- Et forskudd er normalt; full forskuddsbetaling er ikke.
- En sluttbetaling etter levering, stor nok til å bety noe.
- Gjensidige avhengigheter: tidsplanen forskyves om du leverer tekster sent, og det bør stå der.
- En endringsprosedyre: hvert tillegg får et skriftlig estimat før arbeidet begynner.
- Timepris for arbeid utenfor omfanget, fastsatt på forhånd.
- Hva som skjer ved forsinkelse fra begge sider — ikke bare din.
- Opphørsbetingelser: hvordan man avslutter, og hva som da betales og overdras.
Garanti, drift og ansvar#
Den delen som handler om perioden etter lanseringen, og den som oftest mangler.
| Punkt | Rimelig avtale |
|---|---|
| Rettingsperiode | Tretti til nitti dagers gratis retting |
| Hva en feil er | Virker ikke som avtalt — ikke: nytt ønske |
| Responstid | Virkedager ved vanlige henvendelser, raskere ved havari |
| Drift | Separat avtale, med uttrykkelig oppregning |
| Sikkerhetssårbarheter | Hvem retter, innen hvilken frist |
| Persondata | Databehandleravtale om de behandler data |
| Ansvar | Begrensning til avtalens verdi er vanlig |
| Tvister | Hvilken lov, hvilken domstol — kort men til stede |
Skillet mellom «feil» og «nytt ønske» skaper mest friksjon etter lanseringen. Én setning som definerer det, sparer måneders diskusjon.
Ofte stilte spørsmål
Trenger jeg en avtale ved et lite prosjekt?
Ja, om enn kort. To sider som fastsetter omfang, pris, betalingstidspunkter, eierskap og hva som ikke er med, dekker størstedelen av det som går galt. De små prosjektene er nettopp de der ingen skriver noe ned, og der omfanget derfor umerkelig dobles.
Hva om leverandøren vil beholde eierskapet til koden?
Det er en grunn til å spørre videre. Ved skreddersydd kode bør koden være din etter betaling. Unntaket er en egen plattform eller et eget rammeverk hos leverandøren — da får du en lisens snarere enn eierskap, noe som kan være rimelig, forutsatt at avtalen sier hva som skjer om du forlater, eller om de legger ned.
Hvor mye skal jeg betale på forhånd?
Et forskudd på en fjerdedel til en tredjedel er vanlig og rimelig. Full forskuddsbetaling er ikke, fordi det fjerner enhver drivkraft til å fullføre. Knytt resten til leveranser du kan se — godkjent design, levert bygg, side live — snarere enn til kalenderdatoer som kan flytte seg.
Hva skal en garantiperiode dekke?
Feil i det leverte: ting som ikke virker som avtalt. Ikke: nye ønsker, endringer forårsaket av en nettleseroppdatering måneder senere, eller problemer forårsaket av dine egne endringer. Tretti til nitti dager er vanlig. Sørg for at avtalen definerer hva en feil er, ellers diskuterer du det på verst tenkelige tidspunkt.
avtale webutviklingkontrakt nettsideomfang nettprosjekteierskap kildekodebestille nettsidegaranti nettside
