Часті запитання

Вартість залежить від чотирьох факторів: складності функціоналу, обсягу унікального дизайну, інтеграцій із зовнішніми системами (CRM, платіжні шлюзи, 1С/ERP, склад) та вимог до безпеки й продуктивності. Простий сайт-візитівка на готовому шаблоні коштує в рази дешевше, ніж інтернет-магазин з індивідуальною логікою каталогу — це не «накрутка», а інший обсяг інженерної роботи.

За тим самим словом «сайт» може ховатися зовсім різний продукт:

• Шаблон проти індивідуальної вёрстки — шаблон дешевший, але обмежує гнучкість.
• Фрилансер проти команди — у фрилансера нижчі накладні витрати, але немає резерву на випадок хвороби/відпустки, окремого тестувальника.
• Чи закладено тестування, SEO-базу, безпеку — дешеві пропозиції часто цього не включають, і це «спливає» пізніше як додаткові доробки.
• Чи є гарантійна підтримка після здачі проєкту.

Якщо кошторис суттєво нижчий за ринковий — варто уточнити, що саме до нього входить.

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

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

UX/UI-дизайн (прототип, макети), вёрстка, програмування (логіка та інтеграції), копірайтинг (якщо потрібен), тестування. У різних підрядників різне співвідношення цих статей — в одних копірайтинг винесено окремо, в інших входить у пакет.

Так, це стандартна практика: аванс перед стартом (зазвичай 30–50%), оплата після завершення ключових етапів (дизайн, розробка), фінальний платіж після приймання та запуску.

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

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

Сайт-візитівка — 1–3 тижні, сайт середнього рівня з каталогом — 4–8 тижнів, портал чи інтернет-магазин з інтеграціями — від 2–4 місяців. Точний термін фіксується після затвердження ТЗ.

Аналітика та збір вимог → прототип (wireframe) → дизайн → вёрстка → програмування та інтеграції → тестування → запуск → передача доступів клієнту.

Через регулярні демонстрації проміжних результатів (раз на 1–2 тижні), доступ до тестового сервера (staging-версії) та виділений канал зв'язку.

Логотип і брендбук (якщо є), тексти або бриф для копірайтера, фото/ілюстрації, доступи до вже наявних систем (якщо є), список потрібних інтеграцій.

Можна, але «красиво» у кожного своє, тому перший етап все одно потрібен — просто він буде коротшим і спиратиметься на приклади, а не на довгу анкету. Ми зазвичай просимо 3–5 референсів (сайтів, які подобаються візуально), кілька слів про те, для кого сайт, і будь-які матеріали бренду, якщо вони є. Далі показуємо 1–2 варіанти напрямку дизайну, перш ніж заглиблюватися в деталі — так смак клієнта прояснюється швидше, ніж через текстове ТЗ.

• SaaS-конструктори — швидкий старт для лендингів без складної логіки, але залежність від платформи.
• WordPress — найбільша екосистема плагінів, низький поріг входу. Мінус — якість і безпека сторонніх плагінів сильно варіюються, а їх нагромадження з часом уповільнює сайт.
• Joomla — суворіша і передбачуваніша архітектура «з коробки» (див. наступне запитання).
• Drupal — найгнучкіший варіант для складних корпоративних систем, але потребує більш кваліфікованої команди і дорожчий у розробці.

1. Вбудована багаторівнева система прав доступу (ACL). Розмежування прав за групами, категоріями та окремими матеріалами є «з коробки», на відміну від WordPress, де це зазвичай потребує плагінів. Зручно для сайтів із кількома відділами або підрядниками з обмеженим доступом.
2. Багатомовність без сторонніх плагінів. Вбудована в ядро, тоді як у WordPress майже завжди потрібен платний плагін (WPML, Polylang Pro).
3. Суворіша структура контенту. Категорії, теги й типи матеріалів організовані ієрархічно на рівні ядра. Зручно для каталогів, порталів, держструктур, об'єднань філій.
4. Менше, але однорідніша якість розширень. Компактніша за WordPress, але завдяки цьому менше «сміттєвих» і покинутих розширень.
5. Затребувана в держсекторі та НКО-проєктах. Завдяки ACL і стабільності багато державних і освітніх установ у Європі використовують саме Joomla.

Важливе застереження: Joomla — не «краща загалом», а краща для конкретного класу задач — сайтів зі складною структурою контенту, багатьма ролями та потребою в багатомовності без переплати за плагіни. Для простого блогу чи лендінгу розумніше обрати WordPress або SaaS-рішення.

Так, ми працюємо з вибором клієнта, якщо платформа адекватна завданню. Якщо бачимо, що обрана CMS погано підходить під ваші цілі (наприклад, для інтернет-магазину з великим каталогом обрано платформу без нормального управління товарами), — скажемо про це заздалегідь і пояснимо, в чому ризик, але фінальне рішення завжди залишається за клієнтом.

Сам рушій не є менш безпечним — проблема частіше в екосистемі: через величезну кількість сторонніх плагінів різної якості ризик встановити вразливий компонент статистично вищий. Але в обох випадках безпека на 90% залежить від дисципліни оновлень і якості налаштування, а не від самої CMS.

Так, адаптивна вёрстка — стандарт: у більшості сайтів понад половину трафіку йде з мобільних пристроїв.

Так, усі сучасні CMS дають адмін-панель для редагування без програмування. Зручність залежить від того, наскільки продумано налаштовані поля редагування — це варто обговорювати на етапі ТЗ.

Базовий набір: регулярні оновлення CMS і розширень, SSL-сертифікат, захист форм від спам-ботів, обмеження спроб входу в адмінку, резервне копіювання. Для вимогливіших проєктів — Web Application Firewall і періодичний аудит безпеки.

Базова SEO-підготовка — чисті URL, мета-теги, швидкість завантаження, структура заголовків, sitemap — має закладатися на етапі розробки: переробляти потім дорожче. Повноцінне просування (контент-стратегія, посилальна маса) — зазвичай окрема послуга.

Багато студій проводять короткий конкурентний аналіз перед проєктуванням структури сайту — це допомагає не повторювати чужі помилки. Глибина аналізу залежить від пакета послуг.

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

Сам по собі сайт — це інструмент, а не джерело трафіку. Продажі з'являються, коли на сайт приходять потрібні люди: через рекламу, SEO, соцмережі, розсилки чи офлайн-канали. Ми можемо закласти в сайт усе для конверсії (зрозумілі форми, швидке завантаження, коректну аналітику), але обіцяти конкретні цифри продажів «із завтрашнього дня» — нечесно щодо клієнта, бо це залежить від десятків факторів, включно з нішею, конкуренцією та бюджетом на просування.

На більшість проєктів поширюється гарантійний період (1–3 місяці), протягом якого виправлення помилок розробки — безкоштовне. Подальша техпідтримка оформляється окремим договором.

Найчастіші причини: закінчився домен або хостинг (не продовжили вчасно), закінчився SSL-сертифікат, автооновлення плагіна/CMS конфліктує з іншими компонентами, змінився зовнішній сервіс, з яким була інтеграція (платіжний шлюз, API карт, соцмережі), або хостинг не впорався з різким сплеском трафіку. Гарна новина: більшість таких причин виявляється за кілька хвилин діагностики й вирішується швидко — саме для цього і потрібні моніторинг та договір на підтримку.

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

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