Этапы оплаты разработки приложения: как это работает

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

Почему важно платить поэтапно, а не всё сразу

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

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

Стандартная модель: четыре транша по 25%

В индустрии сложилась проверенная структура: четыре равных платежа по 25% от общей суммы. Она работает для большинства проектов — от простых MVP ($5 000–15 000) до комплексных AI-приложений ($45 000–120 000+). Вот как выглядит каждый этап.

Транш 1 — 25%: старт и Discovery

Когда: до начала любой работы, сразу после подписания контракта.

Что оплачивает этот транш:

• Discovery Sprint и формализация требований
• Пользовательские сценарии и описание функциональности
• Wireframes или интерактивный прототип ключевых экранов
• Выбор технологического стека и архитектурная схема
• Детальный план с разбивкой оставшихся этапов по срокам и стоимости

Что получает клиент: документацию, которая останется у него независимо от того, продолжится ли работа с данной студией. Это справедливо: клиент платит за реальный артефакт, не просто за «начало разговора».

Первый транш защищает студию от старта без ясных требований и защищает клиента — потому что ставит деньги под конкретную точку приёмки.

Транш 2 — 25%: дизайн и архитектура готовы

Когда: после утверждения клиентом всех дизайн-макетов и технической архитектуры.

Что оплачивает этот транш:

• UI/UX дизайн всех экранов в Figma (с анимациями и состояниями)
• Финальная архитектурная документация (схема базы данных, API-контракты, описание интеграций)
• Настроенная инфраструктура: репозиторий, CI/CD-пайплайн, тестовая среда

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

Транш 3 — 25%: рабочая бета-версия

Когда: после передачи клиенту работающей бета-версии приложения для тестирования.

Что оплачивает этот транш:

• Реализованная основная функциональность (core features из MVP-объёма)
• Работающие интеграции: API, платёжная система, авторизация, push-уведомления
• Внутреннее тестирование (unit tests, integration tests)
• Доступ к TestFlight (iOS) или аналогу для клиентского тестирования

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

Транш 4 — 25%: релиз

Когда: после публикации в App Store (или передачи финального билда, если публикацию ведёт клиент).

Что оплачивает этот транш:

• Исправление всех замечаний из бета-тестирования
• Финальное QA и нагрузочное тестирование
• Подготовка к релизу: App Store-листинг, скриншоты, описание, конфигурация аналитики
• Передача всей документации, доступов и исходного кода
• Краткий post-launch период поддержки (обычно 2–4 недели)

Что получает клиент: живое приложение в магазине и полный контроль над кодовой базой.

Сравнительная таблица: что включает каждый этап

Транш	%	Ключевые поставки	Критерий приёмки
1 — Старт	25%	Discovery, прототип, архитектура, план	Подписание контракта
2 — Дизайн	25%	Финальные макеты, инфраструктура	Письменное утверждение дизайна
3 — Бета	25%	Работающее приложение, интеграции	Передача билда на тестирование
4 — Релиз	25%	Доработки, публикация, передача кода	Публикация в App Store

Как milestone-структура адаптируется под размер проекта

Для простых MVP ($5 000–15 000, срок 2–4 месяца) четыре транша могут сократиться до трёх: старт + дизайн объединяются в один платёж, оставшиеся два — бета и релиз. Это разумно, когда Discovery и дизайн занимают одну-две недели.

Для сложных проектов с AI, realtime-функциями или множеством интеграций ($45 000–120 000+, срок 7–12+ месяцев) стандартная четырёхэтапная структура может расширяться: появляются промежуточные milestone для каждого крупного модуля. Например, в проекте с 8-месячным циклом вместо одного третьего транша может быть три промежуточных платежа — по завершении каждого функционального блока.

Мы применяем именно такой гибкий подход в Fera Tech. Когда мы разрабатывали наши собственные продукты — Launchcast и Clove AI — milestone-структура помогала чётко отслеживать прогресс и принимать архитектурные решения на каждом переходе между этапами. Примеры нашей работы с клиентами — в портфолио.

На что обратить внимание в контракте

Milestone-структура работает только при чётких формулировках. Несколько пунктов, которые должны быть явно прописаны:

• Определение «принято»: конкретный срок на обратную связь от клиента (обычно 5–7 рабочих дней). Молчание не равно утверждению.
• Количество раундов правок: сколько итераций по дизайну и функциональности включено в объём; что считается новым объёмом работы.
• Условие задержки оплаты: если транш не поступил в течение X дней после подтверждённого milestone, работа приостанавливается до оплаты. Это стандартная практика, а не санкция.
• Право собственности на код: когда оно переходит к клиенту — как правило, после финального платежа.
• Ответственность за задержки на стороне клиента: если обратная связь или материалы приходят позже запланированного, сроки сдвигаются пропорционально.

Подробнее о том, на что смотреть в договоре разработки, читайте в нашем руководстве по красным флагам в контрактах — там разобраны конкретные формулировки, которые защищают клиента.

Как milestone-оплата выглядит в реальных цифрах

Возьмём стандартное iOS-приложение за $30 000 со сроком 5 месяцев:

• Транш 1 — $7 500: Discovery, прототип, план — через неделю после подписания
• Транш 2 — $7 500: утверждённые макеты, готовая инфраструктура — через 4–5 недель
• Транш 3 — $7 500: бета-версия на TestFlight — через 3–4 месяца
• Транш 4 — $7 500: публикация в App Store — через 5 месяцев

Итого: клиент в любой момент заплатил не больше 75% от суммы и не видел ни копейки «в пустоту» — каждый платёж идёт за готовый результат.

Частые вопросы

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

Один перенос milestone — нормально, если причина объективна и студия уведомляет заранее. Проблема начинается, когда переносы становятся системой. Хорошая практика: прописать в контракте, что задержка более чем на X дней без согласованной причины даёт клиенту право на расторжение и возврат части аванса за невыполненный этап.

Можно ли платить почасово, а не по milestone?

Можно, и это часто встречается в контрактах типа Time & Materials. Но milestone-структура даёт клиенту больший контроль: вы знаете, что деньги идут за конкретный результат, а не за часы. Для фиксированного объёма (MVP, конкретная фича) milestone предпочтительнее. Для долгосрочного партнёрства или проектов с меняющимися требованиями T&M может быть удобнее.

Что если я хочу добавить функцию в середине проекта?

Новый объём — это новый milestone или отдельное дополнение к контракту (change order). Профессиональная студия не будет молча добавлять работу: любое расширение объёма должно фиксироваться письменно с указанием стоимости и влияния на сроки. Это защищает обе стороны. Подробнее о структуре контрактов — на странице услуг.

---

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