Як запустити комерційний сайт без розробника
Шість уроків із реального B2B-проєкту: від технічного завдання для ШІ до оптимізації під пошук у ChatGPT.
- Задача
- Запустити комерційний B2B-сайт для преміального медичного обладнання без розробника в команді.
- Обмеження
- Один виконавець, робота уривками між іншими задачами, нуль рядків коду, написаних руками.
- Результат
- Сайт у продакшні за півтора-два місяці, оцінка зовнішнього аудиту 7,2 з 10.sylfirmx.com.ua →
Сайт для дорогого медичного обладнання. Розробника в проєкті не було. Це мій перший сайт, зроблений повністю мною і ШІ: без студії, без фрилансера, без жодного рядка коду, написаного моїми руками.
Розкажу коротко, як це було. І віддам шість речей, які можна забрати собі й використати завтра, незалежно від того, робите ви сайт чи ні.
Що за проєкт
Продукт: Sylfirm X, RF-мікронідлінговий апарат корейського виробництва. Преміум-сегмент, для клініки це серйозна інвестиція, а не покупка між справами.
Сайт sylfirmx.com.ua зроблений не для пацієнтів. Аудиторія: власники клінік естетичної медицини й лікарі-дерматологи. Тобто люди, які ухвалюють рішення про інвестицію в обладнання і які професійно вміють ставити незручні питання.
Це не сторінка для імпульсної покупки. Це digital-актив для угоди з циклом у кілька місяців.
Стек: Next.js 14, TypeScript, Tailwind, статичний експорт, інтеграція з CRM через PHP-проксі. Я не вмію писати на жодній із цих технологій.
Від старту до запуску пройшло півтора-два місяці. Але це не був виділений проєкт: робота йшла уривками, між іншими задачами. Тобто це не «півтора місяця по вісім годин», а півтора місяця, з яких реальної роботи набралося б значно менше.
Команда була. Просто в ній була одна людина
Це важлива деталь, яку зазвичай не проговорюють.
Над сайтом працювали троє:
- я: постановка задач, структура, всі тексти, рішення й приймання роботи;
- Клод у чаті: обговорення архітектури, формулювань і спірних рішень до того, як щось пишеться;
- Claude Code: виконання, тобто код, збірка, правки у файлах.
На фінальному рев’ю до процесу підключився ще й ChatGPT у ролі зовнішнього перевіряльника.
Найцікавіше почалося саме тут. Учасники контролювали одне одного і справді ловили одне одного на помилках. Причому більшість зауважень виконавець приймав як доречні. Це не «моделі посварилися», а нормальний робочий розбір, після якого щось виправлялось.
Найчесніша формула моєї ролі звучить так:
Я не писав код. Я писав технічні завдання, приймав роботу і відповідав за результат. Просто виконавцем був не підрядник, а ШІ-агент.
Тобто я робив рівно те, що робить проджект-менеджер. І тут головне спостереження всього кейсу: роль людини нікуди не поділася. Вона стиснулась до того, що не автоматизується. Рішення, смак, знання ніші й відповідальність.
Тепер корисна частина.
Урок 1. Найважливіша секція технічного завдання називається «Чого НЕ робити»
Люди думають, ніби промпт про те, що просити. Насправді половина якості в тому, що заборонити.
Без цієї секції ШІ-агент починає покращувати те, про що його не просили: перейменовує змінні, «оптимізує» сусідні компоненти, змінює структуру файлів. Ви просили поправити кнопку, а вам переписали півсторінки.
З нею робить рівно те, що замовлено.
Робоче ТЗ у мене виглядало так:
- точні шляхи до файлів і приблизні номери рядків
- команди для самоперевірки, щоб агент сам себе перевірив
- структурований формат звіту про виконане
- секція «Чого НЕ робити»
І ще одне контрінтуїтивне: короткі прямі завдання працювали краще за детальні покрокові схеми з чекпоінтами. Складна інструкція дає складну поведінку.
Що забрати собі: це працює не тільки з ШІ. Спробуйте додати блок «чого не робити» в наступне ТЗ підряднику. Кількість зайвої ініціативи впаде вдвічі.
Урок 2. Зміст затверджується до коду
Тексти кнопок, структура футера, копірайт кожної секції: усе узгоджувалось до того, як писався хоч рядок коду.
Причина проста й неромантична. Правка в тексті тягне за собою правку в коді. Якщо ви міняєте формулювання після верстки, цикл множиться. Один абзац, і поїхала вся сітка секції.
Що забрати собі: зміст це не «наповнення». Це креслення. Спочатку домовтеся, що ви говорите, і тільки потім вирішуйте, як це виглядає.
Урок 3. Один ШІ має перевіряти іншого
Модель, яка написала код, найгірше підходить на роль його рецензента. Вона перевіряє себе в тій самій логіці, в якій помилилась.
Тому в проєкті було розділення: одна модель обговорює й формулює, друга виконує, а третя на фінальному рев’ю приходить збоку й дивиться свіжим оком. У ролі третьої був ChatGPT.
Це працює не тому, що якась модель розумніша. А тому, що в неї немає в контексті всієї історії проєкту, і в неї немає інерції «ми ж домовились так». Вона просто бачить результат і каже, що в ньому не так.
І, чесно кажучи, ловила справді по суті.
Що забрати собі: якщо ви питаєте ШІ «перевір, будь ласка, що ти щойно зробив», ви отримаєте ввічливе «все чудово». Відкрийте другий чат, бажано в іншого провайдера, дайте туди результат без передісторії й попросіть знайти слабкі місця. Це найдешевший спосіб підняти якість, який взагалі існує.
Урок 4. Я прибрав з таблиці порівняння всі хрестики. Вона стала продавати краще
Це та частина, у яку вкладено найбільше годин, а видно її найменше.
На сайті є таблиця порівняння з чотирма конкурентами: Morpheus8, Secret RF, Vivace, Virtue RF. Тринадцять параметрів. Тобто десятки клітинок, кожну з яких треба чимось обґрунтувати.
Стандартний підхід виглядає так: у нас галочки, у них хрестики. Я зробив інакше. Три позначки замість двох:
| Позначка | Значення |
|---|---|
| ● ✓ | Застосування підтверджене протоколом виробника |
| ○ ✓* | Технічно можливо, але off-label, відповідальність на лікарі |
| прочерк | Функції немає |
Ніде не написано «конкурент не вміє». Написано, де є протокол виробника, а де лікар бере відповідальність на себе.
Різниця здається косметичною. Вона не косметична.
Щоб заповнити таблицю в такій логіці, не можна взяти маркетингові сайти конкурентів і переписати з них. Треба піти в офіційну документацію виробників, у зареєстровані показання, у клінічні протоколи, і на кожну клітинку відповісти на питання «а звідки я це знаю». Там, де протокол є, ставиться перша позначка. Де апарат фізично може, але виробник цього не заявляє, друга. Де не може, прочерк.
Це довго. Це найнудніша частина проєкту. І це єдина частина, яку я не став би скорочувати.
Чому це працює: сайт читають лікарі. Що вища кваліфікація людини, то гірше на неї діє категоричність. Агресивне порівняння викликає не довіру, а бажання перевірити. А таблицю, у якій немає жодного оцінного судження, не соромно показати юристу клієнта.
Що забрати собі: чесне порівняння продає краще за виграшне. І це переноситься на будь-який бізнес, не тільки на медтех.
Урок 5. Сайт оптимізований не тільки під Google. Під ШІ теж
Ось тут найсвіжіша частина, і про неї поки мало хто думає.
Власник клініки у 2026 році все частіше не гуглить. Він питає ChatGPT або Perplexity: «який RF-мікронідлінговий апарат взяти в клініку», «Sylfirm X проти Morpheus8, що вибрати». І отримує готову відповідь із двома-трьома джерелами.
Питання просте: ваш сайт серед цих джерел чи ні?
Це називають GEO, generative engine optimization. Логіка інша, ніж у класичному SEO. Пошуковик веде людину на сторінку. ШІ витягує з неї фрагмент і переказує своїми словами. Тому й оптимізуєш ти не позицію, а придатність до цитування.
Що конкретно зроблено на сайті:
Заголовки у формі реального питання. Не «FAQ», а «Питання, які ставлять лікарі перед покупкою». Не «Про технологію», а формулювання, під яким видно, на що саме відповідає секція. ШІ значно охочіше цитує заголовок, який збігається з тим, як людина справді питає.
Самодостатні абзаци. Кожен блок має читатися окремо, без контексту сусідніх. Бо модель забирає фрагмент, а не сторінку. Якщо ваш абзац починається зі слів «як ми вже писали вище», його не процитують ніколи.
Розмітка schema.org (JSON-LD). FAQPage, Product, Organization. Без неї FAQ на сторінці технічно є, але для машини він структурно невидимий.
llms.txt і робота з ботами. Окремий файл із коротким машиночитним описом продукту плюс явні дозволи для ШІ-краулерів у robots.txt. Дрібниця, яку роблять одиниці.
FAQ, зібраний із реальних заперечень. Не вигадані питання «для SEO», а те, що справді питають на дзвінках, включно з питанням про окупність. Шість запитань, і на кожне пряма відповідь у перших двох реченнях.
І найкрасивіше в цій історії ось що.
Головним GEO-активом сайту виявилась та сама чесна таблиця порівняння. Коли хтось питає ШІ «Sylfirm X проти Morpheus8», модель шукає структуроване порівняння з фактами. Не рекламу. Факти з умовами й застереженнями.
Тобто рішення, яке я ухвалив із поваги до лікарів, виявилось найсильнішим технічним рішенням для видимості в ШІ. Чесність і GEO збіглися. Модель погано переказує вихваляння і чудово переказує таблицю, де видно, звідки взята кожна клітинка.
І зворотний бік: якщо структурованого порівняння немає у вас, ШІ візьме його в конкурента. І переказуватиме його версію.
Що забрати собі: зайдіть у ChatGPT і поставте три питання, які ставить ваш клієнт перед покупкою. Подивіться, чиї сайти в джерелах. Це п’ять хвилин і дуже протверезна вправа.
Урок 6. Сайт це не тільки трафік
Після запуску виявилось, що сайт працює наполовину.
Він добре робив те, чого від нього чекали: приводив заявки. Але був другий режим, про який ми просто не подумали. Це коли менеджер відкриває сайт разом із клієнтом під час дзвінка чи зустрічі й веде його по розділах. Цей режим не використовувався взагалі.
Під нього довелося зробити окремий документ: сценарій розмови по сайту. Що показувати власнику клініки, а що лікарю, у якому порядку відкривати секції, як користуватися таблицею порівняння в діалозі.
Що забрати собі: у вашого сайту є другий читач, і це ваш власний відділ продажів. Спитайте менеджерів, чи відкривають вони сайт на дзвінках. Якщо ні, ви оплатили половину активу.
Аудит робив ChatGPT. Вийшло 7,2 з 10
Після запуску я попросив ChatGPT розібрати готовий сайт у п’яти ролях: маркетолог, UI/UX, SEO, продажник і лікар.
| Роль рецензента | Оцінка |
|---|---|
| Маркетолог | 8/10 |
| UI/UX | 7/10 |
| SEO | 6/10 |
| Продажі | 7/10 |
| Погляд лікаря | 7/10 |
| Загалом | 7,2/10 |
Вердикт: переробляти з нуля не треба, каркас і позиціонування сильні. Основні зауваження стосувались не дизайну, а надлишку інформації й надто категоричних формулювань в окремих місцях.
Частину правок я прийняв. Частину свідомо відхилив, бо не кожна рекомендація підходить конкретному бізнесу, і це нормально.
Одразу зніму очевидне питання: це не заміна аудиту від живого фахівця. Модель не знає вашого ринку, не бачила ваших клієнтів і не несе відповідальності за пораду.
Але як перший прохід це працює несподівано добре, і рівно з тієї причини, про яку йшлося в Уроці 3. Сайт будувався в одному сімействі моделей, а перевіряло його інше. У перевіряльника не було в контексті ні наших домовленостей, ні історії компромісів, тільки готовий результат. Тому він спокійно тицяв туди, куди я вже дивитися не міг.
Цифру публікую як є. Кейс без слабких місць перестає бути кейсом і стає рекламою.
Скільки це коштувало
Український ринок сьогодні: кастомний B2B-сайт такого обсягу (11 секцій, інтеграція з CRM, унікальні тексти в технічній ніші) коштує у студії приблизно $3 000–7 000. Плюс копірайтинг, бо технічний текст для лікарів звичайний копірайтер не напише.
Мої витрати: підписка на інструмент, хостинг і домен.
Тут чесно варто назвати й третій варіант, бо я сам ним колись користувався. Це зібрати на WordPress. Компроміс: дешевше за повну розробку, швидше на старті, є кому підхопити. Але за це платиш.
Платиш чужим кодом, який ти не контролюєш. Стосом плагінів, кожен з яких колись зламається або оновиться не вчасно. І головне, платиш швидкістю завантаження. Складений із плагінів сайт майже завжди важкий, і на мобільному це видно одразу.
Для B2B це не косметика. Власник клініки відкриває ваш сайт із телефону між пацієнтами. Якщо сторінка думає три секунди, він її вже закрив, і жодна ваша аргументація не спрацювала, бо він її просто не побачив.
Але грошова різниця тут узагалі не найцікавіше. Цікавіше інше.
У 2020 році такий самий сайт у студії коштував би приблизно стільки ж. Різниця не в ціні. Різниця в тому, що тоді варіанта «зробити самому нормально» не існувало за жодні гроші. Або ти платиш підряднику, або збираєш конструктор і миришся з його обмеженнями. Третьої опції не було.
Зараз вона є. І головний виграш тут не економія, а контроль: правка вноситься тоді, коли вона потрібна, а не тоді, коли в підрядника звільнився розробник.
Що я з цього зрозумів
Не «ШІ зробив сайт замість людини». Це неправда, і будь-хто, хто пробував, це знає.
ШІ забрав виконання. Він не забрав постановку задачі, знання предметної області, смак і відповідальність за те, що вийшло. Тобто все, за що насправді платять.
Проджект-менеджер не зник. Він просто залишився єдиною людиною в команді.
А ви вже перевіряли, чи згадує ШІ ваш сайт, коли клієнт питає про ваш продукт? Напишіть у коментарях, що показало. Мені цікаво, наскільки це вже болить.