Вартість починається зі складу результату
Запит «скільки коштує сайт» може означати дуже різні роботи. Одному бізнесу потрібна сторінка послуги з готовими фотографіями. Іншому — багатомовний каталог, особливі правила замовлення та перенесення даних із чинної системи. Схожий перший екран не робить ці проєкти однаковими. Щоб оцінка була корисною, потрібно домовитися, що саме ви отримаєте та за якими ознаками прийматимете роботу.
На цій сторінці пояснюємо логіку бюджету без універсальної ціни на будь-яке завдання. Конкретну суму, строк, валюту розрахунку та умови оплати фіксуємо для погодженого обсягу. Якщо під час обговорення виникають додаткові потреби, їх слід показати окремо. Так простіше порівняти варіанти й вирішити, що робити зараз, а що перенести на наступний етап.
Що впливає на оцінку сайту
Кількість сторінок — лише одна складова. Важливо, скільки різних типів сторінок потрібно спроєктувати, які матеріали вже готові та хто надалі ними керуватиме. Десять однотипних карток послуги можуть потребувати меншої проєктної роботи, ніж кілька сторінок із різними сценаріями. Окремо оцінюються форми, пошук, фільтри, кабінети та підключення до інших систем.
На бюджет також впливають мови, стан існуючого сайту й вимоги до перенесення. Готові тексти треба перевірити на відповідність структурі; фотографії — підготувати для використання. Якщо матеріалів немає, їх створення стає частиною окремої роботи. У пропозиції корисно розділяти дизайн, розробку, контент, міграцію та перевірку, щоб зрозуміти причину кожного обсягу.
Лендинг і сайт компанії
Лендинг доречний для одного зрозумілого повідомлення та обмеженого набору дій. Це може бути конкретна послуга, продукт або запуск. Його бюджет залежить від складності подачі, готовності матеріалів на підтвердження досвіду й потрібних функцій. Одна довга сторінка зі складною інтерактивністю не обов'язково є простішою за невеликий багатосторінковий сайт.
Сайт компанії часто має кілька аудиторій, послуги, портфоліо й інформацію про співпрацю. У цьому випадку потрібно продумати переходи між розділами та спосіб оновлення даних. Для першої оцінки достатньо назвати основні напрями й показати приклади матеріалів. Остаточний перелік сторінок з'являється після того, як зрозуміло, яке питання покупця закриває кожна з них.
Бюджет інтернет-магазину
У магазині значна частина роботи пов'язана з товарними даними й оформленням покупки. Простий асортимент, товари з варіантами, гуртовий продаж і персональні умови потребують різної логіки. На оцінку впливають категорії, фільтри, кількість мов, завантаження товарів та правила взаємодії з обліком. Потрібно окремо назвати, хто готує назви, характеристики, фотографії й описи.
Оплата, доставка й зовнішні додатки також можуть створювати регулярні витрати. Їхні умови залежать від обраної платформи, країни й облікових записів бізнесу. Перш ніж погоджувати рішення, корисно перевірити не тільки можливість підключення, а й те, як ним користуватиметься команда. Розробка магазину та щоденне виконання замовлень — різні види роботи, їх не слід змішувати в кошторисі.
Три обсяги брендингу
Логотип — основний знак і погоджений комплект його версій. Айдентика в нашому пакеті включає логотип, кольори, типографіку та систему застосування на визначених носіях. Повний брендбук включає логотип, айдентику, правила й приклади використання. Різниця вартості пов'язана з кількістю рішень, які потрібно розробити й підготувати для подальшої роботи.
Бренд із готовою візуальною основою може потребувати іншого складу: оновлення носіїв, впорядкування файлів або документування наявних правил. Не потрібно повторно оплачувати створення знака лише тому, що послуга називається брендбуком. Спочатку визначаємо стан матеріалів і потрібний результат. Окремо погоджуються носії, ліцензійні матеріали, обсяг підготовки до друку та інші спеціальні потреби.
Оцінка автоматизації та CRM
Для автоматизації важливо описати операцію, а не лише назвати інструмент. Звідки надходять дані, хто їх перевіряє, яка подія запускає дію та що означає правильний результат. Передача заявки в готову CRM відрізняється від створення нової системи з ролями, кабінетами й звітами. Чим більше винятків і залежностей, тим більше роботи потребують реалізація та перевірка.
У вартості AI-рішення варто розділяти підготовку, налаштування, тестування й подальші платежі постачальникам. Використання моделі або стороннього сервісу може залежати від обсягу даних і кількості операцій. Для першого пілота корисно погодити обмежене завдання, способи зупинки та критерії продовження. Це дає можливість оцінити практичну користь до розширення системи.
Разовий проєкт і регулярні витрати
Окрім розробки, бізнесу можуть бути потрібні домен, хостинг, підписка платформи, платні додатки, шрифти або зовнішні сервіси. Їхній перелік залежить від рішення. У пропозиції варто показати, які платежі входять у роботу команди, які сплачуються стороннім постачальникам і хто контролює продовження. Це допомагає оцінити загальне утримання, а не лише запуск.
Підтримка також потребує визначення. Оновлення матеріалів, технічне обслуговування, виправлення помилок і розробка нових функцій мають різний зміст. Умови доступності, обсяг робіт та спосіб звернення погоджуються окремо. Не слід вважати безстрокове виконання будь-яких змін включеним лише тому, що сайт створювався на замовлення. Чіткий перелік зручніший для обох сторін.
Як порівняти дві пропозиції
Перш ніж дивитися на підсумкову суму, зіставте склад. Чи входять мобільна версія, тексти, заповнення каталогу, додаткові мови й перенесення старих адрес? Хто надає фотографії? Як визначена готовність і що відбувається після передачі? Відсутня в одному документі робота може пояснювати різницю ціни краще, ніж абстрактна оцінка «дорого» або «дешево».
Для зручного порівняння можна виписати спільний перелік:
- Результат і точний склад сторінок або функцій.
- Матеріали, які готує замовник і виконавець.
- Межі правок і спосіб погодження змін.
- Залежності від доступів та зовнішніх сервісів.
- Перевірка, передача файлів і керування.
- Регулярні платежі та умови подальшої роботи.
Цей перелік не замінює договір, але допомагає поставити правильні питання до початку проєкту.
Як зменшити перший обсяг без втрати сенсу
Бюджет можна планувати через послідовність результатів. Для сайту спочатку виділити основну пропозицію, потрібні докази й контактний шлях. Для магазину — асортимент і спосіб покупки, які реально готові до запуску. Для автоматизації — одну повторювану операцію з доступними даними. Так перша версія має завершену задачу, а наступні роботи додаються свідомо.
Не варто скорочувати лише перевірку або залишати невизначеними важливі залежності. Краще відкласти окрему функцію, ніж включити її назву без зрозумілого виконання. Якщо дата прив'язана до події, про неї корисно повідомити на початку. Тоді можна обговорити реалістичний склад першого запуску, не перетворюючи попереднє побажання на непідтверджену обіцянку строку.
Як погоджувати зміни в обсязі
Під час роботи можуть з'являтися нові ідеї. Корисно відразу розрізняти уточнення погодженого результату й окрему функцію, якої не було в початковому складі. Наприклад, виправлення помилки в готовій формі та додавання нового кабінету потребують різного підходу. Для зміни варто описати її причину, потрібний результат і вплив на інші частини проєкту.
Далі можна оцінити додаткову роботу та вирішити, чи включати її в поточний етап. Так бюджет залишається керованим, а команда не підміняє одне завдання іншим без спільного розуміння. Прозорий перелік змін також допомагає зберегти початкову мету, коли варіантів розвитку стає більше.
Що надіслати для оцінки
Опишіть бізнес, основну аудиторію та бажаний результат. Додайте чинний сайт, кілька прикладів, перелік потрібних мов і матеріалів, які вже маєте. Для магазину корисний зразок товарних даних; для автоматизації — коротка схема поточного процесу. Орієнтовний бюджет допоможе запропонувати відповідний масштаб, а не здогадуватися, які варіанти для вас прийнятні.
Після уточнення можна порівняти кілька складів і визначити пріоритет. Остаточна пропозиція має давати відповідь не лише «скільки», а й «за що», «що потрібно від нас» та «як перевіримо результат». Саме з цього починається керований проєкт, у якому очікування власника й робота команди описані однаково.