Создание
онлайн-сервисов
в Москве

Наша IT-компания поддерживает широкий спектр форматов: от ручного ввода до интеграций с CRM и ERP. В Москве часто требуется работа с 1С и Битрикс24 — эти интеграции мы делаем регулярно.

Нет, он не «сломается», но для некоторых форматов нужно настраивать фильтры и очистку. Мы помогаем адаптировать систему так, чтобы бизнес мог работать даже с «грязными» данными.

Мы проектируем архитектуру с резервированием и логированием. Но если сторонний API полностью перестает отвечать, доступ к его данным может быть временно ограничен.

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

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

Да, мы подключаем «ЮKassa», Сбербанк Онлайн и другие локальные шлюзы.

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

Мы проектируем системы в соответствии с ФЗ-152. Однако, часть ответственности всегда остается за внутренними процессами компании.

Да, архитектура модульная. Новые функции можно добавлять постепенно. Первую версию продукта закрывает разработка MVP.

Да, мы сопровождаем проект: от исправления ошибок до выпуска новых релизов.

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

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

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

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

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

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

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

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

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

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

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

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