Скільки коштує сайт? Ціни, обсяг і підтримка

Ціни DigiDraft для планування бюджету

Суми взято з публічного прайсу DigiDraft, перевіреного 8 жовтня 2026 року. Це орієнтовні ціни в PLN без податків, а не середні показники ринку. Обсяг, податки, матеріали, інтеграції та строки уточнюються в конкретній пропозиції. Позначка «від» не встановлює граничної ціни для довільного розширення.

Почніть із завдань, а не кількості сторінок

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

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

Як порівняти пропозиції за однаковими умовами

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

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

Шаблон, авторський дизайн чи складна система

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

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

Оцінюйте інтеграції разом зі сценаріями помилок

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

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

Перенесення сайту охоплює його попередню історію

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

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

Будуйте графік відповідно до залежностей

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

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

Порахуйте рік користування разом із запуском

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

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

Бриф для предметної оцінки проєкту

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

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