Веб-системы для бизнеса · код в вашем GitLab · оплата этапами
15 пунктов · спросите → сравните ответ с «Нормально» и «Насторожило»
Правило: Если 5 и больше пунктов «нет» или «не знаю» - не вносите полную предоплату. Начните с проработки (ТЗ, макеты) или небольшого пилота.
01 Есть этап проработки до кода
Спросите: Как выглядит этап до разработки? Что будет на руках - ТЗ, макеты, карта сценариев?
✓ Нормально: Отдельный этап с понятными артефактами, не «сразу в код».
⚠ Насторожило: «Сразу пишем код, разберёмся по ходу».
02 Макеты в Figma - до разработки
Спросите: Покажите, как выглядят экраны до начала кода. Где тестируются сценарии?
✓ Нормально: Макеты ключевых экранов; правки в макетах - до кода.
⚠ Насторожило: «Сначала код, потом посмотрите» или «дизайн на ходу».
03 Регулярные демо
Спросите: Как часто виден результат? Где смотреть - тестовый сервер, staging?
✓ Нормально: Демо каждые 1–2 недели на тестовом окружении.
⚠ Насторожило: «Покажем, когда всё будет готово».
04 Критерии приёмки в договоре
Спросите: Что считается «этап сдан»? Кто принимает и в какой срок?
✓ Нормально: Объём работ этапа + критерии приёмки + срок реакции на замечания.
⚠ Насторожило: «Сдадим - посмотрите, если что доработаем» без формулировок в договоре.
05 Код в вашем GitLab с первого дня
Спросите: Чей репозиторий? Когда предоставляется доступ?
✓ Нормально: Репозиторий создаёт заказчик; подрядчик работает с первого коммита.
⚠ Насторожило: «Код у нас, отдадим в конце» или «доступ после оплаты».
06 Code review
Спросите: Кто ревьюит код? Есть senior или архитектор?
✓ Нормально: Pull request / review до merge; архитектура - на опытном специалисте.
⚠ Насторожило: «Один разработчик всё делает сам, ревью не нужно».
07 Тесты по ключевой логике
Спросите: Что покрыто тестами? Что будет, если сломается расчёт, оплата или статус заказа?
✓ Нормально: Описывают, какие сценарии покрыты автотестами (100% не обязательно).
⚠ Насторожило: «Тесты потом, сначала фичи» или «ручками проверим».
08 Документация для передачи
Спросите: Что получит команда заказчика - README, деплой, доступы?
✓ Нормально: Документация входит в scope или отдельным этапом с датой.
⚠ Насторожило: «Разберётесь по коду» без описания деплоя и окружений.
09 Команда, а не один человек
Спросите: Кто делает дизайн, backend, frontend, DevOps? Что если ключевой человек недоступен?
✓ Нормально: Роли разделены; есть замена - не bus factor = 1.
⚠ Насторожило: Один fullstack «на всё» без бэкапа и без процесса передачи.
10 Архитектура до старта
Спросите: Как устроена система - модули, база, интеграции? Есть короткий документ?
✓ Нормально: До кода - схема: модули, данные, интеграции.
⚠ Насторожило: «Сделаем MVP, архитектуру потом переделаем».
11 Интеграции в смете явно
Спросите: 1С, платежи, телефония, API - где в смете? Что если API изменится?
✓ Нормально: Интеграции вынесены в scope с рисками.
⚠ Насторожило: «Интеграции - это мелочь, допилим по ходу».
12 Договор и процесс
Спросите: Работа по договору с ИП/ООО? Кто контакт? Что если команда меняется?
✓ Нормально: Договор, безнал, NDA; понятный контакт с доступом к команде.
⚠ Насторожило: Только Telegram без договора; «работаем на доверии».
13 Оплата этапами
Спросите: Как устроена оплата? Сколько этапов? Когда следующий платёж?
✓ Нормально: Предоплата за один этап вперёд; следующий - после приёмки предыдущего.
⚠ Насторожило: 100% предоплата или «50/50» без промежуточных точек.
14 Диапазон до детального ТЗ
Спросите: Откуда цифра в смете? Что нужно для точной оценки?
✓ Нормально: Сначала диапазон; точная цена - после проработки ТЗ.
⚠ Насторожило: Точная сумма «на глаз» без разбора модулей и сценариев.
15 Условия выхода
Спросите: Если сотрудничество прекращается - что остаётся у заказчика? Код, домен, сервер, документация?
✓ Нормально: Код в репозитории заказчика; описан процесс передачи.
⚠ Насторожило: «Система привязана к нашей инфраструктуре» без плана передачи.