Как основателю читать коммерческое предложение на разработку

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

Рабочее правило простое: если деталь не записана, считайте, что она не входит.

Хорошее описание объёма говорит, что может сделать пользователь, а не просто перечисляет экраны. «Пользователь может зарегистрироваться через почту или Google и сбросить пароль» можно проверить. «Модуль авторизации» — нельзя.

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

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

Если раздела с исключениями нет, попросите его добавить. Всё, что вы считали включённым, но что не вошло, потом вернётся в виде запроса на изменение.

Быть инженером не обязательно, но после прочтения вы должны уметь ответить на эти вопросы:

На чём будет сделан продукт — и почему именно этот стек для вашего продукта?

Кому принадлежат код и аккаунты: хостинг, домен, магазины приложений, аналитика?

Где будет размещён продукт и сколько примерно это будет стоить в месяц после запуска?

Будет ли код задокументирован достаточно, чтобы его мог подхватить другой разработчик?

Хорошее агентство объясняет свои решения простым языком. «Мы всегда так делаем» — не аргумент.

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

Спросите, как часто вы будете видеть прогресс. Еженедельные созвоны — разумный минимум; единственная демонстрация в самом конце — это риск.

Проверьте, упоминаются ли в предложении тестирование, производительность и доступность — или только функции.

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

Уточните, что именно покрывает цена и как разбиты платежи. Предоплата и платежи, привязанные к этапам, — стандарт; 100% заранее — нет.

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

Многие предложения заканчиваются днём запуска. Спросите, что дальше: есть ли период поддержки для исправления ошибок, сколько он длится и как оценивается дальнейшая работа.

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

Что именно не входит в работу?

Кто будет работать над проектом каждый день?

Что будет, если понадобится изменить объём работ?

Кому в итоге принадлежат код и все аккаунты?

Какая поддержка входит после запуска?