Як оцінити пропозицію на розробку сайту: критерії замість порівняння ціни

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

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

Почніть із мети та меж проєкту

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

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

Порівнюйте склад результату, а не назви етапів

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

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

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

З’ясуйте підхід до контенту та SEO

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

Для редизайну чи міграції окремо потрібні інвентаризація чинних URL, карта перенесення, 301-редиректи, збереження важливих метаданих і перевірка Search Console після запуску. Відсутність цього блоку може створити ризик втрати вже накопиченої видимості.

Перевірте технологічні обмеження

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

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

Зафіксуйте права власності та доступи

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

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

Домовтеся про тестування і приймання

Фраза «перевіримо сайт» занадто загальна. Попросіть тестову матрицю: форми, листи, адаптивність, навігація клавіатурою, основні браузери, швидкість, SEO-теги, 404, редиректи, інтеграції та сценарії помилок. Для магазину потрібні окремі проходи оформлення замовлення з різними доставками й оплатами.

Критерії готовності мають бути спостережуваними. Наприклад: усі форми доставляють повідомлення на погоджену адресу; сторінки не мають горизонтального переповнення на визначених ширинах; кожен індексований URL повертає правильний статус і self-canonical.

Відокремте гарантію, підтримку та розвиток

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

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

Проста матриця порівняння

Сигнали ризику

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

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

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

FAQ

Поширені запитання

Чи можна порівнювати пропозиції лише за кількістю сторінок?

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

Що має бути зафіксовано до початку робіт?

Мета, обсяг, відповідальні, вхідні матеріали, етапи, критерії приймання, права доступу, порядок змін і умови після запуску.

Чи нормальна погодинна оцінка замість фіксованої?

Так, особливо для аудиту, підтримки або успадкованого коду. Важливі прозорий облік, пріоритети, межа бюджету й регулярне погодження результату.

Хто має володіти доменом і ліцензіями?

Домен і критичні бізнес-акаунти доцільно оформлювати на власника бізнесу. Правила щодо платних ліцензій потрібно погодити до старту.

Як зрозуміти, що кошторис повний?

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