Більшість конфліктів між замовником і студією виникає не через злий намір, а через те, що сторони домовлялися в переписці й кожна зрозуміла домовленість по-своєму. Договір потрібен не щоб судитися — судяться одиниці. Він потрібен, щоб на етапі, коли всі ще в доброму гуморі, проговорити незручні питання: що буде, якщо строки зсунулися, скільки кругів правок входить у ціну і кому належить сайт після запуску.
Нижче — пункти, через відсутність яких найчастіше й починаються проблеми. Це не юридична консультація, а погляд із боку виконавця, який бачив, де рветься.
Предмет: що саме ви купуєте
«Розробка сайту» — не предмет договору, а напрям думок. Предметом має бути конкретний перелік: кількість і призначення сторінок, набір функцій, мови інтерфейсу, що входить у дизайн, хто пише тексти, хто готує фото.
Найзручніше винести це в додаток — технічне завдання, яке є частиною договору. Тоді суперечка «а я думав, калькулятор входить» вирішується не на емоціях, а відкриванням додатка. Як скласти ТЗ, щоб воно не перетворилося на формальність, — у статті про Website Specifications.
Етапи й оплата
Нормальна схема — оплата частинами за етапами: передоплата на старт, платіж після затвердження дизайну, решта перед запуском. Це захищає обох: ви не платите всю суму наперед, виконавець не працює місяць у борг.
У договорі має бути видно, що саме закриває кожен платіж і який результат сторони вважають етапом завершеним. Формулювання «після виконання робіт» без опису результату не означає нічого.
Приймання етапу
Окремо варто прописати строк на зауваження: наприклад, замовник дає відповідь протягом п’яти робочих днів, інакше етап вважається прийнятим. Без цього проєкт зависає на тижні, бо «ми ще не подивилися», а виконавець не може рухатися далі.
Строки і те, що їх зсуває
Строки в договорі мають бути прив’язані не до календаря, а до подій: стільки робочих днів від затвердження прототипу, стільки — від отримання контенту. Інакше виходить, що контент прислали на місяць пізніше, а винним у зриві дати лишився виконавець.
Корисно прямо перелічити, що зупиняє відлік: очікування матеріалів, відповідей, доступів, оплати. Реальні строки за етапами розібрані у статті How long does it take to develop a website?.
Правки: скільки їх входить
Це пункт, який пропускають найчастіше, і саме він з’їдає маржу й нерви. Формулювання «правки вносяться до повного задоволення замовника» виглядає дружньо рівно до третього перемальовування головної.
Робоча схема: вказати кількість кругів правок на кожному етапі (зазвичай два-три на дизайн) і домовитися, що зміни, які виходять за межі затвердженого ТЗ, оцінюються окремо. Це не жадібність — це межа, після якої проєкт перестає бути проєктом і стає нескінченним.
Кому належить код, дизайн і сайт
Ключове питання, яке власники бізнесу згадують занадто пізно — зазвичай тоді, коли хочуть змінити підрядника.
- Domain має бути зареєстрований на вас або вашу компанію, а не на студію. Це найчастіша пастка: домен оформлений на підрядника, і через три роки переїзд перетворюється на перемовини.
- Web Hosting — бажано теж на ваш акаунт, навіть якщо адмініструє його виконавець.
- Майнові права на дизайн і код переходять до замовника — і в договорі має бути сказано, що саме передається і коли (як правило, після повної оплати).
- Вихідні файли: макети, початковий код, доступи до всіх сервісів передаються після запуску. Список передачі краще оформити актом.
- Сторонні компоненти: платні теми, плагіни, шрифти, фотостоки — чиї ліцензії і на кого оформлені. Ліцензія, оформлена на студію, разом зі студією і зникає.
Що саме потрібно забрати, якщо сайт уже зроблено й ви йдете до іншого виконавця, — у статті How to Transfer a Website to Another Contractor.
Гарантія і що буде після запуску
Гарантія має стосуватися помилок у тому, що зроблено: якщо форма перестала надсилати заявки, це виправляється безкоштовно й у розумний строк. Гарантія не поширюється на нові побажання, на наслідки правок, які ви внесли самі, і на зовнішні сервіси.
Корисно одразу описати, що відбувається після гарантійного періоду: хто оновлює систему, хто робить бекапи, за якою ставкою рахуються доробки. Що зазвичай входить у таку домовленість — у статті which is part of the website's support.
Доступи, дані й конфіденційність
Якщо виконавець працює з вашою базою клієнтів, прайсами чи документами, у договорі має бути пункт про конфіденційність. Для складних проєктів підписують окрему угоду. І навпаки: ви передаєте доступи не «розробнику Сергію в телеграм», а компанії, з якою маєте договір, — і забираєте їх після завершення.
Червоні прапорці
- Виконавець узагалі не пропонує договір і пояснює це тим, що «ми працюємо на довірі».
- Стовідсоткова передоплата без етапів.
- Немає ТЗ або воно складається з трьох рядків.
- Домен реєструє на себе й пояснює, що «так зручніше».
- Відмовляється фіксувати передачу вихідного коду.
- У договорі немає жодного слова про правки й строки.
Жоден із цих пунктів сам по собі не означає, що перед вами шахрай. Але якщо їх кілька — це привід поставити більше питань. Які саме, зібрано у статті How to Choose a Contractor: 9 Questions.
Як це виглядає в нас
Ми працюємо за договором, ТЗ додається до нього, оплата йде етапами, домен і хостинг оформлюються на замовника, а після запуску передаємо вихідний код і всі доступи. Якщо вам потрібен сайт і ви хочете бачити ці умови заздалегідь — опишіть задачу через cost calculation: разом із кошторисом надішлемо й порядок роботи. Що корисно продумати до першої розмови з будь-яким виконавцем — у рубриці How to Order a Website, а що входить у роботу в нас — на сторінці Turnkey Website Development.
Telegram