Caira kan granska ditt avtal med 3 klick:

• Få förslag på ändringar och kommentarer tillagda direkt i din fil

• Skapa en e-postsammanfattning att skicka till den andra parten

Det tar mindre än 30 sekunder att registrera sig för en gratis testperiod. Inget kreditkort krävs: Starta din gratis testperiod

"Det fungerar på min maskin": Varför webbutvecklare behöver bättre avtal

Webbutvecklingsvärlden plågas av "förväntningsglappet."

Du levererar kod som uppfyller specifikationen. Kunden öppnar den på en iPhone 6 från 2014 och skriker "Det är trasigt!"

Du bygger CMS:et de bad om. De ringer dig sex månader senare och kräver att du fixar ett fel som orsakats av ett plugin de installerade.

Utveckling är logiskt. Kunder är känslostyrda. Ditt avtal är den enda bron mellan de två. Utan det skriver du frivilligt upp dig för livslång, obetald teknisk support.

Här är de juridiska buggarna du behöver täppa till i dina affärsvillkor.

1. "Svarta hålet" för webbläsarkompatibilitet

Scenariot: Du bygger en stilren React-webbplats. Den flyger fram i Chrome och Safari. Kundens vd öppnar den i Internet Explorer 11 på kontoret. Rutnätslayouten kraschar. De håller inne betalningen tills "det fungerar överallt."

Juridiska verkligheten:

"Det fungerar överallt" är tekniskt omöjligt. Utan en specifik lista kan en domstol tolka "fungerande webbplats" som "fungerar i vanliga affärsverktyg", vilket kan omfatta äldre webbläsare.

Lösningen:

En klausul om webbläsarstöd.

Var specifik. "Webbplatsen är utformad för att fungera i de två senaste versionerna av Chrome, Safari, Firefox och Edge. Kompatibilitet med äldre webbläsare (t.ex. IE11) undantas om inte detta uttryckligen avtalas i specifikationen."

2. Godkännandetestning ("lanseringsutlösaren")

Scenariot: Du blir klar med sajten. Du skickar länken. "Säg gärna vad du tycker."

Tystnad i 3 veckor.

Sedan: "Kan vi ändra typsnittet?"

Därefter tystnad i 2 veckor.

Sedan: "Kan vi faktiskt flytta logotypen?"

Du är 3 månader försenad och har inte fått betalt de sista 50 %.

Juridiska verkligheten:

Utan en definierad "acceptansperiod" är projektet i zombieläge. Det är varken klart eller inte klart.

Lösningen:

En klausul om "presumerat godkännande".

"Kunden har 7 dagar från leverans på sig att testa mjukvaran. Om inget specifikt 'Fel' (definierat som en krasch/kritiskt fel) rapporteras skriftligen inom 7 dagar, anses mjukvaran vara godkänd och slutsaldot förfaller till betalning."

Det tvingar dem att kontrollera den, eller betala dig.

3. Omfattningsglidning ("Bara en liten ändring")

Scenariot: Du lämnar offert för 5 sidor. Halvvägs igenom skickar kunden över texten. Det är 12 sidor. "Jag delade bara upp Om oss-sidan, det är väl ingen stor grej, eller hur?"

Det är en stor grej. Det påverkar navigeringslogiken, mobila menyer och tiden för innehållsregistrering.

Lösningen:

Sluta lämna offert för "En webbplats." Lämna offert för "Ett arbetsomfång."

• Strikt leverans: "5 st statiska sidor. 1 st kontaktformulär."

Ändringsklausulen: "Alla specifika önskemål utanför detta arbetsomfång debiteras enligt vår ordinarie timtaxa på £[X]. Utvecklingen pausas tills ändringen har godkänts."*

4. Vem äger koden? (IP-rättigheter)

Scenariot: Du använder ditt vanliga "Starter Theme" eller ett bibliotek med hjälpfunktioner du skrev för flera år sedan. Kunden blir osams med dig. De kräver "Full copyright assignment" av all kod.

Om du överlåter allt kan du juridiskt sett inte använda ditt eget starter theme för nästa kund. Du sålde "verktygen", inte bara "huset".

Lösningen:

Gör skillnad mellan "skräddarsydd kod" och "bakgrunds-IP".

"Utvecklaren överlåter upphovsrätten till den skräddarsydda designen och textlayouten till Kunden vid full betalning."*

"Utvecklaren behåller äganderätten till all 'bakgrunds-IP' (återanvändbara bibliotek/frameworks) och ger Kunden en evig, icke-exklusiv licens att använda dem för denna webbplats."*

5. Felrättning för "livstid"

Scenariot: Webbplatsen lanseras. Två år senare uppdateras WordPress. Sajten går sönder. Kunden ringer: "Du byggde den, du får fixa den."

Lösningen:

En garantiperiod.

"Vi erbjuder en 30-dagars garantiperiod efter lansering för att rätta buggar som fanns vid lanseringen. Alla problem som uppstår efter 30 dagar, eller orsakas av uppdateringar från tredje part (plugins/webbläsarändringar), faktureras som underhåll."

Varför avtalsgranskning är din dokumentation

Du kommenterar din kod. Du borde kommentera din affärsrelation.

AI-avtalsgranskning analyserar ditt utvecklaravtal. Den kontrollerar om du av misstag har lovat "ändamålsenlighet" (en hög juridisk ribba) i stället för "skälig omsorg och yrkesskicklighet." Den ser till att ditt "godkännandeflöde" är vattentätt. Den hjälper dig att leverera projektet och få betalt, utan teknisk skuld från tidigare versioner.

Friskrivning: Informationen i denna artikel är endast avsedd som allmän vägledning och är inte avsedd som professionell juridisk, finansiell, skattemässig eller medicinsk rådgivning.