Договір на розробку сайту без несподіваних доплат: що прописати

Договір на розробку сайту має фіксувати не лише суму, а й конкретний результат, який отримає бізнес. Формулювання на кшталт «корпоративний сайт», «сучасний дизайн» або «інтеграція з CRM» не дають достатнього контролю над бюджетом, якщо не пояснюють склад робіт, межі відповідальності та порядок погодження змін.

Практична мета договору — не заборонити будь-які додаткові роботи. У процесі можуть виникати нові потреби бізнесу, змінюватися вимоги зовнішніх сервісів або виявлятися технічні обмеження. Добре підготовлений документ робить такі зміни керованими: до старту робіт сторони розуміють причину, обсяг, вплив на строк і вартість.

Прозорий бюджет не означає незмінну ціну за будь-яких обставин. Він означає, що жодна нова робота не з’являється в рахунку без зрозумілого опису та попереднього погодження.

Звідки беруться несподівані доплати

Найчастіше розбіжність виникає на стику очікувань. Замовник вважає певну можливість природною частиною сайту, а виконавець — окремою функцією, якої не було у погодженому обсязі. Наприклад, форма заявки може входити в базову розробку, але передавання даних у CRM, розподіл заявок між менеджерами, автоматичні листи, захист від спаму та сценарії помилок — це окремі елементи робіт.

Інше джерело ризику — підписання договору лише на підставі загальної комерційної пропозиції. Вона може бути корисною для попереднього вибору підрядника, але не замінює специфікацію: перелік сторінок сам по собі не пояснює їхню логіку, стан на мобільному пристрої, правила редагування або інтеграції.

Щоб уникати ситуацій, які в міжнародному проєктному листуванні можуть називати unexpected website development costs, варто відокремити три категорії: що входить у ціну, які припущення використано для оцінки та що прямо виключено з неї. Такий поділ захищає інтереси обох сторін: бізнес планує витрати, а команда не бере на себе необмежені очікування.

Зафіксуйте обсяг у специфікації

Ключовим додатком до договору є технічне завдання, специфікація або погоджений backlog із номером версії та датою. Для команд, які працюють з англомовною документацією, аналогічний документ можуть називати website project scope agreement. Назва не настільки важлива, як зміст: він має описувати результат так, щоб його можна було перевірити під час приймання.

Замість фрази «сайт на десять сторінок» зазначте типи сторінок, склад блоків, адаптивні стани, джерела контенту, логіку форм і правила редагування в CMS. Документ повинен дозволяти відповісти на просте питання: чи входить конкретна функція в погоджений обсяг, чи це нова вимога?

Специфікація зазвичай охоплює:

• перелік сторінок, мовних версій і типів контенту;
• функції для відвідувачів: пошук, фільтри, форми, оплата, бронювання, особистий кабінет або інші потрібні сценарії;
• можливості адміністратора: ролі, поля, редагування блоків, імпорт та експорт даних;
• вимоги до мобільної версії, підтримуваних браузерів, швидкодії та базової безпеки;
• матеріали й доступи, які надає замовник: тексти, фото, переклади, товарні дані, юридична інформація, акаунти сервісів;
• роботи виконавця: структура, прототипи, дизайн, розробка, наповнення, тестування, запуск та інструкції.

Опишіть ролі та сценарії користувачів

Назва функції ще не визначає її обсяг. Якщо в специфікації є «особистий кабінет», зафіксуйте, хто входить у систему, які дані бачить, що може змінювати, як відновлює пароль і які повідомлення отримує. Якщо є «каталог», опишіть категорії, картку товару чи послуги, фільтри, варіації, правила ціноутворення та поведінку системи, коли даних немає.

Ця деталізація не означає, що потрібно перетворювати договір на технічну енциклопедію. Вона потрібна там, де одна коротка назва може приховувати суттєво різний обсяг розробки. Чим складніша бізнес-логіка, тим важливіше описати її до оцінювання.

Розділіть інтеграції, сервіси й доступи

Кожну інтеграцію варто винести в окремий пункт: з якою системою працює сайт, які дані передаються, хто надає API-доступи, хто оплачує ліцензію та хто відповідає за зміни на стороні сервісу. Особливо небезпечно ототожнювати «підключити CRM» із повноцінним налаштуванням процесів у CRM: це можуть бути різні за складом завдання.

Якщо документація API неповна або можливості сервісу потребують перевірки, зафіксуйте це як припущення. У такому разі доречно передбачити окремий етап технічного дослідження, після якого можна уточнити рішення, строк і бюджет.

Кошторис сайту та модель оплати

Кошторис сайту має показувати не лише підсумкову суму, а й логіку її формування. Доцільно розбити проєкт на етапи: дослідження, прототипування, дизайн, розробка, наповнення, тестування, запуск і передання. Тоді зрозуміло, який результат стоїть за кожним платежем і на якому етапі вплине нова вимога.

Окремо перелічіть витрати, які не є винагородою підрядника: домен, хостинг, платні модулі, шрифти, фотобанки, ліцензії, комісії платіжних систем і зовнішні сервіси. Важливо визначити, чи включено податки, кому належать облікові записи та чи може виконавець здійснювати покупку від імені замовника без окремого погодження.

Фіксована ціна працює добре лише за реального, а не уявного обсягу. Вимога «врахувати все можливе» без меж може збільшити стартову оцінку через резерв ризиків або створити підстави для спорів. Раціональніше погодити пріоритетний обсяг, а нові ідеї оцінювати окремо.

Щоб сформувати початкове очікування, корисно розуміти, скільки коштує створення сайту залежно від типу продукту, функцій, контенту та інтеграцій. Водночас такий орієнтир не підміняє кошторис для конкретного проєкту після уточнення вимог.

Додаткові роботи при розробці сайту: порядок погодження

Найважливіший механізм захисту від раптового рахунку — процедура запиту на зміну. У договорі варто прямо зазначити: робота, якої немає у специфікації, не виконується і не оплачується, доки сторони не погодили її у передбаченій договором формі. Це може бути додаткова угода, документ в електронному документообігу або інший узгоджений спосіб підтвердження.

Кожен запит на зміну має містити:

1. опис нової або зміненої вимоги та її бізнес-мету;
2. посилання на пункти специфікації, прототипи чи макети, яких стосується зміна;
3. оцінку вартості, строку, залежностей і потреби в матеріалах;
4. інформацію про вплив на вже виконану роботу;
5. підтвердження уповноваженої особи замовника до початку реалізації.

Призначте одну або кілька конкретних осіб, які можуть затверджувати вимоги, макети й додатковий бюджет. Інакше команда ризикує отримати суперечливі вказівки від власника, маркетолога, відділу продажів і технічного спеціаліста, а бізнес — витрати на кілька неузгоджених «термінових» доробок.

Перед підписанням зручно пройти внутрішній перелік перевірок; в англомовному середовищі його іноді називають web development contract checklist. Суть не в терміні, а в тому, щоб для кожної нової ідеї існували відповідальний за рішення, оцінка наслідків і зафіксоване підтвердження.

Макети, правки та затвердження дизайну

Дизайн часто розширює обсяг, тому що суб’єктивне «не подобається» складно виміряти. Умови договору на створення сайту мають визначати кількість раундів правок для кожного етапу, строк для зворотного зв’язку, формат консолідованих коментарів і момент затвердження. Після нього зміна структури сторінки або перероблення вже зверстаного екрана має проходити через запит на зміну.

Також варто зазначити, які саме екрани та стани входять у візуальну частину: ключові сторінки, мобільні версії, порожні результати пошуку, помилки форм, модальні вікна та системні повідомлення. Окремо перегляньте матеріал «розробка дизайну сайту»: він пояснює, чому вартість і склад робіт залежать від кількості унікальних шаблонів, сценаріїв і станів, а не лише від кількості пунктів у меню.

Контент, матеріали та затримки

Сайт неможливо коректно завершити без матеріалів, які залежать від замовника. Додаток до договору має містити список контенту, вимоги до форматів файлів, строки передання та відповідальних. Окремо визначте, чи входять у ціну перенесення старих сторінок, підготовка текстів, переклад, редагування зображень, завантаження товарів і перевірка юридичних текстів.

Передбачте сценарій затримки контенту, доступів або відповіді на погодження: чи зсуваються строки, чи може команда перейти до іншого етапу, як фіксується пауза в роботі. Це не штрафний інструмент, а спосіб чесно розподілити залежності в календарі проєкту.

Приймання робіт і критерії якості

Фраза «сайт має працювати коректно» не створює зрозумілої точки приймання. У договорі доцільно встановити середовище для перевірки, ключові сценарії тестування, строк для перегляду результату та спосіб подання зауважень. Зауваження мають посилатися на погоджену специфікацію, макети або критерії приймання, а не додавати нові побажання під виглядом помилок.

Принципово розділяйте дефект і зміну. Дефект — це коли погоджена функція не працює так, як описано в документах. Зміна — нове поле, інший сценарій, додаткова інтеграція чи результат, якого не було в затвердженому обсязі. Дефекти виправляються в межах зобов’язань виконавця, а зміни проходять погодження вартості та строку.

Окремо опишіть запуск: хто надає доступ до домену й хостингу, чи входить розгортання на робочому середовищі, хто перевіряє резервне копіювання та як передаються доступи. Для складного продукту можна передбачити період виправлення дефектів після запуску, чітко відмежувавши його від подальшого розвитку функцій.

Права, доступи та підтримка після запуску

Навіть повністю оплачений сайт може створити витрати й залежність, якщо бізнес не отримав доступів або не розуміє умов використання компонентів. У договорі та документі передання варто зафіксувати доступи до домену, хостингу, CMS, репозиторію коду, аналітики, поштових сервісів і інтеграцій — відповідно до складу проєкту. Власником критичних облікових записів доцільно робити замовника, а виконавцю надавати потрібний рівень доступу.

Окремої уваги потребують майнові права на створені матеріали, а також сторонні бібліотеки, плагіни, шрифти й зображення. Не кожен компонент передається як виключне право: важливо розуміти ліцензійні умови та можливі майбутні платежі за підписки чи продовження ліцензій. Для перевірки юридичних формулювань під конкретну модель співпраці та роботу з даними варто залучити профільного юриста.

Підтримка після запуску є окремою послугою, якщо інше прямо не встановлено договором. Визначте, чи включає вона оновлення, резервне копіювання, моніторинг, реагування на помилки, дрібні контентні зміни або розвиток функціоналу. Без цього одна фраза «поправте на сайті» може означати для сторін зовсім різний обсяг.

Що перевірити перед підписанням договору

Перед укладенням договору оцінюйте не тільки суму в пропозиції, а й здатність сторін керувати невизначеністю. Відповіді на ці питання мають бути відображені в договорі або його додатках:

• Який документ є остаточним описом обсягу та яка його версія чинна?
• Які функції, матеріали, сервіси й витрати прямо виключені з ціни?
• Хто з боку замовника має право затверджувати макети, етапи та новий бюджет?
• Скільки раундів правок входить у кожен етап і що вважається новою вимогою?
• Як оформлюється зміна, коли виконавець може почати її реалізацію та як це впливає на строк?
• За якими сценаріями приймається результат і як відрізнити дефект від нового завдання?
• Які доступи, вихідні матеріали та права будуть передані після виконання зобов’язань?
• Що відбувається, якщо замовник затримує контент або сторонній сервіс змінює правила роботи?

Сильний договір не замінює регулярної комунікації, але задає їй зрозумілі правила. Якщо на старті неможливо коротко пояснити, що входить у ціну, як приймається етап і як погоджується нова функція, сам підпис не усуне ризик доплат. Спочатку уточніть продукт і межі робіт, потім оберіть модель оплати та лише після цього остаточно фіксуйте бюджет і строки.