Знайома історія: перший рік після запуску зміни на сайті робляться швидко. Додати блок — година, поміняти форму — пів дня. На третій рік те саме прохання раптом коштує три дні, а підрядник обережно каже, що «там усе повʼязано».
Нічого дивного не сталося. Просто настав момент платити за накопичені швидкі рішення. У розробці це називають технічним боргом, і бізнесу корисно розуміти цю механіку — вона прямо впливає на бюджет.
Звідки береться борг
Майже завжди з розумних, а не поганих рішень.
Строк важливіший за акуратність. Треба запуститися до сезону. Робиться найкоротшим шляхом — і це правильно, бо сайт, що вийшов на два місяці пізніше, коштує дорожче за будь-яку неакуратність у коді.
Правки на ходу. Під час розробки блоки додають, прибирають, повертають назад — і структура поступово перестає відповідати початковому задуму. Чому це нормально й чим керувати — у матеріалі про правки під час розробки.
Зміна підрядників. Кожен наступний робить по-своєму, не розібравшись у логіці попереднього, бо розбиратися довше, ніж дописати збоку.
Виріс бізнес. Сайт робили під сто товарів і одну форму, а зараз їх пʼять тисяч і шість інтеграцій. Рішення були правильними для того масштабу.
Все залишилося як є. Бібліотеки, платформа, версії — усе застаріває саме по собі, навіть якщо сайт не чіпали.
Як борг проявляється в рахунках
Ознаки, які видно з боку замовника, без жодної технічної експертизи:
- Оцінки ростуть на однакових задачах. Те, що торік було «пів дня», сьогодні «два-три дні».
- Правка в одному місці ламає інше. Поміняли форму — перестала працювати сторінка дякую.
- Ніхто не хоче чіпати певний блок. Про нього говорять «краще не лізти».
- Оновлення відкладаються. Бо після кожного щось відвалюється.
- Кожна зміна потребує тестування всього сайту. А це вже не години, а дні.
Якщо збіглося три пункти з пʼяти — борг перестав бути теоретичним і вже входить у ваші щомісячні витрати. З чого взагалі складається ця сума — у матеріалі про підтримку сайту.
Найдорожчий різновид: дешевий старт
Окремо варто сказати про сайти, зібрані за мінімальні гроші з набору готових доповнень. Такий сайт живе рівно доти, доки нічого не треба міняти. Перша ж нестандартна вимога впирається в те, що всередині двадцять чужих модулів, які треба узгодити між собою.
Це найшвидший спосіб накопичити борг, ще нічого не заробивши — арифметика розібрана в матеріалі про те, чому дешевий сайт виходить дорожчим.
Скільки боргу нормально
Нуль — не мета. Компанія, яка ідеально вилизує код замість того, щоб виходити на ринок, програє тому, хто запустився раніше.
Робоча пропорція проста: приблизно одна година з десяти витрачається на приведення в порядок того, що вже є. Не окремим великим проєктом раз на три роки, а потроху й постійно: разом із черговою задачею впорядкували сусідній шматок.
Це та сама логіка, що з обладнанням — планове обслуговування дешевше за аварійний ремонт.
Що просити в підрядника, щоб борг не ріс мовчки
Три речі, які варто закласти в домовленість із самого початку:
Тестовий майданчик. Зміни спершу перевіряють на копії, а не на живому сайті — тоді ризик правки менший і її не бояться робити. Як це влаштовано — у матеріалі про тестовий майданчик.
Оновлення в регламенті підтримки. Не «за потреби», а планово, з переліком того, що оновлюється.
Доступи й документація у вас. Щоб зміна підрядника не додавала ще один шар боргу. Що саме має бути передано — у матеріалі про передачу сайту, доступи й права.
Ще одна корисна практика: раз на пів року просити коротку письмову відповідь на питання «що на сайті найбільше сповільнює зміни». Технічна команда зазвичай знає це точно, її просто ніхто не питає.
Коли дешевше переписати
Рахунок нескладний. Візьміть години, які щомісяця йдуть на боротьбу з наслідками — переробки, відкати, тестування всього підряд. Помножте на вартість години. Порівняйте з вартістю переробки.
Якщо переробка окупається менш ніж за рік — вона вигідніша. Якщо за три роки — лагодьте далі, ситуація не критична.
Важливо не плутати цю переробку з косметичним оновленням вигляду: борг живе всередині, і новий дизайн поверх старої основи його не прибирає. Різницю між двома роботами розібрано в матеріалі про редизайн сайту, а вибір основи для нової версії — у матеріалі про WordPress чи Next.js.
Коротко
Технічний борг — це не аварія й не помилка підрядника, а нормальний наслідок швидких рішень. Проблемою він стає тоді, коли його ніколи не повертають: правки дорожчають, зміни бояться робити, оновлення відкладаються. Тримайте пропорцію «одна година з десяти на порядок», вимагайте тестовий майданчик і планові оновлення, а рішення про переробку ухвалюйте за строком окупності, а не за відчуттям, що «сайт застарів».
Ми в Obliko беремо на підтримку чужі сайти й починаємо з чесної оцінки, що там дешевше — лагодити чи переробити.
Що таке технічний борг простими словами?
Це накопичені швидкі рішення, які колись зекономили час, а тепер сповільнюють кожну наступну зміну. Як позика: користь отримали одразу, а платите відсотками — годинами на кожну нову правку.
Як зрозуміти, що борг уже великий?
За трьома ознаками: прості правки почали займати дні замість годин, кожна зміна ламає щось в іншому місці, а підрядник дедалі частіше відповідає «це складніше, ніж здається».
Чи можна уникнути технічного боргу зовсім?
Ні, і не треба. Частина швидких рішень виправдана — бізнесу часто важливіше запуститися вчасно. Проблема не в самому борзі, а в тому, що його ніколи не повертають.
Дешевше полагодити чи переписати заново?
Рахують просто: скільки годин щомісяця йде на боротьбу з наслідками і за скільки місяців ця сума перевищить вартість переробки. Якщо термін менший за рік — переробка вигідніша.
Потрібен сайт під ключ?
Від структури й дизайну до запуску. Домен і доступи оформлюємо на вашу компанію.