Погані сайти рідко починаються з очевидно поганого розробника. Частіше все починається з приємної розмови, красивого портфоліо й пропозиції, в якій ніхто не визначив, що саме означає «готово».
Цей гід — для власника бізнесу, який обирає фрілансера, студію або product team для корпоративного сайту, сервісу чи інтернет-магазину. Він не допоможе знайти «найталановитішого» підрядника за одну зустріч. Натомість дасть процес, за яким слабку пропозицію важко замаскувати харизмою.
Коротка відповідь: як обрати розробника сайту
Оцінюйте не смак і не кількість технологій у презентації. Оцінюйте п'ять речей: чи зрозуміла команда бізнес-задачу; які наводить докази; наскільки чітко описує scope та assumptions; як ви перевірятимете результат; що залишиться у вашій власності після завершення.
Evidence
Живі продукти, результати, references і чесна розмова про невдачі.
Scope
Deliverables, exclusions, assumptions, dependencies і change control.
Tests
Acceptance criteria, QA, security, accessibility і performance targets.
Ownership
Domain, accounts, repository, data, documentation і право піти.
До першого дзвінка напишіть brief на одну сторінку
Не починайте з «нам потрібен сучасний сайт». Напишіть: хто користувач; яку дію він має виконати; що бізнес хоче змінити; які три flows критичні; які системи потрібно інтегрувати; хто дає тексти, фото й product data; який дедлайн має реальну причину; який бюджетний коридор ви готові розглядати.
Додайте constraints: мови, ринки, privacy, payments, CRM, CMS, accessibility, migration і внутрішні approvers. Не проєктуйте рішення замість команди. Хороший brief описує проблему й межі, а не диктує 47 сторінок і конкретний JavaScript framework.
Budget range не робить вас слабшим покупцем. Без нього одна команда запропонує шаблон за два тижні, інша — research і custom platform на шість місяців, а ви порівнюватимете числа, що означають різні продукти.
23 питання до підписання договору
Стратегія й докази
- Яку бізнес-проблему ви бачите в нашому brief? Сильна відповідь переформулює задачу, а не повторює ваші слова.
- Що ви свідомо не стали б будувати у першій версії? Команда без позиції продає все; команда з досвідом захищає фокус.
- Покажіть два релевантні live-проєкти. Яка частина була вашою? «Ми працювали з брендом» не означає, що команда створила продукт.
- Що на схожому проєкті пішло не за планом? Шукайте конкретну помилку, рішення й зміну процесу, а не бездоганну легенду.
- Чи можемо ми поговорити з попереднім клієнтом? Для невеликого нового підрядника це може бути не завжди можливо, але причина й альтернативні докази мають бути чесними.
Scope, оцінка й зміни
- Які assumptions лежать під оцінкою? Наприклад: готові тексти, чисті дані, один approver, документований API.
- Що саме входить і прямо не входить у ціну? Запитайте про copy, SEO migration, analytics, integrations, browser QA, навчання, licenses і launch support.
- Хто готує та завантажує контент? «Сторінка готова» без текстів, metadata й images часто не готова до запуску.
- Що найбільше може змінити бюджет або строк? Доросла команда називає uncertainty до того, як вона перетвориться на invoice.
- Як погоджуються зміни? Потрібні короткий опис, вплив на budget/timeline і письмове approval до роботи.
Команда й робочий процес
- Хто фактично виконуватиме роботу? Попросіть імена та ролі delivery team, а не лише людей із pitch call.
- Яка їхня доступність і що буде при заміні? «Senior oversight» раз на місяць — не те саме, що senior delivery.
- Як часто ми побачимо working software? Краще demo кожні 1–2 тижні, ніж великий reveal наприкінці.
- Які рішення та матеріали потрібні від нас? У timeline мають бути client dependencies, approver і строки feedback.
Технологія та якість
- Яку platform або architecture ви радите — і чому вона відповідає нашій операційній реальності? Відповідь має пояснювати maintenance, редакторів, integrations і cost, а не моду.
- Як організовані staging, version control, review, testing і deployment? Ви повинні мати можливість подивитися версію до production і повернутися назад у разі проблеми.
- Які security requirements ви перевіряєте? Для web application попросіть risk-appropriate checklist, наприклад вимоги OWASP ASVS, management secrets, dependency updates, backups та incident process.
- Який рівень accessibility і browser/device matrix входить? Фраза «сайт доступний» слабша за перелік WCAG 2.2 criteria, manual keyboard test і screen-reader checks.
- Які performance targets зафіксуємо? Не «швидкий сайт», а вимірювані сторінки, мережеві умови, Core Web Vitals або інші узгоджені бюджети.
Власність, запуск і підтримка
- На кого оформлюються domain, hosting/cloud, repository, analytics і third-party accounts? На вашу організацію; підряднику надається потрібний рівень доступу.
- Хто володіє code, design, content і data, а що ліцензується? Попросіть список third-party themes, fonts, plugins, stock assets та умов їх використання.
- Що саме означає acceptance і як відбувається launch? Потрібні observable criteria, UAT window, відповідальні, backup/rollback і спосіб фіксації defects.
- Що відбувається після launch або termination? Warranty, support hours, SLA, maintenance price, export, documentation, credentials, knowledge transfer і final backup.
Порівнюйте пропозиції за scorecard на 100 балів
| Критерій | Вага | Що дає високий бал |
|---|---|---|
| Розуміння проблеми | 20 | Сильний diagnosis, user flows, priorities і доречні заперечення |
| Релевантні докази | 15 | Live work, точна роль, outcomes, reference, lessons learned |
| Scope та assumptions | 15 | Deliverables, exclusions, dependencies і change process без туману |
| Quality і technology | 15 | Зрозумілий rationale, QA, security, accessibility, performance |
| Команда й процес | 10 | Named team, cadence, demos, decision ownership, continuity |
| Ownership і handoff | 15 | Client-owned accounts, IP clarity, docs, export і exit plan |
| Ціна та керування ризиком | 10 | Comparable scope, milestone payments, transparent uncertainty |
Кожен reviewer ставить бали незалежно, потім команда обговорює найбільші розбіжності. Не створюйте формулу, в якій найдешевша ставка автоматично перемагає: дешевий proposal із неврахованими content, licenses і migration може мати найдорожчий фінал.
П'ять питань попередньому клієнту
Reference call на 15 хвилин корисніший за ще одну sales presentation. Не просіть загальне «вам сподобалося?». Запитайте:
- Що ви планували отримати й що реально запустили?
- Наскільки фактичні строк і бюджет відрізнилися від початкових — і чому?
- Чи працювала та сама команда, яку вам представили?
- Яким був найбільший неприємний сюрприз і як підрядник відреагував?
- Чи найняли б ви їх знову для такого самого проєкту?
Перевірте live site самостійно: mobile, forms, checkout, keyboard navigation, broken states, performance. Але пам'ятайте, що поточний стан може залежати від років змін після роботи підрядника.
Що має бути в нормальній web-development proposal
У хорошій пропозиції є короткий diagnosis, outcomes, scope, exclusions, approach, named team, timeline з client dependencies, deliverables по milestones, acceptance, price, payment schedule, change process, assumptions, ownership, warranty та ongoing costs.
Paid discovery може бути абсолютно чесною моделлю, особливо коли integrations або product logic ще не досліджені. Результатом discovery мають бути артефакти, якими ви можете користуватися: validated scope, flows, architecture decisions, risks, backlog і точніша оцінка. Не вимагайте безкоштовно спроєктувати весь продукт від кожного finalist.
Небезпечна структура платежів — «50% зараз, 50% коли сайт готовий», якщо готовність не визначена. Кращі milestones прив'язані до demonstrable outcomes: затверджений scope; tested prototype; working increment на staging; content-ready release; accepted production launch.
Що зафіксувати в договорі
Договір не врятує слабку співпрацю, але змусить сторони назвати речі своїми іменами. Перевірте з юристом вашої юрисдикції:
- deliverables, exclusions, assumptions і порядок пріоритетів між документами;
- milestones, client dependencies, review windows і acceptance criteria;
- fees, taxes, expenses, payment timing та умови pause;
- change control і хто має право затверджувати додаткові витрати;
- IP ownership, background IP, open-source і third-party licenses;
- confidentiality, personal data, subprocessors, security та incident notification;
- warranties, defects, service levels, limitation of liability;
- termination, partial work, repository, export, credentials і transition assistance.
Acceptance має описувати результат, який можна спостерігати. Наприклад: «форма створює lead у CRM з потрібними полями, показує confirmation, не дублює запис при повторному click і проходить agreed browser matrix». «Сторінка реалізована за макетом» залишає занадто багато невидимих питань.
Ваш сайт має залишатися вашим
Створіть accounts на email вашої організації: registrar/domain, DNS, cloud/hosting, Git repository, CMS, analytics, tag manager, Search Console, payment provider, email service, maps та consent tool. Дайте vendor роль, необхідну для роботи. Google прямо радить регулярно перевіряти permissions і видаляти доступ та verification tokens людей, які більше не працюють із сайтом.
| Актив | До старту | На handoff |
|---|---|---|
| Domain / DNS | Організація — registrant та owner | 2FA, billing, recovery contacts перевірено |
| Code / design | Repo у вашій org; IP terms узгоджено | Source, history, design files, licenses, build instructions |
| Infrastructure | Ваш cloud account або ясний transfer plan | Environments, backups, secrets rotation, rollback documented |
| Data / analytics | Ваші properties і data ownership | Exports, retention, permissions, tracking map |
| Operations | Owner з вашого боку | Runbook, monitoring, vendor list, maintenance calendar |
Якщо переїзд можливий лише з дозволу підрядника, це не partnership, а dependency. Google радить планувати site migration, тестувати redirects, зберігати Search Console ownership і моніторити старі та нові URLs — тому exit plan потрібен ще до першого deploy.
Десять червоних прапорців
- Відмова дати вам доступ до repository або production accounts.
- Domain і hosting назавжди оформлюються на vendor.
- 100% оплати до появи перевірюваного deliverable.
- Fixed price без assumptions, exclusions або discovery для невідомої задачі.
- «SEO включено», але немає переліку робіт, migration plan чи відповідального.
- Proprietary CMS без documented export і exit cost.
- Немає staging, backups, version control або rollback.
- На pitch є seniors, у delivery proposal команда не названа.
- Scope містить десятки features, але жодного non-goal.
- Portfolio складається зі screenshots; немає live work, outcomes чи людей для reference.
Один прапорець не завжди означає шахрайство. Він означає питання, яке треба закрити до contract, а не на четвертому місяці.
Практичний відбір за 10 робочих днів
Запросіть 3–5 кандидатів, не 15. Дайте всім однаковий brief і письмові відповіді на спільні питання. На фінальному call говоріть із delivery lead, а не лише sales. Після scorecard перевірте reference, вирівняйте scope двох фіналістів і тільки тоді порівняйте price.
Поширені питання
Кого краще найняти: фрілансера чи веб-студію?
Фрілансер часто швидший і дешевший для чіткої невеликої задачі. Студія доречніша, коли одночасно потрібні strategy, design, development, QA та continuity. Оцінюйте реальну delivery team, а не юридичну форму.
Скільки пропозицій варто отримати?
Зазвичай достатньо трьох–п'яти. Більше proposals створюють шум і забирають час, якщо brief ще не дозволяє порівнювати однаковий scope.
Скільки платити наперед?
Універсального відсотка немає. Deposit за резерв команди й старт нормальний, але наступні платежі краще прив'язати до чітких milestones і acceptance, а не календаря.
Хто має володіти сайтом, кодом і доменом?
Domain, business accounts, data та repository мають контролюватися вашою організацією. Право власності на custom work і ліцензії third-party components потрібно прямо визначити в договорі.
Як перевірити розробника сайту?
Перегляньте live projects, уточніть особистий внесок, поговоріть із delivery team і reference, попросіть описати провал, перевірте proposal за scorecard та не підписуйте без ясних acceptance і handoff.
Джерела та дата перевірки
Матеріал перевірено 16 серпня 2026 року за OWASP Application Security Verification Standard, WCAG 2.2 від W3C, supplier assurance questions NCSC, рекомендаціями Google щодо Search Console permissions та site migrations. Це практичний procurement guide, не юридична консультація.
Читайте далі: як спланувати запуск інтернет-магазину, як обрати ecommerce platform та як оцінювати бюджет custom AI development.