Caira oceni Twoją umowę w 3 kliknięcia:
Uzyskaj poprawki i uwagi bezpośrednio w swoim pliku
Generuj podsumowania e-mail dla drugiej strony
Rejestracja trwa mniej niż 30 sekund.
Karta nie jest wymagana:
Rozpocznij darmowy okres próbny
"U mnie działa": Dlaczego programiści potrzebują lepszych umów
W świecie web developmentu dominuje luka oczekiwań.
Oddajesz kod zgodny ze specyfikacją.
Klient otwiera go na starym iPhone i krzyczy,
że nie działa.
Tworzysz zamówiony system CMS.
Po pół roku klient żąda naprawy błędu
wywołanego przez wtyczkę, którą sam dodał.
Kod jest logiczny, a klienci emocjonalni.
Umowa to jedyny most między wami.
Bez niej godzisz się na darmowe wsparcie.
Oto luki prawne, które musisz załatać w swoim regulaminie.
1. Czarna dziura kompatybilności
Scenariusz: Tworzysz stronę w React. Działa super na Chrome.
Prezes klienta otwiera ją na Internet Explorer.
Układ się sypie, a oni wstrzymują płatność.
Rzeczywistość prawna:
Działanie na wszystkim jest niemożliwe.
Bez precyzyjnej listy sąd uzna,
że strona musi działać na każdym starym narzędziu.
Rozwiązanie:
Klauzula o obsługiwanych przeglądarkach.
Bądź precyzyjny. Strona wspiera dwie ostatnie wersje Chrome, Safari, Firefox i Edge. Starsze przeglądarki są wykluczone.
2. Odbiór projektu (moment uruchomienia)
Scenariusz: Koniec pracy. Wysyłasz link o treści: „Daj znać, co myślisz”.
Cisza przez 3 tygodnie.
Nagle: „Czy zmienimy czcionkę?”
Potem 2 tygodnie ciszy.
Znowu: „A może przesuniemy logo?”
Mijają 3 miesiące, a Ty nadal nie masz końcowej wpłaty.
Rzeczywistość prawna:
Bez określonego czasu na odbiór projekt tkwi w martwym punkcie. Nie jest ani skończony, ani nieskończony.
Rozwiązanie:
Klauzula milczącego odbioru.
Klient ma 7 dni na testy. Brak zgłoszenia krytycznego błędu na piśmie w tym czasie oznacza akceptację i wymagalność zapłaty.
To zmusza ich do sprawdzenia projektu lub zapłaty.
3. Rozrastanie się zakresu (Scope Creep)
Scenariusz: Wycena na 5 stron.
Klient wysyła teksty na 12 stron.
Mówi: „Tylko rozbiłem zakładkę O nas, to chyba nie problem?”
To jest problem. Wymaga nowej nawigacji, zmian w wersji mobilnej i pracy.
Rozwiązanie:
Nie wyceniaj „strony”. Wyceniaj konkretny zakres prac.
Jasne rezultaty: „5 stron statycznych. 1 formularz kontaktowy.”
Klauzula zmian: „Zmiany poza zakresem kosztują X za godzinę. Prace wstrzymujemy do momentu akceptacji wyceny.”*
4. Kto posiada kod? (Prawa IP)
Scenariusz: Używasz własnych szablonów startowych. Klient kłóci się z Tobą i żąda pełnego przeniesienia praw autorskich na wszystko.
Jeśli oddasz wszystko, prawnie nie możesz użyć swojego szablonu u kolejnego klienta. Sprzedajesz dom, a nie narzędzia.
Rozwiązanie:
Rozróżniaj kod dedykowany i bazową własność intelektualną.
„Twórca przenosi prawa do dedykowanego projektu i treści po otrzymaniu pełnej zapłaty.”*
„Twórca zachowuje prawa do bibliotek bazowych i udziela klientowi licencji na korzystanie z nich.”*
5. Wieczne naprawianie błędów
Scenariusz: Strona rusza. Po dwóch latach aktualizacja WordPressa psuje system. Klient dzwoni: „Ty to robiłeś, Ty naprawiaj.”
Rozwiązanie:
Okres gwarancji.
Dajemy 30 dni gwarancji na błędy wykryte przy starcie. Problemy po tym czasie lub przez aktualizacje stron trzecich są płatne.
Dlaczego analiza umów to Twoja dokumentacja
Dodajesz komentarze do kodu? Dodaj je też do relacji biznesowych.
Twórco, zobacz przewodnik o pułapkach licencji i przenoszenia IP.
Automatyczna ocena umów bada kontrakt.
Dba, by nie obiecać zbyt wiele.
Pilnuje procesu odbioru.
Pomaga zamknąć projekt, dostać pieniądze i uniknąć długów technicznych.
Wyłączenie odpowiedzialności: treść ma charakter informacyjny i nie stanowi porady prawnej.
