Как это обычно выглядит
- •Заявки с форм перестали доходить, и никто не знает, когда именно это началось,
- •Каталог или прайс обновляется руками, потому что выгрузка сломалась и чинить некому,
- •На телефоне вёрстка разъезжается, а на компьютере всё выглядит нормально,
- •Сайт работает на версии движка, которую перестали обновлять, и хостинг уже присылает предупреждения,
- •Есть исходники, но никто не может сказать, тот ли это код, который сейчас крутится на сервере.
Общее у всех пяти — проблема не в задаче, а в том, что её некому взять. Код написан, он работает, но человек, который держал его в голове, ушёл. И первый же подрядчик, к которому вы обращаетесь, предлагает начать заново — потому что так ему проще, чем разбираться в чужом.
Начинаем с разбора, а не с правки
Прежде чем что-то менять, надо понять, что там есть. Это не формальность: правка в чужом коде опасна ровно настолько, насколько неизвестно, что от неё зависит. Поэтому первый шаг — прочитать проект и провести границу.
Что мы выясняем
- •Где что лежит: домен, DNS, хостинг, почта, код, база — и на кого всё это оформлено,
- •Совпадает ли код в исходниках с тем, что реально работает на сервере,
- •Что зависит от участков, которые придётся трогать, — чтобы правка не сломала соседнее,
- •Есть ли резервные копии и восстанавливаются ли они на самом деле, а не только создаются,
- •Какие задачи из вашего списка решаются в существующем коде, а какие упираются в архитектуру.
Что чинится дёшево, а что нет
Дешевле всего чинится то, что сломано в одном месте: форма, которая перестала отправлять письмо, выгрузка, споткнувшаяся об изменившийся формат, вёрстка, которая не рассчитана на узкий экран. Такие задачи не требуют трогать остальное, и их видно сразу.
Дороже всего — то, что сломано по всему проекту одинаково: когда одно и то же значение переписано в десяти местах, когда правка в одном разделе непредсказуемо меняет другой, когда обновить движок нельзя, потому что тема правилась поверх его файлов. Здесь честный ответ иногда действительно «заменить», и мы говорим об этом сразу, а не после трёх месяцев правок по кругу.
Что вы получаете
- •Правки в вашем коде, а не на нашей площадке, к которой потом нужен доступ,
- •Доступ ко всему, что мы трогали, и историю изменений, по которой видно кто, что и когда,
- •Разбор: что дальше стоит развивать, а что дешевле заменить — с указанием конкретных мест,
- •Возможность уйти в любой момент, ничего не выкупая.
Чего мы не делаем
- •Не называем срок и цену до того, как прочитали код: до этого любая цифра — угадывание,
- •Не предлагаем переписать проект целиком там, где задача решается правкой,
- •Не беремся за проект, где нет доступа ни к коду, ни к серверу: править вслепую нельзя,
- •Не оставляем себе ключей от вашего домена, хостинга и репозитория.
С чем работаем
Сайты на PHP и готовых движках, приложения на Next.js и React, серверную часть на Python, базы PostgreSQL и MySQL, интеграции по API и прошивки контроллеров на C. Это те стеки, на которых работают наши собственные продукты — от AI-серверов до защиты форм и рекламы, — поэтому в чужом коде на них мы разбираемся, а не изучаем его впервые за ваш счёт.
Частые вопросы
Разработчик пропал, доступов у нас нет. Возьмётесь?
Это обычная ситуация, и она решаемая, пока сайт работает: домен и хостинг оформлены на компанию или на человека, до которого можно дойти, а значит доступ восстанавливается через них, а не через пропавшего подрядчика. Начинаем с того, что выясняем, где вообще что лежит — домен, DNS, хостинг, почта, код, база. Если часть окажется оформлена на чужое имя, скажем сразу: это первое, что нужно вернуть себе, и без этого браться за правки бессмысленно.
Вы тоже скажете, что надо всё переписать?
Скажем только там, где это правда, и с объяснением почему. «Переписать заново» — самый удобный ответ для подрядчика: он снимает необходимость разбираться в чужом коде и превращает мелкую правку в новый проект. Поэтому мы сначала читаем то, что есть, и делим задачи на две части: что чинится в существующем коде и что упирается в архитектуру. Вторая часть обычно оказывается меньше, чем звучит на первой встрече.
А если код действительно плохой?
Тогда мы это покажем на конкретных местах, а не общими словами про «устаревшие технологии». Плохой код не повод переделывать всё: чаще всего заменить нужно один узел — тот, из-за которого правки в остальных местах становятся опасными. Что менять, а что оставить, решаете вы, но с нашим разбором на руках, а не под давлением сроков.
Что происходит, если правка ломает соседнюю часть?
На чужом коде это главный риск, и он снимается порядком работы, а не обещаниями. Перед правкой ищем всё, что зависит от изменяемого места, и правим всю цепочку за один заход. Изменения идут по одному, каждое можно откатить отдельно. Если раньше в проекте не было ни истории изменений, ни резервных копий, заводим их до первой правки — это дешевле, чем восстанавливать сайт по памяти.
Код и доступы останутся у нас?
Да, и это не отдельная услуга. Правки делаются в вашем репозитории или в вашем коде на вашем сервере, доступы ваши, история изменений остаётся у вас целиком. Уйти от нас можно в любой момент, ничего не выкупая и никого не упрашивая, — именно потому, что обратная ситуация и привела вас на эту страницу.
Работаете разово или постоянно?
И так, и так. Разово — когда задача понятна и заканчивается: починить формы, обновить каталог, привести вёрстку в порядок на телефоне. Постоянно — когда сайт живой и меняется, и нужен кто-то, кто держит его в голове. Начинать разумно с разового: он показывает состояние проекта и нам, и вам, и после него разговор о сопровождении идёт с цифрами, а не с ощущениями.