Чек-лист приёмки MVP от разработчика: 20 пунктов до оплаты

Три месяца назад ко мне обратился основатель с EdTech стартапом. MVP был «готов» — разработчики отрапортовали, последний транш оплачен, приложение в AppStore. Через две недели после запуска выяснилось: на Android-устройствах ниже 12-й версии платёж не проходил. Это 34% целевой аудитории — студенты с недорогими телефонами. Потерянная выручка за первый месяц — около 400 тысяч рублей. Чек-лист приёмки mvp — это не бюрократия. Это деньги.

Почему основатели принимают MVP «на доверие»

Механизм понятен: к концу разработки отношения с командой уже напряжённые, бюджет на исходе, инвесторы ждут демо. В этом состоянии очень хочется поверить, что всё работает — и нажать кнопку «принять». Разработчики показывают демо в идеальных условиях: свежий MacBook, последняя версия Chrome, тестовый пользователь с заполненными данными. Выглядит отлично.

Реальные пользователи приходят с iPhone 11 в режиме экономии заряда, вводят имя кириллицей с пробелом в конце и нажимают «оплатить» дважды, потому что первый раз ничего не произошло. Система ломается там, где её не тестировали.

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

Блок 1 — Функциональность (5 пунктов)

1. Каждая функция из ТЗ проверена по сценарию

Не «открыли приложение — выглядит хорошо». А пошагово: зарегистрировался → заполнил профиль → создал курс → добавил урок → пригласил студента → студент посмотрел → выставил оценку. Каждый шаг — отдельная строка в чек-листе. Если хоть один шаг не работает — MVP не принят.

2. Edge cases не ломают систему

Это самое частое место поломок. Проверьте:

• Пустые обязательные поля — должна быть понятная ошибка, не «500 Internal Server Error»
• Спецсимволы в полях: O'Brien, Иванов-Петров, email с плюсом user+test@mail.ru
• Экстремальные значения: сумма 999 999 999 рублей, имя из 200 символов, файл 0 байт
• Двойное нажатие на кнопку «Оплатить» или «Отправить» — должна быть защита от дублей

3. Мобильная версия на реальных устройствах

Эмулятор — это не тест. Возьмите три реальных устройства: флагман (iPhone 15 или Samsung S24), среднебюджетный Android (Xiaomi Redmi 12), старый Android (версия 10–11). Пройдите основной сценарий на каждом. Особое внимание: клавиатура перекрывает поля ввода, кнопки в нижней части экрана недостижимы на маленьких экранах, горизонтальная ориентация не ломает вёрстку.

4. Все интеграции работают в production, не в sandbox

Сделайте реальную транзакцию на 1 рубль через production-ключи платёжного шлюза. Отправьте реальное SMS на свой номер. Получите реальный email на ящик с реальным провайдером. Sandbox лжёт: он прощает ошибки, которые production не прощает.

5. Все платёжные сценарии: успех, отказ, возврат

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

• Успешная оплата: деньги списались, пользователь получил доступ, в базе появилась запись
• Отказ банка: карта заблокирована — пользователь видит понятное сообщение, доступ не предоставлен
• Возврат: рефанд через платёжный шлюз → деньги вернулись → доступ отозван

Блок 2 — Производительность (3 пункта)

6. Время загрузки главной страницы

Проверить через PageSpeed Insights (pagespeed.web.dev). Минимальная планка для MVP: Performance Score выше 70 на мобильных. LCP (Largest Contentful Paint) — менее 3 секунд. Если хуже — уточните у разработчиков: это временно или архитектурная проблема? Первое решается быстро, второе — потребует рефакторинга.

7. API отвечает быстро

Типовые запросы (логин, загрузка списка, создание сущности) должны возвращать ответ менее чем за 500 мс. Проверить без технических знаний: откройте DevTools в браузере (F12), вкладка Network, выполните действие в приложении — посмотрите на колонку «Time». Если запросы висят по 2–5 секунд — это проблема.

8. Нагрузочный тест на планируемую аудиторию

Для MVP достаточно простого теста: попросите разработчиков показать результаты нагрузки в 10x от ожидаемого на запуске. Если вы планируете 100 одновременных пользователей в первый месяц — система должна выдерживать 1 000. Инструменты: k6, Apache JMeter, Locust. Результат должен быть в виде отчёта, а не словами «протестировали, всё ок».

Блок 3 — Безопасность (4 пункта)

9. HTTPS на всех страницах и API-эндпоинтах

Открой любую страницу — в адресной строке должен быть замок. Проверьте также API: все запросы должны идти через HTTPS, не HTTP. Если хоть один эндпоинт работает по HTTP — данные пользователей передаются в открытом виде.

10. Нет открытых секретов в коде

Попросите доступ к репозиторию и выполните простую проверку. В терминале:

git log -p | grep -i "password\|secret\|token\|api_key" | head -50

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

11. SQL-инъекции заблокированы

Базовая проверка без технических знаний: в любое текстовое поле введите строку ' OR '1'='1 и попробуйте отправить форму. Правильная реакция — ошибка валидации или игнорирование. Неправильная — сервер «завис», вернул неожиданные данные или выдал 500. Если видите второе — у вас серьёзная уязвимость.

12. Персональные данные защищены (ФЗ-152 чек)

Четыре обязательных пункта для российского рынка: согласие на обработку персональных данных при регистрации (чекбокс + ссылка на политику), политика конфиденциальности на сайте, данные пользователей хранятся на серверах в России (если это российские пользователи — требование 152-ФЗ), возможность удалить аккаунт и данные по запросу.

Блок 4 — DevOps (4 пункта)

13. CI/CD работает

Попросите разработчика сделать небольшое изменение (поправить текст на странице) и задеплоить при вас. Если от коммита до обновления на staging проходит более 15 минут — CI/CD не настроен. Без этого каждое исправление после приёмки будет занимать часы и требовать ручной работы разработчика.

14. Мониторинг ошибок настроен

Покажите нам дашборд Sentry (или аналога). Ошибки должны фиксироваться автоматически с контекстом: какой пользователь, на каком устройстве, что делал, полный stack trace. Без мониторинга вы узнаёте об ошибках от пользователей, а не от системы.

15. Резервное копирование базы данных работает

Попросите разработчика показать последний бэкап и восстановить из него тестовую БД. «Бэкапы настроены» без реального теста восстановления — не принимается. 40% компаний, которые думают, что у них есть бэкапы, обнаруживают при аварии, что восстановление не работает.

16. Логи собираются и доступны

Должна быть возможность просмотреть лог любого запроса за последние 7 дней. Это нужно не только для отладки, но и для расследования инцидентов и разрешения споров с пользователями. Минимально — доступ по SSH с tail -f или централизованная система (Grafana Loki, ELK).

Блок 5 — Документация (4 пункта)

17. README с инструкцией запуска

Новый разработчик должен поднять проект локально за 30 минут, следуя README. Проверьте: возьмите чистую машину (или попросите коллегу) и попробуйте запустить проект по инструкции. Если не получается — документация неполная.

18. API-документация (Swagger или Postman)

Все эндпоинты должны быть задокументированы с примерами запросов и ответов. Это нужно не только для разработчиков — при смене команды (а она рано или поздно сменится) без API-документации вы заплатите за reverse engineering месяцы работы.

19. Файл .env.example без реальных секретов

В репозитории должен быть файл `.env.example` со списком всех переменных окружения и примерами значений (без реальных ключей). Это позволяет новому разработчику понять, какие секреты нужно получить для запуска проекта.

20. Схема базы данных

Документ или ER-диаграмма с описанием всех таблиц, связей, и назначения ключевых полей. Без схемы первый вопрос нового разработчика («а где хранятся платёжные транзакции?») превратится в часы исследования кода.

Как фиксировать результаты приёмки

Не устно. Каждый пункт — строка в Google Spreadsheet с колонками: пункт, статус (OK / FAIL / N/A), комментарий, дата проверки, кто проверял. Если пункт провален — он становится задачей в трекере с дедлайном. Финальная оплата проходит только после того, как все FAIL перешли в OK.

Это не недоверие к разработчикам. Это профессиональный процесс, который защищает обе стороны: вы получаете работающий продукт, разработчики — ясные критерии приёмки без субъективных претензий после оплаты.

Итог

Двадцать пунктов — это не много. Полный прогон занимает 4–8 часов, из которых большую часть делает ваша команда или подрядчик. Если разработчик отказывается помочь с приёмкой по чек-листу или говорит, что «это лишнее» — это красный флаг. Хорошая команда сама предлагает структурированную приёмку, потому что это защищает её репутацию.

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