Из чего складывается стоимость разработки

Введение: почему разные сметы на одну задачу

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

Из чего складывается стоимость разработки? Из этапов проекта, где каждый этап имеет свой вес в смете. Из зарплат специалистов - junior код пишет медленнее, senior видит подвохи с первого взгляда. Из скрытых расходов, которые новичок забывает, а профессионал заранее закладывает. Из качества - за 50k вы получите работающий код, за 500k получите масштабируемую систему, которая не упадет при росте нагрузки.

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

Основные этапы проекта и их доля в бюджете

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

1. Аналитика и открытие (Discovery)

Это погружение в задачу. Аналитик (или тот же разработчик в малой студии) говорит с клиентом, ловит требования, рисует схемы, выявляет подвохи. Типовая доля: 10-15% бюджета. Почему это так важно? Потому что ошибка на этапе аналитики обходится в два раза дороже, чем ошибка, обнаруженная на аналитике. Если вы не разобрали требования - разработчик потратит часы на переделку, потом снова на переделку.

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

2. Дизайн и UX

От эскизов на бумаге до готового дизайн-макета в Figma. Типовая доля: 10-20%. Хороший дизайн - это не красота ради красоты, это понимание пользователя, удобство навигации, тестирование гипотез. Дизайнер исследует конкурентов, делает вайрфреймы, согласовывает их с клиентом, потом переводит в полноценный визуальный дизайн.

На этом этапе появляется дизайн-система - набор компонентов и правил, который потом сэкономит время разработчика. Если дизайн продумать хорошо, разработчик просто собирает компоненты, как конструктор. Если плохо - разработчик выдумывает дизайн сам, а потом еще переделывает.

3. Разработка (Frontend, Backend, Интеграции)

Самая большая линия в смете: 50-70% бюджета. Здесь работают фронтенд-разработчики (интерфейсы), бэкенд-разработчики (логика сервера, БД, API) и интеграторы (связь внешних систем). На этом этапе самым сильно на цену влияет квалификация: junior разработчик пишет медленнее, делает больше ошибок, требует ревью и правок. Senior видит архитектурные подвохи с первого взгляда, пишет масштабируемый код, который потом не нужно переделывать.

Типичный пример: простая задача на SQL запрос. Junior может написать запрос, который работает на малом объеме данных, но падает на большом. Senior сразу подумает об индексах, избежит N+1 проблемы, напишет код, готовый к масштабированию. Итого: junior 10 часов, senior 2 часа на ту же задачу. А если умножить на 100+ таких задач в проекте - разница в сроках и стоимости огромная.

4. QA и тестирование

Типовая доля: 10-15%. QA инженер проверяет, что все работает по ТЗ. Включает автотесты (скрипты, которые проверяют функцию автоматически), ручное тестирование (когда человек кликает и проверяет), баг-хантинг (ищет края, которые разработчик не подумал). Сокращать на этом нельзя - сэкономили 10% на QA, потеряли 100% на поддержке, когда клиент нашел баги в production.

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

5. DevOps и инфраструктура

Типовая доля: 5-10%. Это настройка серверов, CI/CD pipelines (автоматическая разработка кода), мониторинг, резервные копии, безопасность. На первый взгляд выглядит как лишнее, но если не настроить правильно с самого начала - потом переделывать будет в 10 раз дороже. DevOps инженер помещает код в контейнеры, настраивает автоматическое развертывание, ставит мониторинги, чтобы вы узнали об ошибке быстрее клиента.

6. Поддержка и правки после запуска

Проект не заканчивается на дате сдачи. Всегда есть баги, которые нашел клиент, мелкие правки, оптимизация под нагрузку. Типовая доля: 5-15%. Хорошие студии кладут это в смету явно, плохие добавляют к стоимости потом.

Структура смет в цифрах

Вот как выглядит типичная разбивка бюджета по этапам для веб-приложения среднего размера:

Роли в команде и их влияние на цену

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

Уровни разработчиков и их вклад

В любой студии есть иерархия: junior, middle, senior, lead. Это не просто звучит красиво - это влияет на качество и скорость.

1. Junior (стажер, опыт до 2 лет) - пишет простые компоненты, следует готовым паттернам, нуждается в ревью каждого pull request. Ставка: от 100-150 тыс. руб в месяц. На сложный баг потратит 8 часов вместо 1 часа senior.
2. Middle (опыт 2-5 лет) - берет средние по сложности таски, часто не нуждается в ревью, видит архитектурные вопросы. Ставка: от 200-300 тыс. руб в месяц. Это рабочая лошадка большинства студий.
3. Senior (опыт 5+ лет) - берет сложные архитектурные задачи, ревьюит код других, знает best practices в своей нише. Ставка: от 350-500+ тыс. руб в месяц. Один senior может направить работу трех junior.
4. Tech Lead - архитектор проекта, руководит разработкой, делает критические решения. Ставка: от 400-600+ тыс. руб в месяц. Обычно нужен на большие проекты.

Примечание: все ставки - российский рынок, freelance и студии, 2026 год. Точная цена зависит от города, специализации (фронтенд vs DevOps vs аналитика), опыта конкретного человека, наличия лида на проекте.

Заметьте: на таблице нет цены 'за весь проект'. Потому что сначала прикидывают часы (аналитика сказала: 300 часов разработки), потом умножают на ставку (300 × 1500 = 450k для middle разработчика). Если нужна архитектура, добавляют senior за меньше часов, но по выше ставке.

Факторы, которые меняют стоимость

Смета не пришла из ниоткуда. Вот что реально влияет на цену:

• Сложность задачи - интеграция с 5 сторонними сервисами дороже, чем standalone приложение
• Масштабируемость - система на 100 пользователей vs 1 млн - разные архитектуры, разная цена
• Технологический стек - специалист по редкому языку дороже, чем по популярному
• Сроки - срочный проект требует ускорения, что влияет на цену (переработки, премии)
• Качество требуемое - стартап с MVP < корпоративная система с 99.99% uptime
• Опыт команды в домене - если это третий e-commerce для студии vs первый - разница в цене
• Интеграции - подключение к payment gateway, CRM, бухгалтерии - каждое стоит времени
• Поддержка и обслуживание - нужна ли она после запуска и на сколько месяцев
• Тестирование - нужны ли автотесты, нагрузочное тестирование, security audit
• Локализация - одна версия vs несколько языков и валют

Как читать смету подрядчика и не попасться на удочку

Вот пришла вам смета. На что смотреть?

Признаки честной сметы

1. Разбор по этапам - не просто число, а 'аналитика 2 неделя, дизайн 1 неделя, разработка 5 недель'
2. Часы на линию - каждая статья показывает часы, не просто сумму. 'Фронтенд 300 часов × 1500 = 450k'
3. Роли указаны - видно, кто будет работать: 1 senior backend, 2 junior frontend, 1 designer
4. Риски упомянуты - 'Если появятся неожиданные интеграции, смета вырастет'
5. Дефинитив в конце проекта - 'После аналитики переоценим часы и уточним'
6. Условия поддержки - 'Включает 30 дней поддержки, дальше по часам'
7. Примечание о Change Request - 'Если ТЗ расширится, это будет отдельным счетом'

Красные флаги в смете - о чем они говорят

• Просто число, никакого разбора - 'Проект стоит 100k' без детализации. Это значит подрядчик гадает.
• Цена явно ниже рынка (50k за сложный проект) - либо junior команда, либо потом добавят счета за 'изменения'
• Нет часов - только стоимость. Если позвонить и спросить 'Сколько часов?', ответа не будет.
• Не упомянута поддержка - а она там есть, только скрыто в 'изменениях'
• Нет ролей или все один 'разработчик' - это либо один человек, либо неопытная команда
• Смета включает 'неопределенные работы' - 'Может понадобиться еще что-то' без уточнения
• Нет сроков - только деньги. Непонятно, на сколько месяцев это рассчитано

Скрытые расходы и что о них нужно знать

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

• Настройка окружения - если используется специальный стек, может потребоваться день на настройку. Может быть, может не быть.
• Интеграция с третьими API - 'Просто подключить API платежей' может быть 2 часа, может быть 20 часов, если API криволинейный.
• Миграция данных - если проект расширение старой системы, может быть нужна миграция. Может быть 100 часов разработки и тестирования.
• Подготовка к production - настройка мониторов, логирования, отладки на production. На старт - часть DevOps, потом ваша головная боль.
• Обучение вашей команды - если вы будете поддерживать проект сами, нужно провести обучение. Час-два на новичков.
• Документация - кодовая база должна быть задокументирована, как запускать, как расширять. Может быть 10-20 часов.
• Переговоры и уточнения - аналитик может попросить еще встреч, может быть +10-20 часов на согласование.
• Резерв на неожиданное - приличный подрядчик закладывает 10-15% на неожиданные баги и уточнения

Качество vs стоимость: почему дешево не значит хорошо

Можно сэкономить на любом этапе. Каждая экономия имеет цену.

1. Урезали аналитику (сэкономили 15k) - разработчик работает по неполному ТЗ, переделывает много раз. Потеря: +50k.
2. Урезали дизайн (сэкономили 20k) - интерфейс неудобный, пользователи уходят. Потеря: потеря пользователей.
3. Взяли junior вместо middle (сэкономили 100k) - код медленнее, больше багов, долгая разработка. Потеря: +30k на правки, долгие сроки.
4. Урезали QA (сэкономили 15k) - баги нашел клиент, его репутация пострадала. Потеря: 200k на переделку имиджа.
5. Урезали DevOps (сэкономили 10k) - система упала, потеря uptime. Потеря: потеря доверия клиентов.

Классический пример: стартап сэкономил 50k и взял junior команду вместо middle. Через полгода из-за медленной разработки и багов потратил 200k на переделку и смену подрядчика. Вывод: не экономьте на качестве на критичных этапах.

Как уменьшить стоимость без потери качества

Деньги же нужно экономить. Но правильно.

• MVP вместо полного функционала - выпустите 70% функций за 50% цены, потом добавляйте. Это быстрее, дешевле, и вы узнаете, что нужно клиентам.
• Переиспользуйте готовое - есть библиотеки, готовые компоненты, SaaS сервисы. Зачем писать свой auth, если есть готовый?
• Выберите middle вместо senior - если задача не критична по архитектуре, middle сделает дешевле и быстрее, чем junior.
• Фокус на главное - если есть 100 идей, выберите 20 самых важных. Все остальное потом.
• Понятное ТЗ - если вы отдадите четкое ТЗ, подрядчик не будет гадать. Это экономит часы переговоров.
• Меньше интеграций на старт - подключите платежи позже, если нужно. На старт - главное.
• Выберите технологию, которую знает подрядчик - если он эксперт в React и вы берете React, это дешевле, чем если вы просите его освоить новый фреймворк

Дополнительные вопросы при согласовании сметы

Вот чек-лист, что спросить подрядчика, чтобы не было сюрпризов:

• Что конкретно входит в каждую линию сметы? (часы, роли, описание работ)
• Что НЕ входит? (поддержка, интеграции, хостинг)
• Какие сроки? (начало, промежуточные, финал)
• Кто будет работать? (names, уровень, опыт)
• Как считаются переработки? (если проект пойдет дольше)
• Что если появятся новые требования? (как будет пересчитана смета)
• Есть ли резерв в смете? (на неожиданное)
• Какая гарантия на работу? (30 дней, год, чего)
• Как выглядит процесс разработки? (спринты, демо, ревью)
• Может ли смета расти? (и на сколько максимум)

FAQ

Почему разработка стоит так дорого?

Потому что это работа высокой квалификации. Хороший разработчик - это специалист, который учился 5-10 лет, решил тысячи задач, знает, где скрываются подвохи. Его ставка - это не зарплата, это оценка рынка для такого уровня. Еще дороговато кажется? Вспомните, что проект стоит 100k, это 3-4 месяца работы человека. Если взять по часам (1500 ₽/час), это 150-200 часов одного специалиста плюс еще специалисты других ролей.

Можно ли договориться о меньшей цене?

Да, но каждый процент скидки - это либо снижение качества, либо ускорение, которое означает ночные переработки. Честная смета - это уже расчет по рынку. Если предложить 30% скидку, подрядчик либо откажет, либо возьмет, но потом будут проблемы. Можно договориться о сокращении функционала (MVP вместо полного), о переиспользовании готового, о более дешевых технологиях - но это должно быть явно.

Что влияет на сроки проекта?

Четыре фактора: объем работы (часы), размер команды, качество ТЗ и переговоры. Если у вас есть ясное ТЗ и вы не будете менять требования каждую неделю, проект пойдет быстро. Если ТЗ расплывчатое и вы каждый день просите что-то переделать - сроки растут. Точная формула: часы разделить на (кол-во людей × эффективность), минус время на встречи.

Как не переплатить за поддержку?

Договоритесь об условиях с начала. 'Включает 30 дней бесплатной поддержки после запуска, дальше 5000 ₽ в месяц за баги/правки или по часам'. Без договора поддержка становится 'а можно еще сделать...' и никто не знает, кто это платит. Также важно: поддержка - это баги и мелкие правки. Если вы просите новый функционал - это развитие, считается отдельно.

Почему senior дороже, если результат же код?

Потому что результат разный. Junior написал код, что работает. Senior написал код, что работает, масштабируется, безопасен, удобен для поддержки, готов к 10x нагрузке. Второе - это не просто код, это архитектура, опыт, качество. Аналогия: вы можете нанять студента построить дом за 100k, может быть, не упадет. Или нанять архитектора за 500k, и он точно не упадет. Ставка senior - это страховка.

Что такое Change Request и как не переплатить?

Change Request - это когда вы просите что-то новое или измененное после того, как аналитика и смета готовы. Например: 'А давайте еще сюда добавим интеграцию с Instagram'. Это расширение задачи. Хороший подрядчик скажет: 'Это CR, стоит X часов, будет Y ₽ дополнительно, сдвинет сроки на Z недель'. Плохой просто сделает, а потом добавит счет. Чтобы не переплатить: четко опишите требования в начале, потом любое расширение - явный CR с расчетом.

Как проверить, что подрядчик не слишком дорогой?

Получите две-три сметы от разных студий и сравните. Смета не может быть просто числом, должна быть разбор по этапам и ролям. Если одна смета 50k, другая 150k, не нужно брать дешевую - нужно спросить, почему разница. Может быть, дешевая студия берет только фронтенд, а дорогая включает всё. Или дешевая берет junior, дорогая middle. Кстати, самая дешевая смета часто означает неопытную команду или скрытые расходы потом.