Одна компания для разработки и поддержки сайта: когда это ускоряет бизнес, а когда делает вас зависимыми

Идея разделить разработку и поддержку между двумя подрядчиками звучит разумно, пока не случается сбой. Потом один пишет, что проблема в чужом коде, второй просит доступы, а сайт в это время теряет заявки. У нас был такой проект в e-commerce: в пятницу вечером форма заказа перестала отправлять данные в CRM, и пока две команды выясняли, где сломалось - в Laravel 11, webhook или самой CRM, бизнес потерял почти 17 часов.

С тех пор я смотрю на это проще: вопрос не в количестве подрядчиков. Вопрос в цене управления схемой, в скорости реакции на инциденты и в том, можно ли сменить исполнителя без остановки продаж.

Скорость поддержки почти всегда упирается в контекст

В сопровождении сайта дольше всего занимает не сам фикс, а понимание того, где лежит логика, кто менял интеграцию, почему платежный модуль подключен именно так и что заденет правка рядом. Новый подрядчик на это легко тратит 2-6 недель, даже если проект не выглядит сложным.

Когда сайт делает и поддерживает одна команда, этот контекст уже собран. На задачах, которые напрямую бьют по деньгам, разница видна сразу: корзина, лид-формы, SEO-страницы, акции, личный кабинет, обмен с CRM. На одном проекте правка логики корзины у нашей команды заняла 3 дня, а новый подрядчик до старта работ запросил аудит PostgreSQL 16, платежного шлюза и связки с amoCRM.

Разве скорость зависит только от числа разработчиков?
Нет. В поддержке узкое место - объем контекста и доступов. Один инженер, который знает проект и может открыть Git, логи и staging, часто полезнее команды, которая видит систему впервые.

Одна команда убирает споры на стыках. Зависимость тоже растет быстро

Самая частая проблема при разделении - пинг-понг ответственности. Один подрядчик говорит, что код работает. Второй отправляет проверять сервер. Бизнесу от этого не легче: форма не пишет лиды, корзина считает скидку с ошибкой.

Единый подрядчик снимает половину таких историй. Он отвечает за архитектуру, релиз и последствия в одном контуре. У нас был клиент из медицины, сеть частных клиник: старый WordPress дорабатывали годами через FTP, а поддержку держали у другой команды. Критичный баг в записи к врачу закрывали 9 дней. После переноса в Git, настройки staging и одной зоны ответственности похожие инциденты стали закрываться за 1-3 дня.

Но здесь есть ловушка. Если доступы, документация и порядок передачи проекта живут только у студии, удобная модель быстро превращается в жёсткую зависимость от подрядчика.

Я проверяю несколько красных флагов сразу:

• у бизнеса нет доступа к домену, VPS и DNS
• Git-репозиторий оформлен только на подрядчика
• бэкапы нельзя скачать и поднять отдельно
• схема интеграций с CRM, почтой и CDN нигде не описана

Если смена исполнителя без остановки проекта занимает больше 30 дней, риск уже высокий.

Поддержка закладывается еще в разработке

Поддержка сайта - это часть разработки, а не сервисный хвост после сдачи проекта. Если у проекта нет staging, Git, логов, мониторинга и нормального деплоя, сопровождение потом будет дорогим даже при хорошем коде.

Мы сами когда-то брали проекты по схеме «сейчас выкатим вручную, порядок наведем позже». Это была ошибка. На практике такие истории почти всегда заканчивались ночными откатами. Один раз мы приняли сайт, где релизы шли по FTP прямо в прод. Формально все работало, но любая правка была риском, потому что никто не мог быстро сказать, какой файл меняли и как вернуться на прошлую версию.

Плохая схема:
Правка в проде -> ручная загрузка файлов -> нет проверки -> инцидент

Нормальная схема:
Git -> staging -> чек-лист -> deploy -> мониторинг -> rollback

Вот как это выглядело в цифрах на одном B2B-проекте после наведения порядка:

Две команды бывают полезны, но только в понятной конструкции

Я бы не стал говорить, что один подрядчик всегда лучше. Есть ситуации, где разделение работает нормально.

Первая - внутри компании есть сильный CTO или технический руководитель. Он держит архитектуру, правила релизов и может быстро остановить спор подрядчиков фактами, а не перепиской. Вторая - когда нужен отдельный сервисный контур: сайт сети клиник, запись 24/7, дежурство и SLA на критичный инцидент 15-60 минут. Третья - когда роли разведены заранее: core-разработка у одной команды, DevOps, мониторинг или L1-поддержка у другой.

Хорошая модель - та, где подрядчика можно поменять без паузы в продажах.

Если этого нет, у вас не схема управления, а доверие на словах.

Что проверить до договора, а не после первой аварии

Я смотрю на подрядчика не по презентации, а по четырем вещам: у кого доступы, как идут релизы, сколько занимает восстановление и как передается проект. Вопросы скучные, но именно они решают, потеряете вы вечер на спор между командами или нет.

Если хотите быстро проверить свою модель, задайте один неприятный вопрос: кто в пятницу вечером за 30 минут соберет доступы, поднимет бэкап и выпустит срочный фикс. Если ответа нет, история с потерянными 17 часами уже ближе, чем кажется.