Популярные вопросы

Custom-разработка имеет смысл там, где есть уникальная логика, специфические интеграции или требования, которые ни один готовый продукт не закроет без существенных компромиссов.

Если задачу можно решить существующим инструментом, который покроет 80% потребностей – скажем об этом на старте. Но если бизнес уже перерос шаблонные решения или строит что-то нестандартное, индивидуальная разработка дает полный контроль: логика, роли, интеграции, отчеты – все под конкретные требования.

Готовая платформа – это быстрый старт в пределах того, что в ней предусмотрено. Пока бизнес укладывается в эти границы, все работает. Но когда появляются нестандартные процессы, специфическая логика или потребность в глубоких интеграциях, начинаются обходные пути, плагины и постоянные ограничения.

Индивидуальное решение строится под вас: масштабируется вместе с бизнесом, интегрируется с любыми сервисами и не зависит от решений сторонней платформы по изменениям в API или политике.

В основном это либо инструменты для внутренней работы компании, либо продукты, с которыми взаимодействуют клиенты или партнеры. Первые – это системы управления, учетные платформы, интеграционные решения между существующими сервисами. Вторые – веб и мобильные приложения, партнерские порталы, e-commerce. Часто одно переплетается с другим: например, платформа для дистрибьюторов, которая внутри подключена к ERP и аналитике. Конкретный набор всегда зависит от того, какой процесс нужно решить.

От сложности и объема. Иногда MVP можно собрать за месяц, а полноценную систему за несколько месяцев. Если нужна глубокая интеграция или разработка сложной аналитики с нуля, сроки длиннее. Разработка всегда разбивается на фазы, и первые результаты появляются раньше, чем проект завершается полностью.

Начинаем с Discovery-этапа. Здесь мы вместе выясняем реальную задачу, ограничения и критерии результата. Это точка, где мы проверяем, правильно ли сформулирована задача, прежде чем начинать ее решать.

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

Ежедневного погружения не нужно, но полностью отстраниться тоже не получится. На старте важно качественно передать контекст и ответить на ключевые вопросы. Дальше нужно время от времени принимать решения по приоритетам, смотреть демо, отчеты, давать фидбек. Чем четче коммуникация на каждом этапе, тем меньше правок и недопониманий в конце.

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

При T&M новые приоритеты просто вписываются в следующий цикл. С фиксированным бюджетом сложнее, но управляемо: садимся, смотрим на текущий объем и решаем, что важнее сделать сейчас, а что отложить. Главное, что ни одно решение не принимается без вашего участия. Все прозрачно, и вы всегда в курсе, что и почему изменилось.

QA-инженер работает в той же команде и подключается к каждой функции. Ручное тестирование закрывает сценарии, где важна логика и пользовательский опыт. Автоматизация подключается там, где нужно проверять одно и то же регулярно, без ошибок из-за человеческого фактора.

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

В backend-разработке работаем с PHP (Phalcon, Yii2), Java, Symfony, для интеграций – REST API и GraphQL. Фронтенд чаще всего строим на Vue.js, для управления контентом используем PIMCore, мобильные решения – Swift и Kotlin. Это все использовали в конкретных проектах для ритейла, e-commerce, госсектора, медиа и производства.

Стек всегда подбирается под задачу. В одном проекте в приоритете быстродействие, в другом – гибкость интеграций, в третьем – масштабируемость. И мы всегда объясняем клиенту, почему предлагаем именно такой набор инструментов.

Подключали продукты к CRM, ERP, складским системам, маркетинговым платформам, платежным шлюзам, почтовым сервисам, государственным API, маркетплейсам. Если система имеет открытый API – подключаемся напрямую. Если нет – ищем другой путь: парсеры, прокси, кастомные коннекторы. Главное, что результат должен работать в реальной операционной среде.

Код, документация и инфраструктура полностью переходят к вам после оплаты. Передаем все в ваш Git или другую систему на ваш выбор. Никаких закрытых модулей или скрытых зависимостей, из-за которых вы были бы привязаны к нам. Хотите сменить подрядчика или развивать продукт собственной командой – никаких препятствий.

Код проходит несколько уровней проверки, ручное или автоматизированное тестирование, проверку на производительность и безопасность. Но еще более важный момент – проектирование. Если функция плохо продумана или логически противоречит остальной системе, она не попадает в разработку. Исправлять архитектурные решения после релиза намного дороже, чем задать правильные вопросы в начале.

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

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

От минимального мониторинга до полного технического сопровождения, в зависимости от того, что нужно. Критические проекты закрываем SLA с четким временем реагирования. Для менее критичных предлагаем гибкий формат по договоренности. Поддержка охватывает работу с багами, обновление библиотек, безопасность и оптимизацию.

Если архитектура спроектирована с учетом роста – да, и именно так мы ее строим. Новые модули, увеличение нагрузки, дополнительные интеграции – все это закладывается на уровне решений, принятых еще до первой строки кода. У нас есть кейсы, где MVP, собранный за несколько недель, вырос в полноценную платформу без необходимости переписывать систему с нуля.

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