Доработка
и модернизация сайтов
в Москве

Сначала проверить, действительно ли упёрлись именно в платформу. Ограничение чаще всего конкретное: нельзя сделать нужный каталог, нет связи с учётной системой, не выходит ускорить страницы, не получается собрать нужную форму. Если ограничение платформенное, доработка не поможет и речь идёт о переносе на собственный движок с сохранением адресов, текстов и накопленных позиций в поиске. Отдельный случай разобран здесь: перенос сайта с Тильды.

Готово — это когда работает у вас, а не когда написано «сделано». Поэтому критерий приёмки формулируется до начала работ и на понятном языке: что должно происходить, при каких данных, что видит посетитель и что попадает в учётную систему. Показываем результат на тестовой копии, вы проверяете по этому списку, и только после вашего подтверждения изменения переносятся на рабочий сайт. Спор «мы имели в виду другое» такой список снимает заранее.

Да, это частая работа и её нельзя откладывать: на старой версии перестают выходить обновления безопасности, а хостинг рано или поздно переключит её принудительно. Порядок такой: поднимаем копию сайта на новой версии, собираем полный список ошибок, правим код и обновляем несовместимые расширения, проверяем формы, оплату и выгрузки. Переключение боевого сайта происходит после проверки, а не до неё, и возврат к прежней версии остаётся возможным.

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

Да, и отдельная оценка для этого не нужна: небольшие правки идут из общего запаса часов, согласованного на месяц. Важно другое — заранее договориться, что считается небольшой задачей. Правка текста, поля в форме, условия отображения блока — да. Новый раздел, изменение логики заказа, интеграция — нет, это отдельный объём работ со своим сроком, иначе «мелочи» съедают регулярные работы целиком. Границу мы фиксируем письменно в начале, а не спорим о ней потом.

Да, и для постоянно развивающегося сайта он удобнее разовых смет: вы не согласовываете каждую мелочь отдельно, а мы держим команду в контексте проекта и не тратим время на повторное погружение. Запас часов согласуется на месяц, переносится на следующий по договорённости, приоритет задач внутри него определяете вы, а неизрасходованное и перерасход видны в отчёте за месяц построчно. Ежедневные операции — копии, обновления, наблюдение — закрывает администрирование сайта.

Мы быстро анализируем причину, устраняем конфликты и восстанавливаем работу сайта. Восстановление входит в гарантийный период после обновления.

Да, и мы часто рекомендуем это клиентам. Обновления сочетаем с технической оптимизацией: ускоряем загрузку, упрощаем код, улучшаем индексацию и UX.

Минимум раз в квартал. Крупные онлайн-площадки — перед сезонными акциями или релизами новых продуктов. Регулярные обновления помогают tech agency поддерживать безопасность и производительность.

Мы тестируем все изменения, используем систему уведомлений и резервное копирование. Благодаря процессу product design studio ошибки исключаются еще на стадии теста.

Потому что одна и та же фраза означает разный объём. «Добавить фильтр в каталог» на сайте, где каталог собран стандартными средствами, — это несколько часов. На сайте, где каталог переписан предыдущим подрядчиком и данные лежат в трёх местах, та же фраза означает сначала разобраться в чужой логике, а потом уже делать. Разница в разы, и она не в нашей оценке, а в вашем сайте. Чтобы назвать цену, нам нужно посмотреть код и данные — обычно это несколько часов работы, и мы называем эту оценку заранее. На выходе вы получаете разбивку по подзадачам с часами по каждой. Если цена окажется выше ожидаемой, у вас на руках будет понятно, из чего она складывается и что можно выкинуть.

Поддержка — это чтобы работало то, что уже есть: обновления, копии, мониторинг, починка поломок. Доработка — это новая функциональность или изменение существующей: раздел, фильтр, интеграция, личный кабинет. Редизайн — это когда меняется внешний вид и структура, а функциональность переносится. Граница важна для денег: починка того, что сломалось само, входит в тариф поддержки, а новый раздел или интеграция считаются отдельно по часам. Мы разделяем это в отчёте, чтобы не выяснять в конце месяца, почему часы кончились.

Мы не правим прод напрямую. Работа идёт на копии сайта, изменения собираются в отдельную ветку, и перед выкатом прогоняются ключевые сценарии — те, на которых держится ваш бизнес: заказ, оплата, форма, вход в кабинет. Выкат идёт в оговорённое окно, а не «когда готово». После выката мы отдельно проверяем, что патч на месте и не затёрт следующим обновлением. Откат готовится до выката, а не после поломки: если что-то пошло не так, возврат к прежнему состоянию занимает минуты. Это дороже по часам, чем «залить по FTP», и это разница между подрядчиком и человеком с доступом.

Всё. Код — в вашем репозитории, доступы — ваши, документация по сделанному — у вас, включая описание того, где что лежит и почему сделано именно так. Мы не оставляем закладок, не завязываем сайт на наш сервер и не держим ключей, без которых он перестанет работать. Следующий подрядчик получит внятную картину, а не археологию.

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

Сначала превращаем фразу в перечень изменений, а потом считаем. «Добавить фильтр в каталог» может означать четыре часа работы или месяц — разница в том, сколько свойств участвует, нужен ли отдельный индекс, меняется ли адресация страниц, как это влияет на поиск и на выгрузки. Мы возвращаемся с разбором и оценкой по позициям, а не с одним числом: по позициям видно, что можно отложить и чем управлять по бюджету.

Зависит от того, где они живут. Изменения, внесённые в штатных точках расширения, обновление переживают. Правки, сделанные прямо в исходных файлах, при обновлении исчезают вместе с функциональностью, ради которой их делали, и обнаруживается это не сразу. Поэтому мы сначала описываем, как именно реализована каждая доработка, а новые делаем так, чтобы следующий апдейт их не затронул. Это не удорожает работу, но сильно удешевляет её сопровождение.

Да, это обычный для нас формат. Порядок приёмки тот же: сверяем файлы с оригинальной сборкой, выписываем чужие правки, читаем код и восстанавливаем логику по нему, а не по устному пересказу. Итог — короткое описание того, что сайт делает на самом деле, и список мест, где доработка окажется дороже ожидаемого. С этим описанием вы можете идти к любому подрядчику: оно остаётся вашим независимо от того, продолжим ли мы работу.