Как происходят расчёты за разработку проекта: от утверждения ТЗ до передачи готового продукта

Для исполнителя — иметь понятную финансовую модель, которая позволяет начать разработку, довести её до готового состояния и безопасно передать результат заказчику.

В WebRuta мы используем достаточно простую схему:

Утверждение ТЗ и КП
        ↓
10% перед началом разработки
        ↓
Локальная разработка проекта
        ↓
Подтверждение готовности
        ↓
Оставшиеся 90%
        ↓
Deployment на VPS
        ↓
Настройка production
        ↓
Передача проекта заказчику

Разберём каждый этап подробнее.

Сначала фиксируются ТЗ, стоимость и сроки

Расчёты начинаются не с оплаты.

Сначала обе стороны должны понимать, что именно будет разработано.

До старта проекта формируется техническое задание, в котором описываются:

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

После этого проект оценивается.

Формируется коммерческое предложение, где фиксируются:

состав работ;
стоимость разработки;
сроки;
порядок расчётов;
условия запуска;
порядок передачи проекта.

Только после подтверждения заказчиком ТЗ и коммерческого предложения начинается следующий этап.

Первый платёж — 10% от стоимости проекта

Перед началом разработки заказчик вносит:

10% от общей стоимости проекта.

Например, если разработка оценена в:

600 000 ₽

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

60 000 ₽

После этого проект переходит в разработку.

Такая схема позволяет зафиксировать намерение заказчика действительно запускать проект, но при этом основная часть стоимости ещё не выплачивается.

Для клиента это означает, что до появления готового результата он не передаёт исполнителю большую часть бюджета.

Почему не требуется 100% предоплата до разработки

Для сложного веб-продукта разработка может занимать значительное время.

Это может быть:

CRM;
SaaS;
личный кабинет;
B2B-портал;
интернет-магазин;
корпоративная система;
сервис с интеграциями.

Поэтому модель полной оплаты ещё до начала работ часто создаёт слишком большой риск уже для заказчика.

В нашей схеме первоначальные 10% являются стартовым платежом.

Основные 90% выплачиваются только после того, как проект уже разработан локально и исполнитель может подтвердить его готовность.

Получается более понятная точка баланса:

10%
→ запуск разработки

90%
→ после фактической готовности проекта

Что означает «проект готов локально»

До публикации в интернете проект разрабатывается в рабочей среде исполнителя.

К этому моменту должны быть реализованы функции, предусмотренные утверждённым ТЗ.

Например:

Frontend
Backend
Database
Административная панель
Авторизация
Роли пользователей
Файлы
Уведомления
Интеграции
Фоновые процессы

В зависимости от проекта состав может отличаться.

Главный критерий:

согласованный объём разработки уже выполнен.

Проект находится в состоянии готового release, который можно переносить на production-инфраструктуру заказчика.

Локальная готовность и работа в интернете — разные этапы

Это важно понимать заранее.

Если приложение работает на компьютере разработчика, это ещё не означает, что оно уже опубликовано в интернете.

После локальной разработки необходимо отдельно выполнить production deployment.

Например:

Готовый локальный проект
        ↓
VPS заказчика
        ↓
Backend
Database
Nginx
SSL
Domain
Workers
Storage
Backup
Monitoring

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

Как заказчик узнаёт, что проект действительно готов

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

В зависимости от типа продукта это может включать:

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

Главная задача этого этапа — не просто сообщить:

Проект готов.

А дать заказчику понятное подтверждение того, что согласованная разработка действительно выполнена.

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

Например, в ТЗ указано:

Регистрация пользователей
Авторизация
Личный кабинет
Создание проектов
Файлы
Сообщения
Уведомления
Админ-панель
Мобильная версия

При подтверждении локальной готовности можно пройти по этим пунктам:

Регистрация             ✓
Авторизация             ✓
Личный кабинет          ✓
Создание проектов       ✓
Файлы                   ✓
Сообщения               ✓
Уведомления             ✓
Админ-панель            ✓
Мобильная версия        ✓

Так у заказчика есть конкретное основание переходить к следующему финансовому этапу.

После подтверждения готовности оплачиваются оставшиеся 90%

Когда согласованный проект разработан и заказчику подтверждена его локальная готовность, производится окончательный расчёт.

Заказчик оплачивает:

оставшиеся 90% стоимости проекта.

Если вернуться к примеру со стоимостью:

600 000 ₽

то схема выглядит так:

Перед разработкой:
60 000 ₽

После локальной готовности:
540 000 ₽

Общая стоимость остаётся:

600 000 ₽

Никакой дополнительной оплаты из-за самого факта разделения платежей не появляется.

Почему основной расчёт происходит до deployment

После переноса проекта на VPS ситуация принципиально меняется.

Продукт начинает размещаться на инфраструктуре заказчика.

На сервере могут оказаться:

исходный код;
production build;
база данных;
миграции;
конфигурация;
файлы проекта.

Затем выполняется привязка домена, настройка HTTPS и остальных production-сервисов.

Фактически разработанный результат начинает переходить под контроль клиента.

Именно поэтому полная оплата согласованной стоимости проекта завершается до production deployment, а не после окончательной передачи всей системы.

При этом заказчик не оплачивает «обещание»

Это принципиальный момент.

Оставшиеся 90% выплачиваются не сразу после первого платежа и не в середине разработки.

К этому моменту:

ТЗ утверждено;
КП утверждено;
стоимость известна;
сроки известны;
проект разработан;
готовность подтверждена.

То есть финансовая контрольная точка находится между:

готовым результатом разработки

и:

передачей этого результата
в production заказчика.

После полного расчёта начинается deployment

Далее исполнитель переносит проект на сервер.

Если используется VPS, выполняется подготовка production-среды.

В зависимости от технологического стека необходимо установить и настроить:

Docker;
Node.js;
PostgreSQL;
Redis;
Nginx;
Object Storage;
background workers;
systemd;
другие необходимые компоненты.

Состав зависит от конкретной архитектуры.

Сначала проверяется сам VPS

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

Проверяются:

CPU;
RAM;
SSD/NVMe;
операционная система;
свободное место;
сеть;
порты;
доступ SSH.

Если приложение рассчитано, например, на 4 ГБ RAM, попытка запустить его на VPS с 512 МБ памяти создаст проблемы независимо от качества разработки.

Поэтому инфраструктура тоже является частью запуска.

Затем переносится приложение

Готовый release загружается на сервер.

Подготавливаются:

frontend;
backend;
dependencies;
environment;
database migrations;
worker;
storage.

При необходимости создаются Docker-контейнеры или настраиваются системные сервисы.

Создаётся production-база данных

Локальная development-база и production-база — это разные среды.

На сервере создаётся рабочая база.

Выполняются migrations.

Например:

001_initial_schema
002_users
003_projects
004_notifications
...

Если проект передаётся уже с подготовленными данными, выполняется их безопасный перенос.

Создаются production-секреты

На сервере могут понадобиться:

DATABASE_URL
SESSION_SECRET
JWT_SECRET
ENCRYPTION_KEY
SMTP_PASSWORD
S3_ACCESS_KEY
ADMIN_SECRET

Production-секреты не должны находиться во frontend или в публичном репозитории.

Они создаются и размещаются в защищённой конфигурации сервера.

Настраивается домен

Далее рабочий домен направляется на сервер.

Например:

project.ru
     ↓
DNS
     ↓
IP VPS

При необходимости настраиваются:

A;
AAAA;
CNAME;
TXT;
MX.

Конкретные записи зависят от проекта.

Подключается HTTPS

После правильной настройки DNS выпускается SSL/TLS-сертификат.

После этого рабочий адрес выглядит:

https://project.ru

а обычный HTTP перенаправляется на HTTPS.

Настраивается Nginx

Для многих проектов используется примерно такая схема:

Интернет
   ↓
Nginx
   ↓
Backend
   ↓
PostgreSQL

Nginx может отвечать за:

HTTPS;
reverse proxy;
статику;
сжатие;
security headers;
ограничения запросов.

Запускаются фоновые процессы

Если приложение имеет:

уведомления;
email;
очереди;
обработку файлов;
отложенные задачи;
интеграции,

одного backend-процесса недостаточно.

Необходимо также запустить worker и scheduler.

После deployment проект ещё раз проверяется

Даже если локально всё работало идеально, production имеет свои особенности.

Например:

другой домен;
HTTPS;
другая база;
proxy;
SMTP;
filesystem;
Object Storage;
timezone;
cookie;
firewall.

Поэтому после запуска выполняется production QA.

Какие сценарии проверяются

В зависимости от проекта:

Открывается ли сайт?
Работает ли регистрация?
Работает ли вход?
Работает ли восстановление пароля?
Создаются ли проекты?
Загружаются ли файлы?
Работает ли админ-панель?
Приходят ли уведомления?
Работает ли почта?
Запускаются ли фоновые задачи?
Работает ли мобильная версия?

Проект считается корректно развёрнутым не тогда, когда файлы появились на VPS, а когда реальные пользовательские сценарии работают через production-домен.

Если после запуска обнаруживается дефект

Например, ТЗ предусматривало:

Пользователь может загружать PDF.

На production выяснилось, что из-за server configuration файлы больше определённого размера не загружаются.

Это не новая функция.

Это defect согласованного функционала.

Он исправляется при доведении проекта до рабочего состояния.

Но новая функция после готовности — это уже изменение проекта

Например, после запуска клиент говорит:

Давайте теперь автоматически отправлять каждый загруженный PDF в 1С.

Если этого не было в утверждённом ТЗ, это новое требование.

Для него отдельно оцениваются:

объём;
срок;
стоимость;
риски.

Так первоначальная разработка не превращается в бесконечный поток новых задач внутри уже согласованной стоимости.

После запуска проект полностью передаётся заказчику

После успешного production deployment и проверки заказчик получает комплект проекта.

В него может входить:

ZIP-архив проекта;
исходный код;
production-файлы;
документация;
описание архитектуры;
инструкция по deployment;
данные о конфигурации;
доступы;
ключи;
секреты.

Конкретный состав зависит от проекта.

Зачем передавать ZIP-архив

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

Например:

project-final.zip

Так исходный результат находится не только внутри VPS.

Клиент может сохранить его:

локально;
в корпоративном хранилище;
в резервной копии.

Документация не менее важна, чем исходники

Архив без описания иногда мало полезен.

Поэтому вместе с проектом желательно передать документацию.

Например:

README
DEPLOYMENT
ARCHITECTURE
BACKUP
RESTORE
ENVIRONMENT

Из неё должно быть понятно:

Как устроен проект?

Как его запустить?

Какие сервисы используются?

Как сделать backup?

Как восстановиться?

Как обновить приложение?

Что происходит с ключами и секретами

Если ключи принадлежат проекту клиента, после передачи клиент должен иметь к ним доступ.

Например:

production encryption keys;
API tokens;
SMTP credentials;
storage credentials;
admin credentials.

При этом желательно не хранить их прямо внутри исходного ZIP в открытом виде.

Секреты лучше передавать отдельно и безопасно.

Инфраструктура также должна принадлежать заказчику

При возможности VPS и домен желательно оформлять непосредственно на клиента.

Тогда после завершения проекта:

домен принадлежит клиенту;
VPS принадлежит клиенту;
исходники находятся у клиента;
секреты находятся у клиента.

Исполнитель не становится обязательным посредником между владельцем бизнеса и его собственным продуктом.

После завершения клиент может сменить пароли

Если для deployment заказчик предоставлял временный доступ к:

VPS;
регистратору домена;
панели хостинга;
другим сервисам,

после передачи проекта пароли можно изменить.

Ещё лучше использовать отдельные временные аккаунты, если сервис их поддерживает.

Например:

Главная учётная запись клиента
        +
временный технический пользователь

После завершения работ временного пользователя можно удалить.

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

Если собрать все этапы вместе:

1. Обсуждение проекта
        ↓
2. Подготовка ТЗ
        ↓
3. Оценка проекта
        ↓
4. Коммерческое предложение
        ↓
5. Подтверждение ТЗ и КП
        ↓
6. Оплата 10%
        ↓
7. Начало разработки
        ↓
8. Локальная разработка
        ↓
9. Тестирование
        ↓
10. Подтверждение готовности клиенту
        ↓
11. Оплата оставшихся 90%
        ↓
12. Подготовка VPS
        ↓
13. Deployment
        ↓
14. Домен + HTTPS
        ↓
15. Production QA
        ↓
16. Исправление выявленных дефектов
        ↓
17. Передача ZIP и документации
        ↓
18. Передача ключей и доступов
        ↓
19. Проект полностью у заказчика

Что получает клиент в обмен на первый платёж

Первоначальные 10% — это не плата за весь будущий продукт.

Это финансовая точка запуска проекта.

После неё исполнитель начинает работу по утверждённому ТЗ.

Основные 90% остаются у клиента до появления готового результата.

Что получает клиент перед оплатой 90%

До окончательного расчёта у заказчика уже должно быть подтверждение:

согласованный функционал реализован;
проект собран;
основные сценарии работают;
локальная разработка завершена;
продукт готов к production deployment.

Только после этого происходит основная оплата.

Что клиент получает после оплаты 90%

После полного расчёта работа не заканчивается.

Наоборот, начинается этап передачи продукта.

Исполнитель обязан:

перенести проект на VPS;
настроить окружение;
подключить БД;
настроить домен;
настроить HTTPS;
запустить необходимые сервисы;
проверить production;
исправить обнаруженные дефекты;
передать исходники;
передать документацию;
передать необходимые доступы.

Таким образом окончательная оплата означает не:

Исполнитель получил деньги и проект закончен.

Она означает:

Разработанный результат переходит из локальной среды в production и передаётся заказчику.

Почему такая схема понятна обеим сторонам

Риск распределяется между заказчиком и исполнителем.

Для заказчика

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

10%

Основной платёж производится после подтверждения выполненной разработки.

Для исполнителя

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

То есть после фактической передачи уже не остаётся большого неоплаченного остатка.

Главное — согласовать этот порядок до начала разработки

Самая плохая ситуация возникает, когда финансовые правила впервые обсуждаются уже после появления готового проекта.

Например:

Кстати, теперь нужно оплатить ещё 90%.

Для заказчика это выглядит как новое условие.

Поэтому порядок:

10% перед началом;
90% после локальной готовности;
production после полного расчёта

должен быть известен и согласован ещё на этапе коммерческого предложения.

Тогда обе стороны заранее понимают процесс.

Что происходит, если проект не готов

Если разработка ещё не соответствует утверждённому ТЗ, оснований переходить к окончательному расчёту нет.

Сначала исполнитель должен довести согласованный объём до готового состояния.

Контрольная точка — готовность результата, а не просто истечение запланированного срока разработки.

Что происходит, если заказчик после готовности не производит окончательный расчёт

В этом случае проект не передаётся в production-инфраструктуру клиента до выполнения согласованных финансовых условий.

Это намного безопаснее, чем:

сначала полностью передать проект
↓
потом пытаться получить оплату

Не требуется отключать уже работающий сервис или вмешиваться в инфраструктуру клиента.

Production deployment просто ещё не начался.

Прозрачная схема лучше сложного количества платежей

Существует много моделей:

30 / 30 / 40
20 / 40 / 40
оплата каждого этапа
почасовая оплата
ежемесячный retainer

Все они могут быть нормальными.

Но если стоимость проекта уже точно определена и scope стабилен, схема:

10%
+
90%

имеет важное преимущество — её легко понять.

Заказчик заранее знает:

Сколько я плачу?

Когда?

Что должно произойти перед следующим платежом?

Что произойдёт после него?

Чем меньше финансовой неопределённости, тем проще сама работа над проектом.

Вместо вывода

Разработка сложного веб-продукта — это не одна операция:

Сделали сайт → получили деньги.

Между идеей и готовой production-системой существует несколько разных состояний.

В нашей модели финансовая схема привязана к двум понятным контрольным точкам.

Первая:

ТЗ и КП согласованы
↓
10%
↓
начинается разработка

Вторая:

проект готов локально
↓
готовность подтверждена заказчику
↓
оставшиеся 90%
↓
production deployment и передача

После полного расчёта исполнитель не просто передаёт ZIP-файл.

Проект переносится на VPS, настраивается, подключается к рабочему домену, проходит production-проверку, а заказчик получает исходники, документацию, необходимые ключи и контроль над своей инфраструктурой.

Такая схема делает расчёты понятной частью процесса разработки.

Заказчик не оплачивает основную сумму до появления готового результата.

Исполнитель не передаёт полностью разработанный продукт до закрытия согласованной стоимости.

А момент оплаты связан не с обещаниями одной из сторон, а с конкретным техническим состоянием проекта.

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