Сколько стоит разработка программного обеспечения в Узбекистане?

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

Почему единой цены не существует

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

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

Что действительно двигает цифру

Примерно в порядке влияния на общие трудозатраты:

1. Интеграции. Каждая внешняя система — платежи, бухгалтерия, мессенджеры, государственные сервисы, действующая ERP — добавляет доступы, тестовую среду, обработку ошибок и порядок поддержки на случай сбоя. Это ещё и наименее управляемая часть графика, потому что вы ждёте кого-то другого.
2. Роли и права доступа. Каждая дополнительная роль умножает количество экранов и добавляет логику прав, которая затрагивает каждую функцию. Тестирование растёт быстрее, чем можно предположить по числу экранов: четыре роли — это четыре версии каждого экрана, которые нужно проверить.
3. Существующие данные. Перенос многолетних таблиц или старой базы данных редко сводится к разовому скрипту. В реальных данных есть дубликаты, пропущенные поля и недокументированные форматы; их очистка — отдельный проект.
4. Правила предметной области. Тарифы, скидки, налогообложение и цепочки согласований — как раз то место, где «простые» приложения становятся дорогими, потому что правила живут в головах людей и у каждого есть исключения.
5. Дизайн. Аккуратный интерфейс на основе готовой библиотеки компонентов стоит долю от индивидуального, насыщенного анимацией. Профессиональными могут быть оба; оригинальный дизайн каждого экрана нужен только одному.
6. Платформы. Кроссплатформенные фреймворки сокращают разрыв между вебом, iOS и Android, но не убирают его: публикация в магазинах приложений, тестирование на устройствах и push-уведомления — это работа в любом случае.
7. Нефункциональные требования. Целевая доступность, журналы аудита, работа офлайн и ожидаемая нагрузка меняют архитектуру, а архитектура, определённая поздно, — самое дорогое, что можно менять.

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

Что включают проекты разного типа

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

Тип проекта	Обычно включает	Где прячутся трудозатраты	Размер для планирования
Маркетинговый сайт	Страницы, SEO, формы, CMS, языки	Контент и перевод	Меньший
Веб-приложение или портал	Авторизация, роли, дашборды, база данных	Права доступа и отчётность	Средний
Мобильный MVP	Ключевые сценарии, бэкенд, публикация в магазине	Устройства, офлайн, модерация	Средний
Операционная платформа или CRM	Многоролевые процессы, импорты, отчётность	Миграция, интеграции	Больший
Продукт с ИИ	Интеграция модели, интерфейс проверки, оценка качества	Качество данных, оценка качества	Зависит

Эти типы пересекаются. Большинство запросов на «простой сайт» превращаются во вторую строку, как только кто-то упоминает личный кабинет клиента, а большинство запросов на CRM — в четвёртую, как только речь заходит о существующих данных. Если ваш проект постоянно сползает на строку ниже, планируйте сразу по этой строке.

Модели оплаты и когда какая подходит

Модель	Подходит, когда	Что берёте на себя вы	Что берёт на себя подрядчик
Фиксированная цена, фиксированный объём	Требования задокументированы и стабильны	Медленные и дорогие изменения	Ошибку в оценке
Оплата по времени и материалам	Объём будет меняться вслед за обратной связью пользователей	Неопределённость бюджета	Только темп разработки
Выделенная команда	Есть непрерывная дорожная карта на месяцы вперёд	Мощность, которую нужно загружать	Стабильность состава

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

Статьи расходов, о которых забывают

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

• Анализ, сбор требований и письменное техническое задание.
• Дизайн UI/UX и библиотеку компонентов, которая удешевляет последующие экраны.
• Тестирование в тех браузерах, на тех устройствах и языках, которые вы реально поддерживаете.
• Управление проектом и время на согласования, которое потратит ваша собственная команда.
• Среды, CI/CD, резервные копии и мониторинг.
• Миграцию данных, очистку, контент и перевод.
• Аудит безопасности, разграничение доступа и работу с секретами.
• Документацию, передачу проекта и обучение.

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

Во сколько обходится эксплуатация после запуска

Стоимость разработки разовая, стоимость эксплуатации постоянная, и обсуждать их нужно в одном разговоре:

• Хостинг, управляемые базы данных, хранилище и трафик, которые растут вместе с использованием.
• Домены, сертификаты и доставка транзакционных писем.
• Сервисы с оплатой по факту использования: SMS, карты, push-уведомления и любые LLM API.
• Комиссии платёжного провайдера с каждой проведённой транзакции.
• Аккаунты разработчика в магазинах приложений, которые нужно продлевать.
• Сопровождение: обновление зависимостей, изменения в ОС и правилах магазинов, патчи безопасности.
• Поддержка и небольшие доработки, когда придут реальные пользователи.

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

Локальные факторы, которые меняют оценку в Узбекистане

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

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

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

Вопросы, которые выявляют слабую оценку

Задайте их любому подрядчику, включая нас:

1. Что явно не входит в эту цену?
2. По каким интеграциям у вас уже есть документация и тестовый доступ, а какие остаются предположением?
3. Входят ли в эту цифру дизайн, тестирование, управление проектом и развёртывание?
4. Как оцениваются и согласуются изменения объёма после начала работ?
5. Кому принадлежит исходный код и где он хранится в ходе проекта?
6. Что именно передаётся: репозитории, инфраструктура, документация, доступы?
7. Есть ли гарантия на исправление дефектов после запуска и на какой срок?
8. Какие части проекта самые рискованные и как вы заложили этот риск в цену?
9. Кто выполняет работу и что произойдёт, если этот человек станет недоступен?
10. Сколько будет стоить эксплуатация системы в месяц и что входит в сопровождение?

«Мы пока не знаем, и вот как мы это выясним» — хороший ответ на несколько из них. Цифра без приложенных к ней допущений — нет.

Ошибки, которые раздувают счёт, и что делать вместо них

• Выбор по часовой ставке. Меньшая ставка при вдвое большем числе часов обходится дороже. Сравнивайте полную стоимость определённого результата, а не цену часа.
• Отказ от анализа ради экономии. Сокращение этого этапа не убирает вопросы, а переносит их в разработку, где ответы стоят по расценкам разработки.
• Формулировка решения вместо проблемы. «Сделайте нам мобильное приложение» заранее исключает вариант, при котором адаптивное веб-приложение дойдёт до тех же пользователей быстрее. Приносите проблему и заставьте подрядчика обосновать самую дешёвую технологию, которая её решает.
• Разработка того, к чему можно просто подключиться. Замена работающей бухгалтерской или ERP-системы обычно обходится намного дороже, чем подключение к ней, — взвесьте системную интеграцию прежде, чем переписывать.
• Разработка всех ролей сразу. Запускайте сначала для той роли, которая создаёт ценность; реальное использование всё равно изменит остальной план.
• Бесхозные стыки. Если подрядчиков двое, зафиксируйте в договоре ответственного за точки интеграции, иначе каждый решит, что это была задача другого.
• Отсутствие резерва. Неизвестные — не провал планирования; провал — это отказ закладывать их в бюджет.

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

Итог

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