Co powinna zawierać brytyjska umowa developera freelance?

Brytyjska umowa developera freelance powinna nazwać strony, zakres prac (SOW) albo backlog, odbiór, środowiska, kontrolę zmian, wynagrodzenie, kto jest właścicielem kodu, praktykę pracy IR35, limit odpowiedzialności oraz co się dzieje, jeśli anulują albo płacą pozamówienieZamówienie (purchase order) to pisemne żądanie kupującego nabycia wymienionych towarów albo usług na podanych warunkach. Może utworzyć umowę, jeśli jest ofertą, którą dostawca akceptuje. Gdy każda strona strzela własnymi warunkami standardowymi, masz battle of the forms. Umowa ramowa o świadczenie usług powinna mówić, że jej warunki biją drobny druk każdego PO.Więcej w słowniku terminie. Podpisz ją przed pierwszym commitem.

Ta strona dotyczy najpierw England and Wales. Prawo autorskie na podstawie Copyright, Designs and Patents Act 1988 (ustawy o prawie autorskim, wzorach i patentach z 1988 r.) obowiązuje w całym Zjednoczonym Królestwie. Off-payroll working (IR35) to brytyjska reguła podatkowa. Droga pozwu o zapłatę niezapłaconej faktury to procedura z England and Wales w Klient nie płaci faktury freelancera.

Nie ma szablonu umowy na rozwój oprogramowania w Contracts.io. Zacznij od umowy z freelancerem albo umowy niezależnego wykonawcy. Budowa strony może zacząć od budowy strony. Powtarzana praca zawiesza zakres prac pod umową o świadczenie usług. Miesięczny slot na opiekę siedzi na umowie o stałą współpracę. Praca silnie strategiczna może zacząć od umowy konsultingowej. Jeśli udostępniasz nieopublikowany kod, zanim umowa jest podpisana, obok niej stoi wzajemna umowa o zachowaniu poufności (NDA). Umowy dla developerów to krótsza strona dla tej grupy. Co powinna zawierać brytyjska umowa na web design? to siostra pod zlecenie stron.

Dziesięć bloków robi robotę:

Zaliczka 40% to przykład, nie stawka ustawowa. Wpisz liczby, których naprawdę używasz.

Co zawiera umowa freelancera lub wykonawcy porównuje szablony. Jak napisać umowę to ogólna lista kontrolna. Ta strona to wersja dla developera.

Nie wysyłaj mailem pliku Word i nie licz, że v4_final to ten, który podpisali. Obie strony powinny edytować i podpisać elektronicznie jeden wspólny projekt.

Ty, chyba że go przeniesiesz. CDPA 1988 s.11 czyni autora pierwszym właścicielem praw autorskich do pracy freelance. Przeniesienie nie jest skuteczne, jeśli nie jest na piśmie, podpisane. Zapłacenie faktury nie przesuwa tytułu. Przenieś kod na zamówienie po pełnej zapłacie. Licencjonuj swoje biblioteki i narzędzia.

CDPA 1988 s.11 to reguła pierwszego właściciela. Wyjątek dla pracowników z s.11(2) dotyczy pracowników, nie developera na umowie o świadczenie usług (contract for services). Zlecenie buildu nie przesuwa praw autorskich. Jeśli umowa milczy, sąd może uznać ograniczoną licencję dorozumianą na cel zamówienia. To nie jest własność. Milczenie to sposób, w jaki klient zabiera repo do innego studia i twierdzi, że myślał, że je kupił.

CDPA 1988 s.90 to reguła przeniesienia. Przeniesienie praw IPprzeniesienie praw IPPrzeniesienie praw IP to przekazanie własności pracy, tak że należy ona do klienta, a nie do osoby, która ją wykonała.Więcej w słowniku musi być na piśmie, podpisane przez ciebie albo kogoś podpisującego w twoim imieniu. LicencjalicencjaLicencja to zgoda na korzystanie z pracy w uzgodniony sposób, bez odbierania własności osobie, która ją wykonała.Więcej w słowniku to zgoda na korzystanie z utworu. To nie jest przeniesienie własności. Zobacz licencję IP a cesjęlicencja IP a cesjaCesja IP przenosi własność prawa autorskiego albo innej własności intelektualnej. Licencja to zgoda na używanie; autor nadal jest właścicielem. W England & Wales nie ma reguły work-made-for-hire jako pierwszego właściciela u freelancerów: Copyright, Designs and Patents Act 1988 s.11. Cesja musi być na piśmie i podpisana: s.90. Powiedz, którą masz na myśli i kiedy następuje.Więcej w słowniku.

Amerykański nagłówek „work for hire„work for hire”Work for hire to określenie, częste w umowach w stylu amerykańskim, oznaczające, że klient jest od początku traktowany jako autor i właściciel pracy.Więcej w słowniku” tej roboty w England and Wales nie wykonuje. Zobacz work for hire. Zapisz przeniesienie albo licencję zwykłymi słowami.

Trzymaj cztery stosy:

• Kod na zamówienie — nazwane rezultaty. Przenoszone albo licencjonowane po pełnej zapłacie.
• Twoje biblioteki — komponenty, CLI, wcześniejsze startery. Licencjonowane na to zlecenie, nie przenoszone.
• Open-source — komponenty osób trzecich na własnych licencjach. Nie możesz ich przenieść.
• Notatki robocze — spike’i, odrzucone branche, lokalne narzędzia. Nie wliczone, chyba że wycenione.

W umowie o świadczenie usług między przedsiębiorcami obowiązuje dorozumiany warunek, że wykonasz usługę z należytą starannością i umiejętnością — Supply of Goods and Services Act 1982 (ustawa o dostawie towarów i usług z 1982 r.) s.13. Ten warunek nie przesuwa praw autorskich.

Przykład

Po otrzymaniu pełnej zapłaty Developer przenosi na Klienta prawa autorskie do kodu na zamówienie w Rezultatach. Do tego czasu Klient nie ma licencji na kopiowanie, publikowanie, publiczne udostępnianie ani adaptację, chyba że Developer zgodzi się na piśmie. Wcześniej istniejące materiały, biblioteki, narzędzia i komponenty open-source osób trzecich zostają przy Developerze albo ich licencjodawcach i są licencjonowane wyłącznie jako część Rezultatów.

Prostym językiem: są właścicielami kodu na zamówienie, gdy zapłacą. Nie mogą wypuszczać niezapłaconej pracy. Twój starter kit i biblioteki innych zostają na własnych warunkach.

Zapisz to w klauzuli przeniesienia praw własności intelektualnej. Jeśli wypuszczają niezapłaconą pracę, zobacz Klient korzysta z Twojej pracy bez zapłaty.

Trzymaj trzy stosy. Kod na zamówienie jest przenoszony albo licencjonowany po pełnej zapłacie. Twoje wcześniej istniejące biblioteki i narzędzia zostają twoje i są licencjonowane na to zlecenie. Komponenty open-source zostają na własnych licencjach — ujawniaj je. Nie możesz przenieść licencji, której nie masz.

Działająca klauzula o osobach trzecich odpowiada na cztery rzeczy:

• Co. Nazwane biblioteki, które napisałeś wcześniej, starter kit, pakiety osób trzecich, których zlecenie potrzebuje.
• Kto jest właścicielem licencji. Twój kod zostaje twój. Open-source zostaje na warunkach opublikowanych przez autorów. Klient nie kupuje tych praw autorskich, płacąc tobie.
• Co ujawniasz. Listę komponentów osób trzecich i licencję, którą każdy już niesie. Nie wymyślaj nazwy licencji. Skopiuj nazwę z pakietu.
• Co gwarantujesz. Że nie wrzucisz materiału, do którego nie masz prawa. Nie że upstreamowy pakiet zostanie kompatybilny na zawsze.

CDPA 1988 s.90 to reguła dla twoich praw autorskich. Nie przesuwa licencji open-source osoby trzeciej. Trzymaj to jako wcześniej istniejące materiały albo jako licencje osób trzecich, nie jako przeniesione finały.

Jeśli udostępniasz nieopublikowane repo, zanim umowa jest podpisana, obok dokumentu buildu stoi wzajemna umowa o zachowaniu poufności (NDA).

Przykład

Wcześniej istniejące materiały, biblioteki i narzędzia pozostają przy Developerze i są licencjonowane Klientowi wyłącznie w zakresie potrzebnym do korzystania z Rezultatów. Komponenty open-source osób trzecich pozostają na własnych licencjach. Developer ujawni te komponenty i licencję, którą każdy już niesie. Developer nie przenosi tych licencji. Developer gwarantuje, że według wiedzy Developera Rezultaty nie zawierają materiału osoby trzeciej, który Developer wprowadził bez prawa do tego.

Prostym językiem: dostają licencję na użycie twojego zestawu w tym produkcie. Nie kupują twojego przybornika. Open-source zostaje na licencji, którą już ma. Mówisz, czego użyłeś.

Zapisz zakres prac (SOW) albo nazwany backlog, jak wygląda „gotowe”, do jakich środowisk dostarczasz i jak wyceniana jest zmiana. „Produkt” to nie lista. Dodatkowe epiki to kontrola zmian, nie uprzejmość. Podpisz SOW przed pierwszym commitem.

Działający zakres odpowiada na pięć rzeczy:

• Lista. Nazwane epiki, story albo data zamrożenia backlogu. Checkout to nie marketplace. API to nie UI admina.
• Odbiór. Pisemne testy, demo na stagingu, okno wad. Wada to niezgodność z SOW. „Mamy nowy pomysł” to zmiana.
• Środowiska. Kto hostuje dev, staging i production. Kto trzyma konta w chmurze. Kto może promować na production.
• Co jest poza. Druga aplikacja, płatne reklamy, treści, stały dyżur — chyba że są na liście w środku.
• Kontrola zmian. Nowy epik jest wyceniany i podpisywany najpierw. Zobacz Klient dokłada pracę i kontrolę zmian.

Limit popraweklimit poprawekLimit poprawek określa, ile rund zmian wlicza się w wynagrodzenie, zanim dodatkowa praca zostanie wyceniona.Więcej w słowniku szlifuje uzgodniony ekran. To nie jest drugi produkt bez opłaty.

Jeśli umowa mówi, że zmiany muszą być na piśmie i podpisane, „tak” na Slacku nie przepisuje zlecenia. Rock Advertising Ltd v MWB Business Exchange Centres Ltd [2018] UKSC 24 nadaje tej klauzuli skutek.

Przykład

Rezultatami są pozycje z Załącznika 1. Developer zawiadomi, że Rezultat jest gotowy w środowisku staging. Klient przetestuje go w ciągu 10 dni roboczych i przyjmie na piśmie albo wskaże wady względem Załącznika 1. Milczenie po tym terminie liczy się jako odbiór. Dalsza praca, dodatkowe epiki albo praca poza Załącznikiem 1 są wyceniane i uzgadniane na piśmie przed rozpoczęciem pracy. Developer dostarcza na staging. Promocja na production jest krokiem Klienta, chyba że Załącznik 1 stanowi inaczej.

Prostym językiem: dostają nazwany backlog. Dziesięć dni roboczych na szturchanie stagingu. Jeśli nic nie powiedzą, jest odebrane. Nowy epik to nowe wynagrodzenie. Oni wciskają przycisk production, chyba że i to wyceniłeś.

Stali klienci często siedzą pod umową o świadczenie usług plus zakresem prac na każde zlecenie. Strona marketingowa może zacząć od budowy strony.

Stawka dzienna płaci za czas. Stała cena i etapy płacą za nazwane rezultaty. Nie ma domyślnego brytyjskiego prawa do zatrzymania zaliczki ani pobrania kill fee — obie strony muszą uzgodnić kwoty. Zapisz zaliczkę przed startem pracy. Wobec klienta biznesowego opłata nie może być karą.

Wybierz jeden kształt wynagrodzenia i zapisz go:

Zaliczka 30–50% przy podpisaniu, z pracą wstrzymaną, dopóki nie wpłynie, to zwykły kształt freelance. Kill fee stoi obok: wykonana praca plus wskazany udział pozostałego wynagrodzenia, jeśli anulują bez podania przyczyny. Zobacz anulowanie i opłatę za anulowanie oraz warunki płatności.

Wobec klienta biznesowego uzgodniona opłata za anulowanie, która faktycznie jest kwotą przy naruszeniu, nie może być karą. Cavendish Square Holding v Makdessi [2015] UKSC 67 pyta, czy obowiązek wtórny nakłada uszczerbek rażąco nieproporcjonalny do uzasadnionego interesu w wykonaniu umowy. Powiąż kwotę z zarezerwowanym czasem, poniesionymi kosztami i odrzuconymi innymi zleceniami. Płaskie 100% od dnia podpisania, bez związku z tymi interesami, to kształt, który wygląda jak kara.

Dłuższy podział to Klient zrezygnował: czy możesz zatrzymać zaliczkę?.

Przykład

Klient zapłaci 40% Wynagrodzenia przy podpisaniu i resztę przy odbiorze Rezultatów. Developer nie rozpocznie, dopóki nie otrzyma pierwszej kwoty. Jeśli Klient anuluje bez podania przyczyny po rozpoczęciu pracy, Klient zapłaci za dotychczas wykonaną pracę oraz opłatę za anulowanie w wysokości 25% pozostałego Wynagrodzenia. Już zapłacone kwoty są zaliczane na tę sumę. Własność intelektualna w pracy nie w pełni zapłaconej zostaje przy Developerze.

Prostym językiem: 40% wpływa, zanim zaczniesz. Jeśli odwołają, gdy już pracujesz, płacą za to, co zrobiono, plus ćwierć tego, co zostało. Nie są właścicielami niezapłaconego kodu.

Te procenty to przykłady, nie stawka ustawowa. Przy zleceniu na stawkę dzienną zapisz stawkę, minimum dni i to, że odwołane dni już trzymane w kalendarzu i tak są należne, jeśli odrzuciłeś inną pracę.

Zapisz krótki termin płatności, prawo wstrzymania, gdy faktura jest przeterminowana, i to, że żadna licencja ani przeniesienie nie działa, dopóki nie zapłacą w całości. Wobec brytyjskiego klienta biznesowego odsetki ustawowe od opóźnionej płatności handlowej wynoszą 8% powyżej stopy bazowej Bank of England plus stałą kwotę na odzyskanie. Nie podajemy aktualnej stopy bazowej.

Warunki płatności powinny nazwać:

• kiedy wychodzą faktury — przy podpisaniu, w punkcie środkowym, przy odbiorze
• ile dni na zapłatę — net 14 albo net 30Net 30Net 30 oznacza, że klient ma 30 dni od daty faktury na zapłatę.Więcej w słowniku wygrywa z otwartym „gdy zakupy następnym razem puszczą”
• prawo wstrzymania, gdy niesporna faktura jest przeterminowana, w tym prawo nie promować na production
• że prawa autorskie albo licencja na korzystanie z pracy przechodzą dopiero po pełnej zapłacie

Przy kwalifikującym się długu między przedsiębiorcami Late Payment of Commercial Debts (Interest) Act 1998 (ustawa o odsetkach od opóźnionych płatności handlowych z 1998 r.) ustala odsetki ustawowe. GOV.UK o opóźnionych płatnościach handlowych podaje stopę jako 8% plus stopa bazowa Bank of England. Gdy te odsetki biegną, należna jest też stała kwota na odzyskanie: £40 poniżej £1,000, £70 od £1,000 do poniżej £10,000 i £100 od £10,000 wzwyż, plus uzasadnione koszty odzyskania niepokryte tą kwotą. Zobacz odsetki za opóźnienie w płatności. Ustawa z 1998 r. nie dotyczy klienta będącego konsumentem.

Stopa umowna, jeśli ją wskażesz, to stopa, na którą wskazujesz zamiast ustawowej. Nie wymyślaj kwoty, która nie ma związku z ustawą ani z dokumentem.

Przykład

Każda niesporna faktura jest płatna w ciągu 14 dni od jej daty. Developer może wstrzymać pracę i nie jest zobowiązany przekazać dostępu do production, gdy jakakolwiek niesporna faktura jest przeterminowana o więcej niż 7 dni. Prawa autorskie oraz wszelka licencja na korzystanie z Rezultatów przechodzą na Klienta wyłącznie po zapłacie w całości. Do tego czasu Klient nie ma prawa kopiować, publikować, publicznie udostępniać ani adaptować Rezultatów.

Prostym językiem: mają dwa tygodnie na zapłatę. Po tygodniu spóźnienia praca staje, a production zostaje zamknięta. Nie są właścicielami kodu i nie mogą go wypuszczać, dopóki nie zapłacą.

Kolejność monitowania — pisemne wezwanie, letter before action, pozew o zapłatę — to Klient nie płaci faktury freelancera.

Żadna etykieta nie rozstrzyga podatku. Od 6 kwietnia 2021 r. organy publiczne oraz średni albo duzi klienci muszą wydać Status Determination Statement. Mali klienci z sektora prywatnego zostawiają tę decyzję twojej spółce. Zapisz autonomię, rzeczywiste zastępstwo i wzajemność tak, by pasowały do tego, jak naprawdę pracujesz.

Zasady off-payroll working siedzą w ITEPA 2003. Od 6 kwietnia 2021 r., gdy usługi są świadczone przez pośrednika na rzecz organu publicznego albo średniego lub dużego klienta z powiązaniem z UK, klient musi wydać Status Determination Statement. To oświadczenie musi wskazać, czy pracownik byłby pracownikiem, gdyby zatrudniono go bezpośrednio, wyjaśnić powody i zostać sporządzone z należytą starannością.

Gdy usługi są świadczone przez pośrednika na rzecz osoby, która nie jest organem publicznym i która kwalifikuje się jako mała w danym roku podatkowym, stosuje się Rozdział 8. Spółka kwalifikuje się jako mała w roku podatkowym, jeśli reżim małych spółek z Companies Act 2006 (ustawy o spółkach z 2006 r.) dotyczy jej ostatniego roku obrotowego istotnego dla tego roku podatkowego. Spółka pracownika decyduje wtedy o statusie.

Co umowa nadal może zrobić, to opisać relację pracy rzetelnie:

• Autonomia. Ty decydujesz, jak dostarczyć uzgodniony rezultat. Klient ustala rezultat, terminy i rozsądne zasady na miejscu, nie metody dnia codziennego.
• Rzeczywiste zastępstwo. Możesz wysłać odpowiednio wykwalifikowanego zastępcę, opłacanego przez ciebie. Nielimitowane weto klienta sprawia, że prawo wygląda nierealnie.
• Wzajemność. Każdy zakres prac to osobne zlecenie. Żadna strona nie jest zobowiązana oferować ani przyjmować dalszej pracy, gdy zlecenie się kończy.

HMRC patrzy łącznie na umowę i praktykę pracy. Klauzula o zastępstwie, której klient nigdy nie pozwoliłby w praktyce, nie uniesie statusu. Wpisz zastępstwo do klauzuli cesji i podwykonawstwa w umowie niezależnego wykonawcy albo umowie z freelancerem, nie w pobocznym mailu.

Dłuższa lista kontrolna — Rozdział 8 i Rozdział 10, Status Determination Statement oraz brzmienie przyjazne „poza” — to lista kontrolna klauzul IR35. Ta strona nie wymyśla brzmienia poza tamtą.

Przykład

Developer decyduje, jak dostarczyć uzgodniony rezultat. Klient może ustalić rezultat, terminy i rozsądne zasady dostępu, nie metody dnia codziennego. Developer może wysłać odpowiednio wykwalifikowanego zastępcę, opłacanego przez Developera. Każdy zakres prac to osobne zlecenie. Żadna strona nie jest zobowiązana oferować ani przyjmować dalszej pracy, gdy zlecenie się kończy.

Prostym językiem: ty prowadzisz jak. Oni kupują co. Możesz wysłać kogoś innego, kto zrobi robotę. Ten SOW to ten SOW — nie obietnica przyszłego miesiąca.

Ogranicz odpowiedzialność do wielokrotności wynagrodzenia. W England and Wales nie możesz wyłączyć odpowiedzialności za śmierć albo uszkodzenie ciała spowodowane zaniedbaniem. Jeśli masz dostęp do danych osobowych w systemach klienta, przetwarzanie wymaga wiążącej umowy procesora. Zobacz dłuższy przewodnik o odpowiedzialności.

Działające ograniczenie odpowiedzialności nazywa:

• limit — często wynagrodzenie zapłacone na podstawie SOW albo wskazaną wielokrotność
• co zostaje nielimitowane — odpowiedzialności za śmierć albo uszkodzenie ciała spowodowane zaniedbaniem nie można wyłączyć ani ograniczyć (Unfair Contract Terms Act 1977 s.2, ustawa o nieuczciwych warunkach umownych z 1977 r.). Inną odpowiedzialność z tytułu zaniedbania można ograniczyć tylko w stopniu, w jakim zapis jest rozsądny
• czy zwolnienie z odpowiedzialności (indemnity) siedzi w limicie, czy go przebija

Dłuższa strona to Jak freelancer ma ograniczyć odpowiedzialność?.

Jeśli przetwarzasz dane osobowe dla klienta — bazy production, eksporty użytkowników, dostęp supportu — artykuł 28(3) UK GDPR wymaga umowy, która wiąże cię jako procesora. Musi wskazać przedmiot i czas przetwarzania, charakter i cel, rodzaj danych osobowych i kategorie osób, których dane dotyczą, oraz warunki procesora z art. 28(3)(a)–(h). Zobacz ochronę danych. Nie udawaj, że linijka „będziesz przestrzegać prawa ochrony danych” jest tą umową.

W umowie o usługi między przedsiębiorcami obowiązuje też dorozumiany warunek, że wykonasz usługę z należytą starannością i umiejętnością — Supply of Goods and Services Act 1982 s.13. Limit stoi obok tego warunku. Nie kasuje go.

Przykład

Całkowita odpowiedzialność Developera na podstawie tej umowy jest ograniczona do wynagrodzenia zapłaconego na podstawie właściwego zakresu prac. Nic w tej umowie nie ogranicza odpowiedzialności za śmierć albo uszkodzenie ciała spowodowane zaniedbaniem. Gdy Developer przetwarza dane osobowe dla Klienta, to przetwarzanie podlega warunkom procesora z Załącznika 2.

Prostym językiem: jeśli coś pójdzie nie tak, odpowiadasz do wysokości wynagrodzenia za to zlecenie. Nie wyłączysz się z zabicia kogoś przez nieostrożność. Jeśli ruszasz dane ich użytkowników, napisz papier procesora, nie klimat.

Nazwij, kto dostaje dostęp, do których repozytoriów i kont w chmurze, z jakim uprawnieniem i kiedy dostęp się kończy. Używaj nazwanych kont, nie wspólnego hasła. Na końcu oddajesz dane dostępu, a oni odwołują twoje. Zapisz to jako praktykę, nie jako klauzulę z ustawy karnej.

Działająca klauzula o dostępie odpowiada na pięć rzeczy:

• Co. Hosty Git, konsole chmury, CI, trackery błędów, analytics, DNS domeny.
• Kto. Nazwane osoby, na nazwanych kontach. Żadnego wspólnego hasła roota w DM na Slacku.
• Uprawnienie. Least privilege na zlecenie. Zapis na production tylko jeśli SOW mówi, że ty promujesz.
• Sekrety. Gdzie żyją deploy keys i tokeny. Kto je rotuje.
• Koniec. Oddajesz albo niszczysz dane dostępu. Oni odwołują twój dostęp w dacie końca albo przy istotnym naruszeniu.

Nie trzymaj kluczy production jako zakładnika za niezapłaconą fakturę. Prawo wstrzymania i linijka IP już robią tę robotę: brak przeniesienia i brak obowiązku promocji, gdy niesporna faktura jest przeterminowana. Walka o lockout to sposób, w jaki mały dług staje się większym sporem.

Jeśli udostępniasz nieopublikowane repo, zanim umowa jest podpisana, postaw wzajemną umowę o zachowaniu poufności (NDA) obok listy dostępu.

Przykład

Klient udzieli Developerowi dostępu do repozytoriów i kont w chmurze wymienionych w Załączniku 1, na nazwanych kontach i z uprawnieniem tam wskazanym. Developer nie będzie udostępniał tych danych dostępu. Na końcu albo na pisemne żądanie Klienta Developer zwróci albo zniszczy dane dostępu w kontroli Developera, a Klient odwoła dostęp Developera.

Prostym językiem: wpuszczają cię na nazwane konto. Nie rozdajesz kluczy. Gdy się kończy, oddajesz klucze, a oni zamykają drzwi.

Tylko jeśli umowa tak mówi. Samo przeniesienie kodu nie daje ci prawa, by wstawić produkt na swoją stronę. Zapisz licencję zwrotną: nazwane kanały, czy możesz wymienić klienta i czy poufna praca zostaje poza portfolio, dopóki nie wystartują.

Działająca klauzula o portfolio odpowiada na cztery rzeczy:

• Gdzie. Twoja strona, social, drukowany showreel, wystąpienia.
• Co. Publiczny produkt, nie nieopublikowane branche ani odrzucona architektura.
• Kiedy. Po starcie albo po wskazanym embargu.
• Podpis. Czy wymieniasz klienta i czy oni wymieniają ciebie. Credit za kod to obietnica umowna.

Zobacz publicity i portfolio. Jeśli zlecenie jest poufne — niestartowany produkt, build w stealth — zapisz, że licencja zaczyna się przy ich publicznym starcie albo za pisemną zgodą. Milczenie to sposób, w jaki case study idzie na żywo w tygodniu przed ich ogłoszeniem.

Przykład

Developer może odtwarzać publiczny produkt w portfolio Developera oraz na stronie i kanałach społecznościowych Developera i może wskazać Klienta jako zamawiającego, po starcie albo wcześniej za pisemną zgodą Klienta. Ta licencja nie obejmuje nieopublikowanych branchy, adresów staging ani informacji poufnych.

Prostym językiem: gdy jest publiczne, możesz pokazać żywy produkt i ich wymienić. Nie możesz pokazać ścieżek, które zabili, ani wyciekać startu.

Jeśli odmawiają jakiegokolwiek użycia w portfolio, to kwestia ceny. Miej to w dokumencie przed startem.

Zlecenie kończy się, gdy nazwane rezultaty są odebrane albo gdy upływa wypowiedzenie. Przekaż repozytoria, dane dostępu i dokumentację. Niezapłacony kod zostaje twój. Potem wsparcie siedzi na retainerze albo u klienta. Nie zostawiaj „będziemy mieli na oku” jako otwartej obietnicy.

Działające przekazanie odpowiada na pięć rzeczy:

• Kiedy build się kończy. Odbiór na stagingu albo wskazana data końca.
• Co przechodzi. Repozytoria, admin chmury, CI, DNS, loginy osób trzecich, runbooki.
• Co zostaje. Twoje lokalne narzędzia, niewykorzystane spike’i, biblioteki, których nie przeniosłeś.
• Gwarancja. Wady względem SOW przez wskazaną liczbę dni. To okno umowne, nie ustawowy dodatek do CDPA.
• RetainerabonamentAbonament (retainer) to ustalenie, w którym klient płaci regularną opłatę, by zarezerwować określony czas lub stały dostęp do wykonawcy.Więcej w słowniku. Godziny na miesiąc, czasy reakcji, czy niewykorzystane godziny przechodzą, jak się kończy. Zobacz umowę o stałą współpracę.

Jeśli chcą cię na dyżurze po starcie i nie ma retainera, to nowe zlecenie. Jak zakończyć umowę freelance to dłuższa strona o końcu.

Przykład

Zlecenie kończy się przy odbiorze Rezultatów albo przy wypowiedzeniu z Załącznika 1. Developer przekaże repozytoria, dostęp administratora chmury, CI, rekordy DNS i loginy osób trzecich wymienione w Załączniku 1. Wady względem Załącznika 1 zgłoszone w ciągu 30 dni od odbioru są naprawiane bez opłaty. Hosting, dyżur i dalsze zmiany po tym oknie to osobny retainer albo są wyceniane jako dodatkowa praca. Własność intelektualna w pracy nie w pełni zapłaconej zostaje przy Developerze.

Prostym językiem: dostarczasz, oddajesz klucze, naprawiasz prawdziwe błędy przez miesiąc. Potem płacą za opiekę albo prowadzą to sami. Niezapłacony kod zostaje twój.

W Contracts.io obie strony tworzą, negocjują i podpisują elektronicznie jedną wspólną umowę developera, więc SOW, linijka IP i kill fee to wersja, którą obie podpisały. Opisz zlecenie w jednym zdaniu. Lex, nasz asystent AI, przygotowuje projekt. Udostępniasz jeden link. Nikt nie wymienia się mailami z v4_final.docx.

Klient otwiera ten link. Może Accept, Counter lub Decline na tej samej wersji, a potem oboje podpisujecie elektronicznie. Druga strona nigdy nie płaci i nie potrzebuje konta.

Zacznij od umowy z freelancerem albo umowy niezależnego wykonawcy. Budowa strony może zacząć od budowy strony. Powtarzana praca może zawiesić zakres prac pod umową o świadczenie usług. Po starcie umowa o stałą współpracę pokrywa opiekę. Możesz też zacząć od generatora umów AI albo generatora umów. Jeśli udostępniasz nieopublikowany kod, zanim umowa jest podpisana, obok niej stoi generator NDA albo wzajemna umowa o zachowaniu poufności (NDA).

To nie wydaje Status Determination Statement IR35 za klienta. Sprawia jednak, że zakres prac, przeniesienie praw IP albo licencja, zaliczkazaliczkaZaliczka to pieniądze płacone z góry, przed główną pracą lub ostatnią fakturą.Więcej w słowniku, kill fee i limit odpowiedzialnościlimit odpowiedzialnościLimit odpowiedzialności to maksymalna kwota, jaką jedna strona może zostać wezwana do zapłaty drugiej na podstawie umowy.Więcej w słowniku to słowa, które obie strony podpisały, a nie linijka zagubiona w mailu.

Free £0, potem płatne plany od £15 miesięcznie — zobacz /pricing.

Wypróbuj na contracts.io: opisz build w jednym zdaniu, udostępnij jeden link i podpisz elektronicznie przed pierwszym commitem.

Umowy dla developerów to szerszy zestaw warunków wokół tego dokumentu. Umowy dla web designerów to siostra stron. Lista kontrolna klauzul IR35 to strona o statusie. Czy zaczynać pracę, zanim umowa zostanie podpisana? to zasada na dzień pierwszy.