Договір на розробку сайту — що має бути, щоб захистити вас як клієнта
Коротко
- → Договір без конкретного переліку сторінок і функцій — це не договір, а декларація про наміри. Предмет має бути описаний так, щоб можна було перевірити: зроблено чи ні
- → Права на код, дизайн і контент повинні переходити до вас після повної оплати — інакше розробник може заблокувати ваш сайт у будь-який момент
- → Кількість раундів правок має бути зафіксована в договорі — «безлімітні правки» на практиці означають «коли-небудь, може, зроблю»
- → Якщо розробник відмовляється підписувати договір або каже «та навіщо, ми ж довіряємо одне одному» — це головний червоний прапорець
Ви домовились із розробником, обговорили сторінки, функції, ціну — і він каже: «Давайте я надішлю договір». Або гірше: не каже, і ви починаєте працювати на словах. У другому випадку проблеми майже гарантовані. У першому — залежить від того, що в цьому договорі написано.
Я підписую договір з кожним клієнтом. І бачив достатньо чужих договорів (коли до мене приходять після невдалого досвіду), щоб знати: різниця між хорошим і поганим договором — це різниця між «отримав сайт вчасно» і «втратив гроші і час». Ця стаття — чекліст того, що має бути в договорі на розробку сайту, з поясненням навіщо.
Сторони і предмет: хто, що і для кого
Перше — ідентифікація сторін. Якщо розробник — ФОП, у договорі мають бути його ПІБ, РНОКПП (ІПН), банківські реквізити. Якщо ТОВ — назва, код ЄДРПОУ, юридична адреса. Те саме стосується вас як замовника. Без цього договір юридично слабкий, і в разі спору довести щось буде складно.
Друге — предмет договору, і це найважливіша частина. «Розробка веб-сайту» — це не предмет. Предмет — це конкретний перелік: кількість сторінок, які функції (форма зворотного зв'язку, каталог товарів, калькулятор), адаптивна верстка, інтеграції (CRM, платіжна система, Нова Пошта). Якщо не прописано — розробник формально правий, здавши вам одну сторінку з текстом «Hello World».
Найкраща практика — додати до договору технічне завдання (ТЗ) як додаток. Саме ТЗ описує деталі, а договір посилається на нього: «Виконавець зобов'язується розробити веб-сайт відповідно до Додатку 1 (Технічне завдання)». Що має бути в ТЗ — я описував у статті про те, що підготувати для розробника перед початком роботи.
Терміни і етапи здачі
У договорі мають бути дві дати: початок робіт і кінцевий дедлайн. Але однієї кінцевої дати недостатньо, якщо проєкт більший за лендінг. Для сайтів на 10+ сторінок розумно прописати проміжні етапи: затвердження дизайну, верстка, програмування, тестування, запуск. Кожен етап — зі своїм дедлайном. Детальніше що відбувається на кожному етапі — окрема стаття.
Окремий пункт: що вважається затримкою з вини замовника. Якщо ви 3 тижні не надсилаєте матеріали або не даєте зворотний зв'язок на дизайн — дедлайн розробника зсувається. Це справедливо, і це має бути в договорі. Формулювання типу «терміни зсуваються на кількість днів затримки замовника» — стандартне і захищає обидві сторони.
Також зафіксуйте, що відбувається при порушенні дедлайну розробником. Зазвичай це пеня — 0,1–0,5% від вартості за кожен день прострочення. Без цього пункту розробник може тягнути проєкт місяцями без жодних наслідків.
Вартість і порядок оплати
Фіксована сума чи погодинна ставка — має бути зрозуміло одразу. Для більшості бізнес-сайтів стандарт — фіксована ціна за проєкт. Погодинна модель підходить для довгострокової підтримки або проєктів з нечітким обсягом (але тоді потрібен ліміт годин або бюджету). Орієнтири по цінах — у розборі вартості розробки сайту.
Типова схема оплати: 50% передоплата, 50% після здачі. Для великих проєктів — 30/30/40 або поетапно. Ключовий момент: передоплата не повинна бути 100%. Якщо розробник вимагає всю суму наперед — це ризик. Ви втрачаєте важіль впливу, і в разі проблем повернути гроші буде важко.
Що ще має бути: що входить у ціну, а що ні. Хостинг, домен, контент, фотографії, платні плагіни, інтеграції зі сторонніми сервісами — все це може бути і може не бути включене. Якщо не прописано — будете дізнаватись по ходу, і кожен раз це «ще трохи грошей». Порахуйте орієнтовну вартість заздалегідь, щоб розуміти бюджет.
Потрібна консультація?
Безкоштовно розберу ваш проєкт і дам рекомендації
Права на результат: кому належить сайт
За замовчуванням (ст. 430 Цивільного кодексу України) майнові права на твір, створений на замовлення, належать замовнику і виконавцю спільно. Це означає, що без окремого пункту в договорі розробник має такі самі права на ваш сайт, як і ви. На практиці це рідко створює проблеми — але коли створює, це боляче.
У договорі має бути чітко: «Усі майнові права на результат робіт (дизайн, код, контент) переходять до Замовника після повної оплати». Це стосується вихідного коду, макетів дизайну, текстів, ілюстрацій — усього, що створено в рамках проєкту. Без цього пункту розробник формально може заборонити вам змінювати сайт або передавати його іншому підрядникові.
Окремий нюанс: CMS та плагіни. Якщо сайт побудований на WordPress — ви не отримуєте права на WordPress, бо це відкрите ПЗ зі своєю ліцензією (GPL). Те саме з платними плагінами — ліцензія на них зазвичай оформлюється на конкретну людину чи компанію. Уточніть, хто буде власником ліцензій і чи зможете ви їх продовжувати самостійно.
Правки, доопрацювання і обсяг робіт
Кількість раундів правок — один із найчастіших джерел конфліктів. Стандарт — 2–3 раунди правок на кожний етап (дизайн, верстка). «Раунд» — це одна порція зауважень, зібрана в один список. Не «я буду надсилати правки по одній щодня протягом місяця».
Важливо розрізняти правки і зміну обсягу. «Змінити колір кнопки» — правка. «Додати інтернет-магазин, якого не було в ТЗ» — зміна обсягу, яка потребує окремого погодження і, ймовірно, додаткової оплати. Договір має описувати процедуру: як подаються правки, у який термін виконуються, що робити із запитами поза ТЗ.
«Безлімітні правки» — маркетинговий трюк. На практиці це означає одне з двох: або розробник закладає великий запас у ціну (і ви переплачуєте), або він погоджується на все, а потім тягне роками, бо пріоритет — на нових клієнтах, які платять. Конкретна цифра (2–3 раунди) краща для обох сторін.
Гарантії, відповідальність і розірвання
Гарантійний термін — період після здачі, протягом якого розробник безкоштовно виправляє баги. Стандарт у галузі — 1–3 місяці. Баг — це коли щось працює не так, як описано в ТЗ. «Хочу іншу структуру головної» — не баг, а нова задача. Ця межа теж має бути в договорі. Сюди ж варто внести повний список того, що ви отримаєте після здачі сайту: доступи, файли, інструкції. Окремо варто обговорити, що буде після гарантійного терміну — чи пропонує розробник підтримку сайту на платній основі, і на яких умовах.
Розірвання договору: обидві сторони повинні мати право розірвати. Типові умови: замовник може розірвати в будь-який момент, оплативши виконану частину роботи. Виконавець може розірвати, якщо замовник не виходить на зв'язок протягом 30 днів або не вносить оплату. Ключове — що відбувається з уже зробленою роботою: чи отримує замовник вихідні файли пропорційно до оплати.
Конфіденційність — якщо ви передаєте розробнику доступ до бази клієнтів, CRM або внутрішніх документів, додайте пункт про нерозголошення (NDA). Для більшості малих проєктів окремий NDA — перебір, але один абзац у договорі не завадить.
Червоні прапорці в договорі
Є речі, які повинні насторожити ще до підписання. Перша — відсутність договору взагалі. «Та навіщо, ми ж довіряємо» — це не довіра, це відсутність відповідальності. Друга — договір на одну сторінку, де все обмежується фразою «розробка сайту за таку-то суму». Це не захищає нікого.
Третя — 100% передоплата. Четверта — заборона звертатись до інших розробників для доопрацювання після здачі (так, таке буває). П'ята — розробник залишає за собою права на код і «дає ліцензію на використання». Це означає, що ваш сайт — не ваш, і в разі конфлікту він може його відключити.
Шоста — немає пункту про терміни або пеню за прострочення. Сьома — «безлімітні правки» замість конкретної цифри. Якщо бачите два або більше з цих прапорців — це привід переглянути вибір розробника. А щоб зрозуміти, скільки має коштувати нормальна робота — чому дешевий сайт обходиться дорожче.
Часті запитання
Юридично — ні, усна домовленість теж має силу, але довести її в суді практично неможливо. Тому договір — обов'язковий на практиці. Навіть для проєкту за 5 000 грн. Це захищає і вас, і розробника.
У більшості випадків — нічого, бо розробник має свій шаблон. Якщо хочете перевірити договір у юриста — консультація коштує від 500 до 2 000 грн. Для великих проєктів (від 100 000 грн) юридична перевірка окупається багаторазово.
Зазвичай розробник надає свій шаблон, а ви перевіряєте і вносите зауваження. Якщо у вас є корпоративний юрист — нехай теж подивиться. Головне — не підписувати, не прочитавши.
2–3 раунди на етап — стандарт. Для невеликих проєктів (лендінг, сайт-візитка) достатньо 2 раунди: один після першої версії, один фінальний. Для інтернет-магазину або складного корпоративного сайту — 3 раунди на дизайн і 2 на верстку.
Перший крок — письмова претензія (email з описом порушення і вимогою виправити у визначений термін). Якщо не допомагає — зверніться до юриста з договором, перепискою і доказами оплати. Наявність підписаного договору з конкретними зобов'язаннями — це те, що дає вам юридичну позицію.
Так, але це складніше: потрібен двомовний договір, узгодження юрисдикції (чиє право застосовується), валюта оплати і спосіб розрахунку. Для проєктів до 50 000 грн зазвичай простіше працювати з українським підрядником, де договір регулюється українським правом.
Після. Спочатку обговоріть обсяг, функції, терміни і ціну. Потім розробник готує договір і ТЗ на основі домовленостей. Ви перевіряєте, що все збігається з тим, що обговорювали. І тільки тоді підписуєте. Підписувати «рамковий» договір до обговорення деталей — ризиковано.
Не знайшли відповідь?
Висновок: договір — це не бюрократія, а спокій
Хороший договір — це коли обидві сторони чітко розуміють: що буде зроблено, коли, за скільки, і що робити, якщо щось піде не так. Він не замінює довіру між клієнтом і розробником — він її підсилює, бо знімає невизначеність.
Перед тим як шукати розробника, порахуйте орієнтовну вартість свого проєкту — це допоможе предметно обговорювати бюджет. Прочитайте, як оцінити якість готової роботи, щоб знати, що перевіряти при здачі. А якщо потрібен список типових помилок — він допоможе задавати правильні питання ще до початку розробки.
