Как выбрать подрядчика на разработку ПО в Узбекистане: гид для бизнеса

Выбор подрядчика на разработку — это решение, которое влияет на проект на годы вперёд. Неверный выбор оборачивается не только потерянными деньгами, но и потерянным временем, недоступными исходниками и продуктом, который невозможно развивать. На рынке Узбекистана выбор осложняется тем, что здесь работают и зрелые студии, и команды-однодневки, и фрилансеры под вывеской «агентства». Разберём по шагам, как отличить надёжного партнёра от рискованного.

С чего начинается выбор: задача, а не технологии

Распространённая ошибка — начинать с вопроса «на чём вы пишете». Сначала должна быть сформулирована бизнес-задача: что продукт должен делать, для кого, какие сроки и бюджет реалистичны. Хороший подрядчик задаёт встречные вопросы про пользователей, нагрузку, интеграции (платёжные системы, Soliq, my.gov.uz, Didox, банковские API) и про то, как вы будете развивать продукт после запуска. Если команда сразу называет стек и цену, не разобравшись в задаче, — это сигнал, что вам продают шаблон, а не решение.

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

Критерии оценки подрядчика

Сильную команду отличают несколько проверяемых признаков:

• Юридический статус. Зарегистрированное ООО или ИП, реквизиты, возможность работать по официальному договору с НДС или без — в зависимости от налогового режима. Компания, которая просит оплату «на карту физлица», — это сразу риск.
• Процесс, а не герои. У зрелой студии есть менеджер проекта, постановка задач в трекере (Jira, YouTrack, аналоги), демо по спринтам, code review. Если весь проект держится на одном «гениальном разработчике» — при его уходе вы остаётесь ни с чем.
• Прозрачная коммуникация. Регулярные статусы, понятная отчётность по часам и задачам, готовность показывать промежуточный результат, а не только финал.
• Техническая экспертиза под вашу задачу. Опыт в нужной нише — финтех, e-commerce, маркетплейсы, мобильные приложения — важнее, чем общее число лет на рынке.

Как правильно смотреть портфолио

Портфолио — это не галерея красивых картинок. Оценивайте его критически:

• Просите живые ссылки на работающие сайты и приложения в App Store / Google Play, а не только скриншоты. Проверьте, обновляются ли проекты, не «мертвы» ли они.
• Уточняйте роль команды в проекте: они делали всё, или только верстали дизайн по чужой архитектуре? Часто в портфолио попадают проекты, где участие было минимальным.
• Просите контакты прошлых клиентов и звоните им. Один честный разговор с предыдущим заказчиком даёт больше, чем десяток кейсов на сайте. Спрашивайте про сроки, превышение бюджета, поведение в кризисных ситуациях.
• Смотрите на сложность задач, похожих на вашу: интеграции с платёжными системами Узбекистана (Click, Payme, Uzum), высокая нагрузка, мультиязычность (uz/ru/en).

Договор: что обязательно зафиксировать

Устные договорённости в разработке не работают. Грамотный договор защищает обе стороны и должен содержать:

• Техническое задание или его методику — приложением к договору. Без ТЗ «доработки» становятся бесконечными, а споры о «что входило в стоимость» — неизбежными.
• Этапы, сроки и привязанные к ним платежи. Оплата по факту приёмки этапа, а не всё вперёд.
• Передачу исключительных прав на код и дизайн заказчику после оплаты. Без этого пункта по закону права остаются у исполнителя.
• Гарантийный период на исправление багов после сдачи (обычно 1–3 месяца).
• Условия расторжения и порядок передачи наработок при выходе из проекта.
• NDA о неразглашении, если работаете с чувствительными данными.

Red flags: на что обратить внимание сразу

Некоторые сигналы стоит замечать ещё на этапе переговоров:

• Подозрительно низкая цена. Если предложение в разы дешевле рынка — экономят на тестировании, архитектуре или работают студенты. Доработка такого продукта обходится дороже, чем разработка с нуля.
• Нежелание давать доступ к коду по ходу проекта. Здоровая практика — репозиторий на вашем GitHub/GitLab с первого дня. Отказ — повод насторожиться.
• «Сделаем за неделю». Нереалистичные сроки означают либо непонимание задачи, либо обман.
• Отсутствие договора или предложение «работать на доверии».
• Один контакт на весь проект без команды и процессов за ним.
• Размытые ответы про технологии и архитектуру — признак того, что решения принимаются на ходу.

Передача исходников и доступов

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