Caira może przejrzeć Twoją umowę w 3 kliknięciach:

• Otrzymuj sugerowane zmiany i komentarze dodawane bezpośrednio do Twojego pliku

• Generuj podsumowanie e-maila do wysłania drugiej stronie

Rejestracja do bezpłatnego okresu próbnego zajmuje mniej niż 30 sekund. Karta kredytowa nie jest wymagana: Rozpocznij bezpłatny okres próbny

„It Works on My Machine”: Dlaczego twórcy stron WWW potrzebują lepszych umów

Świat tworzenia stron WWW zmaga się z „rozbieżnością oczekiwań”.

Dostarczasz kod zgodny ze specyfikacją. Klient otwiera go na iPhonie 6 z 2014 roku i krzyczy „Jest zepsute!”

Budujesz CMS, o który prosili. Dzwonią sześć miesięcy później, żądając naprawy błędu spowodowanego przez wtyczkę, którą oni zainstalowali.

Programowanie jest logiczne. Klienci są emocjonalni. Twoja umowa jest jedynym mostem między tymi dwoma światami. Bez niej zapisujesz się na dożywotnie, nieopłacane wsparcie techniczne.

Oto prawne błędy, które musisz załatać w swoich Warunkach współpracy.

1. Czarna dziura „zgodności z przeglądarkami”

Sytuacja: Budujesz elegancką stronę w React. Działa świetnie w Chrome i Safari. Prezes klienta otwiera ją w Internet Explorer 11 w biurze. Układ siatki się rozsypuje. Wstrzymują płatność, dopóki nie będzie działać „na wszystkim”.

Rzeczywistość prawna:

„Działa na wszystkim” jest technicznie niemożliwe. Bez konkretnej listy sąd może zinterpretować „funkcjonalną stronę internetową” jako „działającą na standardowych narzędziach biznesowych”, co może obejmować starsze przeglądarki.

Rozwiązanie:

Klauzula obsługiwanych przeglądarek.

Bądź konkretny. „Strona internetowa została zaprojektowana tak, aby działać w dwóch najnowszych wersjach Chrome, Safari, Firefox i Edge. Zgodność ze starszymi przeglądarkami (np. IE11) jest wyłączona, chyba że wyraźnie uzgodniono to w Specyfikacji.”

2. Testy akceptacyjne (wyzwalacz „uruchomienia”)

Sytuacja: Kończysz stronę. Wysyłasz link. „Daj znać, co myślisz.”

Cisza przez 3 tygodnie.

Potem: „Czy możemy zmienić czcionkę?”

Potem cisza przez 2 tygodnie.

Potem: „Właściwie, czy możemy przesunąć logo?”

Jesteś 3 miesiące po terminie i nie otrzymałeś ostatnich 50% wynagrodzenia.

Rzeczywistość prawna:

Bez zdefiniowanego „Okresu akceptacji” projekt jest w trybie zombie. Nie jest ani ukończony, ani nieukończony.

Rozwiązanie:

Klauzula domniemanej akceptacji.

„Klient ma 7 dni od dostarczenia na przetestowanie oprogramowania. Jeśli w ciągu 7 dni na piśmie nie zostanie zgłoszony żaden konkretny „Błąd” (zdefiniowany jako awaria/poważna usterka), oprogramowanie zostaje uznane za zaakceptowane, a pozostała kwota staje się wymagalna.”

To zmusza ich do sprawdzenia tego albo zapłacenia Ci.

3. Rozrost zakresu („Tylko jedna mała zmiana”)

Sytuacja: Wyceniasz 5 stron. W połowie projektu klient przesyła treść. To 12 stron. „Po prostu podzieliłem stronę O nas, to chyba nie problem, prawda?”

To jest duży problem. Chodzi o logikę nawigacji, wpływ na menu mobilne i czas wprowadzania treści.

Rozwiązanie:

Przestań wyceniać „stronę internetową”. Wyceniaj „zakres prac”.

• Ścisłe rezultaty: „5 x Strony statyczne. 1 x Formularz kontaktowy.”

Klauzula zmian: „Wszelkie konkretne prośby spoza tego Zakresu będą rozliczane według naszej standardowej stawki godzinowej wynoszącej £[X]. Prace zostaną wstrzymane do czasu zatwierdzenia zmiany.”*

4. Kto jest właścicielem kodu? (prawa IP)

Sytuacja: Używasz swojego standardowego „Starter Theme” albo biblioteki funkcji pomocniczych, które napisałeś lata temu. Klient pokłóci się z Tobą. Żądają „pełnego przeniesienia autorskich praw majątkowych” do całego kodu.

Jeśli przeniesiesz wszystko, nie będziesz mógł legalnie użyć własnego starter theme przy następnym kliencie. Sprzedałeś „narzędzia”, a nie tylko „dom”.

Rozwiązanie:

Rozróżnij „Kod na zamówienie” i „IP bazowe”.

„Programista przenosi na Klienta prawa autorskie do autorskiego projektu i układu tekstu po pełnej płatności.”*

„Programista zachowuje własność całego „Zaplecza IP” (ponownie używalnych bibliotek/frameworków) i udziela Klientowi bezterminowej, niewyłącznej licencji na ich używanie dla tej strony internetowej.”*

5. Naprawianie błędów „na całe życie”

Sytuacja: Strona rusza. Dwa lata później WordPress się aktualizuje. Strona przestaje działać. Klient dzwoni: „Ty to zrobiłeś, ty to napraw.”

Rozwiązanie:

Okres gwarancji.

„Zapewniamy 30-dniowy okres gwarancji po uruchomieniu na naprawę błędów obecnych przy starcie. Wszelkie problemy pojawiające się po 30 dniach lub spowodowane przez aktualizacje osób trzecich (wtyczki/zmiany przeglądarek) są płatną obsługą serwisową.”

Dlaczego przegląd umowy jest Twoją dokumentacją

Komentujesz swój kod. Powinieneś komentować swoją relację biznesową.

Analiza umów przez AI parsuje Twoją umowę na realizację projektu. Sprawdza, czy przypadkiem nie obiecałeś „przydatności do określonego celu” (wysokiego progu prawnego) zamiast „należytej staranności i dbałości”. Upewnia się, że Twój przepływ „Akceptacji” jest szczelny. Pomaga Ci dostarczyć projekt i dostać zapłatę, bez dziedzicznego długu technicznego.

Zastrzeżenie: Informacje zawarte w tym artykule służą wyłącznie ogólnym wskazówkom i nie są przeznaczone jako profesjonalna porada prawna, finansowa, podatkowa ani medyczna.