Пастка дешевої розробки. Скільки насправді бізнесу коштує економія на технічному стеку на старті
Сергій Колозенко — фаундер та CEO Megasite, компанії, що займається веброзробкою та створенням digital-рішень для бізнесу.
У цій колонці він пояснює, де бізнес втрачає контроль над бюджетом у розробці, як уникнути цього ще на старті проєкту і чому економія на початку часто призводить до більших витрат у процесі.
Різниця вартості розробки в чесному бюджеті та на фрілансі
Коли бізнес хоче зекономити на розробці, найчастіше він обирає фріланс. Це виглядає логічно, адже ціна нижча, старт швидший і менше формальностей. Проте основне, що варто розуміти, це те, що коли ви звертаєтесь до аутсорс-компанії, ви отримуєте гарантію. Адже фрілансер не так сильно ризикує репутацією, якщо після виконаної роботи не візьме слухавку, не внесе правки, чи взагалі зникне. В той час як клієнт залишиться один на один з сайтом, і не факт, що з діючими доступами.
До прикладу, за 15 років роботи в MEGASITE дуже часто зверталися компанії, які приходили після фрілансерів і в усіх дуже схожа історія. Якийсь спеціаліст на фрілансі зробив сайт і наче все було непогано, але в один день ця людина переїхала за кордон, вимкнула телефон і контакту з нею немає. Так само, як немає жодних доступів до сайту. Ні до хостингу, ні до домену. І до нас завжди звучить одне питання: чи ми можемо допомогти в такому випадку? Відповідь — ні. Якщо немає доступів, ми не можемо нічого вдіяти.
Говорячи про більш технічні моменти, варто згадати якість продукту, котрий клієнт отримує на виході. Адже спеціаліст на фрілансі фізично не може зробити роботу, яку робить ціла компанія і команда, де працює більше ніж одна людина, де налагоджені процеси, а досвід компанії — це сума досвідів кожного співробітника. Тому на виході продукт буде якіснішим. Це і правильна архітектура продукту, і сучасний технологічний стек, і подальша безпека сайту, і готовність до SEO, і оптимізація швидкості, і наявність документації, і зрозуміла структура для подальшого розвитку. У випадку звернення до фрілансера цього всього, як правило, не буде. Так само, як і не буде гарантії, що завтра щось не зміниться.
Тому економія на старті часто обертається значно більшими витратами в майбутньому.
Технічні обмеженнями, з якими зіштовхується бізнес через пів року після запуску «дешевого» сайту
Підписуйтеся на наші соцмережі
Якщо архітектура проєктування є непродуманою, надалі сайт неможливо масштабувати. Не буде можливості додавати додатковий функціонал, або додавати інтеграції із зовнішніми сервісами. Це головні обмеження, з якими може зіштовхнутися клієнт, який вирішив обмежитися простим та дешевим сайтом, створюючи його як одноразовий продукт. Такий сайт має право на існування, втім функціонувати він може лише без подальшого розширення.
Як застарілий або неякісний Legacy code перетворюється на постійний фінансовий «податок» для бізнесу
Підтримка дешевого сайту в довгостроковій перспективі коштує дорожче, ніж розробка якісного продукту. Якщо сайт зроблено незрозуміло як на застарілому стеку, команді знадобиться значно більше часу, щоб зробити будь-яке доопрацювання або виправити помилку. Багато часу йде на аналіз, розуміння системи та пошук рішення.
Наприклад, у роботі MEGASITE ми часто зіштовхуємося із ситуаціями, коли на застарілій системі навіть проста задача займає близько шести годин. Цей час команда витрачає на аналіз, пошук і розуміння того, як усе працює і як це правильно реалізувати. У новій системі такого етапу майже немає, адже спеціалісти одразу розуміють, як впровадити рішення. Тобто на новому стеку це може зайняти одну годину, тоді як на застарілому — п’ять-шість, а інколи й більше.
Економія на технічній оптимізації та швидкості завантаження сайту збільшує вартість кожного кліка в Google Ads
Вартість ліда напряму залежить від якості сайту. Уявімо ситуацію, де потенційний клієнт переходить із реклами на сайт, і не може знайти форму заявки, чи сторінка довго завантажується або сайт некоректно відображається, наприклад, на певній моделі iPhone. Що користувач робить в такій ситуації? Йде до конкурента. І все це означає, що маркетинговий бюджет витрачається даремно, адже оплата відбувається за кожен клік.
Якщо ж сайт якісний, швидко завантажується, має зрозумілу структуру і функціонал, тоді переходи з реклами краще конвертуються в ліди, а вартість ліда відповідно стає нижчою.
Ціна економії на безпеці сайту: витік бази клієнтів або зупинка сайту у розпал сезону продажів
Причин, через які сайт може перестати працювати, насправді дуже багато. Іноді проблема виникає через некоректно побудовану архітектуру сайту, якщо він спочатку був неправильно спроєктований і не розрахований на велике навантаження, при зростанні трафіку сервер може просто не витримати, і сайт перестає працювати.
Проблема може бути і на стороні хостингової компанії. Таке трапляється доволі часто, і тоді залишається чекати, поки провайдер відновить роботу сервера. Є також сервіси захисту, наприклад Cloudflare, які встановлюються для запобігання DDoS-атакам. Іноді збій відбувається саме на стороні такого сервісу, і через це сайт теж стає недоступним. Буквально нещодавно ми вирішували подібну ситуацію в MEGASITE.
Як власнику, який не є технічним спеціалістом, на етапі тендеру розпізнати «дешеву пастку»
Перше, на що варто звернути увагу, це сайт компанії, до якої ви звертаєтеся. Наскільки він добре виглядає, як працює, чи є на ньому баги. Це обличчя компанії. Якщо вони не можуть зробити нормальний сайт для себе, виникає питання, чи зможуть зробити хороший продукт для вас.
Друге, подивіться, з ким вони працювали і яке в них портфоліо. Які проєкти вони зробили, як виглядають ці сайти і чи якісно вони працюють.
Третє, почитайте відгуки клієнтів. Їх легко знайти в Google Business, у соціальних мережах або просто через пошук. Подивіться, що пишуть про компанію, яка в неї репутація на ринку, скільки задоволених і незадоволених клієнтів. Також варто звернути увагу на рейтинги компаній, нагороди або інші досягнення. Це теж показує рівень компанії.
Ще один важливий момент – ставити конкретні технічні питання, щоб зрозуміти, наскільки професійно компанія підходить до проєкту. Наприклад:
- Яку архітектуру ви пропонуєте і як вона дозволить масштабувати продукт через 2–3 роки?
- Який технічний стек ви використовуєте і чому саме його?
- Які заходи безпеки будуть реалізовані на сайті?
- Як буде побудована інтеграція з CRM, платіжними системами та маркетинговими інструментами?
- Чи буде документація по проєкту і чи можна буде передати цей проєкт іншим розробникам?
Я думаю, цих питань буде достатньо, щоб визначити технічний рівень підрядника. І якщо на цьому етапі немає чітких відповідей, краще не починати роботу, ніж потім виправляти наслідки «дешевої» розробки.