Как мы разрабатываем цифровые платформы с нуля: от идеи до запуска

Что такое «разработка под ключ» и почему это не просто код

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

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

Этап 1. Discovery: превращаем идею в требования

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

На этом этапе мы фиксируем:

• Бизнес-цель и метрику успеха — что должно измениться после запуска (скорость обработки заявок, конверсия, снижение ручного труда, новый канал дохода).
• Роли и сценарии — кто пользователь, что он делает, где у него возникает боль и где деньги.
• Ограничения — интеграции с банками, платёжными системами, госсервисами (ЕПИГУ, soliq, Didox), законодательство о персональных данных, требование размещения серверов внутри Узбекистана.
• Границы MVP — что входит в первую версию, а что осознанно откладываем.

Этап 2. Проектирование архитектуры и прототип

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

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

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

Этап 3. Разработка итерациями

Мы ведём разработку короткими спринтами по 1–2 недели, и в конце каждого заказчик видит работающий кусок системы, а не отчёт о потраченных часах. Это даёт две вещи: контроль бюджета и возможность корректировать курс, пока это дёшево.

Технически на этом этапе мы закладываем фундамент, который потом сложно достроить:

• Версионирование и код-ревью — каждое изменение проходит проверку второго разработчика, история кода под Git.
• Автотесты на критичную логику — биллинг, авторизация, расчёты. Это то, что нельзя ломать «по-тихому» при следующих правках.
• CI/CD — автоматическая сборка и выкатка, чтобы релиз был рутинной операцией на минуты, а не стрессом на полночи.
• Раздельные окружения — dev, staging, production, чтобы тестировать на копии, а не на живых пользователях.

Этап 4. Запуск и то, что бывает после

Запуск — это не «выложили и ушли». Перед релизом мы проводим нагрузочное тестирование, проверяем безопасность (защита от типовых атак, шифрование данных, разграничение прав доступа), настраиваем мониторинг и логирование. Важно, чтобы при сбое команда узнавала о проблеме из системы мониторинга, а не из звонка разозлённого клиента.

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

Типичные ошибки, которые мы помогаем не совершить

• «Сделаем всё сразу». Раздутый scope первой версии убивает сроки и бюджет. Лучше запустить ядро и расти от обратной связи.
• Отсутствие владельца продукта со стороны бизнеса. Если на стороне заказчика никто не принимает решения быстро, разработка встаёт в ожидании ответов.
• Игнорирование локального контекста. Платежи, идентификация, интеграции с госсистемами и требования к хранению данных в Узбекистане имеют свою специфику — её нужно учитывать на этапе архитектуры, а не на запуске.
• Vendor lock без передачи кода. Заказчик должен владеть исходным кодом и доступами. Мы передаём репозиторий и документацию — платформа остаётся вашим активом.