Det här ska stå i avtalet med din utvecklingsbyrå

Ett bra avtal märks inte när allt rullar på – det märks när projektet gnisslar. Då avgör det vem som betalar för förseningen, vem som äger koden och hur ni skiljs åt utan att produkten tar skada. Här är de femton punkter som bör finnas med, skrivna för dig som beställer utan egen bolagsjurist.

Leverans och betalning (punkt 1–5)

1. Leveransdefinition. Skriv vad som ska levereras i funktionella termer: vilka flöden, vilka plattformar, vilken miljö. Hänvisa gärna till en bilaga med kravlista eller user stories – “en app” är ingen leveransdefinition.
2. Acceptanskriterier och acceptansperiod. Definiera hur ni avgör att en leverans är godkänd: vem som testar, mot vilka kriterier och hur lång tid ni har på er. Utan acceptansperiod blir “klart” en åsiktsfråga.
3. Betalningsplan kopplad till milstolpar. Betala mot godkända delleveranser i stället för mot kalendermånader. Det håller incitamenten rätt: byrån får betalt när något fungerar, inte när tiden har gått.
4. Ändringshantering. Nya önskemål kommer alltid. Reglera hur de prissätts, godkänns och dokumenteras innan de byggs – annars blir varje tillägg en potentiell konflikt om vad som “ingick”.
5. Bemanning och nyckelpersoner. Namnge nyckelroller och reglera hur byten hanteras. Du köper delvis specifika människors kompetens, inte bara en logotyp.

Ansvar, viten och avslut (punkt 6–10)

6. Ansvarsfördelning. Lista vad du som beställare ansvarar för: beslut, innehåll, testdata, tillgång till era system. Många förseningar beror på att beställarens åtaganden aldrig skrevs ner.
7. Viten vid försening. Ett rimligt vite ger byrån skäl att prioritera er. Koppla det till förseningar som byrån faktiskt råder över, och håll nivån proportionerlig mot avtalets värde.
8. Ansvarsbegränsning och försäkring. Byrån kommer att vilja begränsa sitt ansvar, ofta till avtalets värde. Det är normalt – men kontrollera att ansvarsförsäkring finns och vad den täcker.
9. Uppsägning och exit. Reglera uppsägningstid, vad som levereras vid avslut och vad avslutet får kosta. Ett bra avtal gör det odramatiskt att skiljas.
10. Tvistelösning. Bestäm i förväg hur oenigheter hanteras: förhandling, medling, domstol eller skiljeförfarande. Skiljeförfarande går snabbt men kan bli dyrt för mindre bolag.

Rättigheter till kod, design och data (punkt 11–15)

11. Äganderätt till kod och design. Huvudregeln i svensk rätt är att upphovsrätten stannar hos den som skapat verket om inget annat avtalats. Skriv in att alla rättigheter övergår till er vid betalning.
12. Öppen källkod och tredjepartslicenser. Modern utveckling bygger på öppen källkod. Kräv att byrån redovisar vilka licenser som används och att inget hindrar er kommersiella användning.
13. Data och personuppgifter. Behandlar byrån personuppgifter för er räkning krävs ett personuppgiftsbiträdesavtal enligt GDPR. Reglera också var data lagras och hur den lämnas tillbaka vid avslut.
14. Skydd vid konkurs. Säkerställ löpande faktisk tillgång till källkoden – egen kopia av kodförrådet, egna konton hos molnleverantören – eller avtala om källkodsdeponering. Går byrån i konkurs är ett avtalat ägande utan tillgång till koden en klen tröst.
15. Dokumentation och överlämning. Avtala att dokumentation, arkitekturbeskrivning och driftsinstruktioner ingår i leveransen, så att en annan leverantör kan ta över utan att börja om.

Scenario: betalningsplanen som räddar projektet

Säg att ni beställer en kundportal för 900 000 kr. I stället för tre fasta fakturor delar ni upp summan i sex milstolpar à 150 000 kr, var och en med definierade acceptanskriterier. Vid milstolpe tre upptäcker ni att inloggningen inte fungerar som avtalat. Eftersom betalningen är kopplad till godkännande pausas fakturan tills felet är löst – och diskussionen handlar om kriterierna ni skrev ner, inte om vems minnesbild som gäller.

Det är skillnaden mellan ett avtal som ligger i en mapp och ett avtal som styr projektet.

Så använder du checklistan

Gå igenom punkterna innan du skriver på, och be byrån förklara varje punkt den vill stryka. En seriös leverantör blir inte nervös av tydliga avtal – tvärtom. Vi på Weapp går alltid igenom leveransdefinition, ägande och exit före projektstart, eftersom ett otydligt avtal är en dålig start på ett långt samarbete. Vill du ha en andra åsikt på ett avtalsförslag eller prata igenom ett kommande projekt? Hör av dig.