Этапы оплаты разработки сайта: аванс, транши, финальный расчёт

Когда клиент присылает бриф и просит смету, вопрос “сколько и когда платить” почти всегда всплывает раньше вопроса “что именно вы сделаете”. Грамотно выстроенные этапы оплаты разработки сайта защищают обе стороны: заказчик не рискует всей суммой сразу, а исполнитель не работает месяцами в долг, надеясь на оплату по факту сдачи. За несколько лет на фрилансе и в студийных проектах я перепробовал разные схемы - от полной предоплаты на мелких доработках Tilda до пяти-шести траншей на CRM-проектах на React - и ниже разберу, какая схема подходит под какой тип работы.

Зачем вообще разбивать оплату на этапы

Без разбивки на этапы риск ложится на одну из сторон целиком. Если заказчик платит всё в начале, он зависит от добросовестности исполнителя и не может повлиять на процесс, если что-то пошло не так. Если исполнитель берёт деньги только в конце, он рискует потратить недели на макет, бэкенд и интеграции, а затем услышать “мы передумали” или получить бесконечный список правок без оплаты.

На практике деление на этапы решает ещё одну проблему - сверку ожиданий. Когда я делаю интернет-магазин под ключ (от 80 000 ₽) и разбиваю его на дизайн, вёрстку, интеграцию оплаты и логистики, каждый транш идёт после того, как заказчик посмотрел конкретный результат и согласился, что это то, что он хотел. Без такой сверки итоговая приёмка превращается в спор о том, что было обещано изначально.

Аванс: какой процент брать и когда он оправдан

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

На мелких доработках - правка скрипта на Tilda, изменение логики формы, донастройка виджета - беру полную предоплату. Стоимость такой задачи от 3 000 ₽, работа занимает пару часов, и держать деньги в подвешенном состоянии до сдачи нет смысла ни мне, ни клиенту.

На проектах среднего масштаба - сайт на WordPress от 60 000 ₽, Telegram-бот от 30 000 ₽, автоматизация в n8n от 25 000 ₽ - стандартная практика это 30-50% авансом. Эта сумма покрывает риск исполнителя на старте и одновременно не выглядит грабительской для заказчика, который ещё не видел ни строчки кода.

На крупных вещах - веб-сервис или SPA от 150 000 ₽, CRM на React от 100 000 ₽ - я обычно снижаю долю аванса до 20-30% от суммы, но компенсирую это частыми промежуточными траншами. Смысл в том, что при большом бюджете 50% аванса это уже серьёзная сумма, которую заказчик отдаёт человеку, с которым ещё не поработал.

Промежуточные транши: как привязать оплату к результату

Самая рабочая логика - платёж идёт не за отрезок времени, а за проверяемый результат. “Оплата за две недели работы” ничего не говорит заказчику, а “оплата после того, как интеграция с СДЭК протестирована и рассчитывает доставку корректно” - понятная точка, которую можно принять или вернуть на доработку.

На проектах с интеграциями (эквайринг T‑Bank в связке с WooCommerce, расчёт доставки СДЭК, синхронизация с CRM) я обычно делю оплату так:

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

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

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

Это не жёсткий стандарт, а отправная точка - реальные цифры я всегда прописываю в договоре под конкретный объём работ.

Финальный расчёт: что проверять перед последним платежом

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

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

Если после сдачи нужно вести проект дальше - исправлять баги, обновлять зависимости, реагировать на инциденты - это отдельная услуга техподдержки от 15 000 ₽ в месяц, а не часть завершающего платежа.

Договор и акты приёма-передачи по этапам

Без письменной фиксации любая схема оплаты держится на честном слове, а это плохо работает, когда стороны не виделись вживую. В договоре или в переписке (для небольших задач это тоже приемлемо) фиксирую: сумму и сроки каждого этапа, что именно считается результатом этого этапа, и что происходит, если заказчик не принимает работу или не платит вовремя.

На проектах от 60 000 ₽ и выше подписываю акт после каждого крупного транша - не потому что это юридически обязательно в каждом случае, а потому что это снимает споры задним числом: “а мы разве это согласовывали” звучит гораздо реже, если есть подписанный документ с датой и описанием сданного этапа.

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

Частые ошибки в графике платежей

Повторяющиеся проблемы, с которыми сталкивался и как заказчик, и как исполнитель:

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

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

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

Какой процент аванса нормально просить у заказчика?

Зависит от масштаба: на мелких доработках беру 100% сразу, на проектах среднего размера - 30-50%, на крупных сервисах - 20-30% с компенсацией частыми промежуточными траншами.

Что делать, если заказчик просит начать работу без аванса?

На небольших задачах иногда соглашаюсь, если репутация заказчика проверяема (например, есть отзывы или предыдущие проекты). На крупных проектах от 100 000 ₽ работа без аванса - это риск потратить месяц без единой гарантии оплаты, поэтому я в таких случаях не берусь.

Можно ли платить одной суммой в конце, без этапов?

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

Что происходит, если заказчик не платит очередной транш?

Работа приостанавливается до оплаты - это стандартное условие, которое прописываю в договоре. Уже сданные и оплаченные этапы остаются у заказчика, но доступ к следующим модулям и передача исходников по неоплаченному этапу не происходит.