Большинство основателей стартапов выбирают разработчика по двум критериям: цена и портфолио. Это понятно — других ориентиров нет, а времени на глубокую проверку не хватает. Но именно поэтому 60% проектов сталкиваются с проблемами уже в процессе разработки. Знать, что спросить разработчика до подписания договора — значит сэкономить месяцы и сотни тысяч рублей.
Почему цена и портфолио — плохие фильтры
Рассмотрим, как что спросить разработчика работает на практике.
Портфолио показывает, что студия умеет делать красивые скриншоты. Оно не показывает, как принимались решения, почему проект занял 8 месяцев вместо трёх, и что произошло с клиентом после сдачи. Цена — ещё менее надёжный индикатор: низкая цена часто означает либо джунов в команде, либо намеренный демпинг с последующими допработами.
Хороший подрядчик отличается от плохого не в портфолио — он отличается в разговоре. Правильные вопросы вскрывают то, что не написано на сайте студии.
Блок 1. Технические вопросы (5 вопросов)
Вопрос что спросить разработчика заслуживает детального анализа.
1. Какой стек вы используете для FinTech/EdTech MVP и почему?
Хороший ответ: Чёткое обоснование выбора стека под задачу. Например: «Для FinTech с высокой нагрузкой берём Go или Python + FastAPI, PostgreSQL, очереди на Redis. Для EdTech с видеоконтентом — Node.js + S3 + CloudFront». Они объясняют компромиссы.
Красный флаг: «Мы работаем на любом стеке» или называют один стек на все случаи жизни без объяснений. Такая студия либо не думает о задаче, либо будет делать всё на том, что знает лучше всего — вне зависимости от ваших потребностей.
2. Как вы тестируете код?
Хороший ответ: Unit-тесты обязательны, интеграционные — на критических путях (платежи, авторизация), E2E — на ключевых сценариях пользователя. Называют конкретный покрытие: «стремимся к 70%+ на бизнес-логике».
Красный флаг: «Тестируем вручную» или «у нас есть QA, он всё проверит». Для FinTech это неприемлемо — один баг в логике начисления баланса может стоить вам регуляторных проблем.
3. Есть ли у вас CI/CD? Как выглядит процесс деплоя?
Хороший ответ: GitHub Actions / GitLab CI с автоматическими тестами перед мержем, staging-окружение для проверки перед production, автоматический деплой по тегу или мержу в main.
Красный флаг: «Деплоим вручную по FTP» или «разработчик заливает файлы». Такой процесс — прямой путь к ситуации «работало на моей машине».
4. Где будет хоститься продукт и кто управляет инфраструктурой?
Хороший ответ: Предлагают Yandex Cloud или Hetzner для российского рынка, объясняют, почему. Готовы настроить под вас или передать управление после сдачи. Инфраструктура описана в IaC (Terraform/Ansible).
Красный флаг: «Хостим у себя на серверах» без возможности миграции. После такого ответа вы навсегда зависимы от подрядчика.
5. Как вы мониторите production после запуска?
Хороший ответ: Sentry для ошибок, Grafana или DataDog для метрик, алерты в Telegram/Slack. Называют конкретные инструменты и описывают процесс реагирования на инциденты.
Красный флаг: «Мониторинг — не наша зона ответственности» или молчание. Без мониторинга вы узнаёте о падении продукта от пользователей — в самый неподходящий момент.
Блок 2. Процессные вопросы (5 вопросов)
Именно что спросить разработчика определяет результат для бизнеса.
6. Как организован процесс разработки? Покажите, как выглядит типичная неделя
Хороший ответ: Еженедельные демо или статус-апдейты, задачи в Jira/Linear, прозрачный backlog. Вы видите прогресс в реальном времени, а не «всё хорошо» раз в две недели.
Красный флаг: «Мы работаем итерациями, не беспокойтесь». Любое обещание не беспокоить клиента — признак того, что коммуникация будет проблемой.
7. Как вы обрабатываете изменения в ТЗ в процессе разработки?
Хороший ответ: Есть процедура change request с оценкой влияния на сроки и бюджет. Небольшие изменения — в рамках буфера, крупные — через отдельный договор.
Красный флаг: «Мы гибкие, всё сделаем» без описания процедуры. Это сигнал, что студия либо будет делать всё молча, накапливая недовольство, либо потом выставит счёт на «неучтённые работы».
8. Кто проводит code review и как?
Хороший ответ: Обязательный review перед мержем от минимум одного разработчика не из числа авторов кода. Называют критерии: читаемость, тесты, соответствие архитектурным решениям.
Красный флаг: «Code review делает тимлид когда есть время». Это значит, что в 60% случаев его не делает никто.
9. Какую документацию вы сдаёте вместе с кодом?
Хороший ответ: README с инструкцией по запуску, API-документация (Swagger/OpenAPI), архитектурная схема, описание переменных окружения. Это база для последующей поддержки.
Красный флаг: «Код самодокументируем» или «документацию пишем по запросу». Через год после сдачи вы не сможете онбордить нового разработчика без автора кода.
10. Как передаёте проект на поддержку после сдачи?
Хороший ответ: Есть процедура hand-off: передача доступов, инструктаж команды клиента или поддержки, период гарантийного сопровождения (обычно 1–3 месяца).
Красный флаг: «Сдали — до свидания». Большинство проблем в production возникает в первые 30 дней после запуска. Без гарантийного периода вы один на один с багами.
Блок 3. Бизнесовые вопросы (5 вопросов)
При правильном подходе что спросить разработчика становится конкурентным преимуществом.
11. Кому принадлежит код после сдачи проекта?
Хороший ответ: «Полностью вам — все права на исходный код, документацию и материалы переходят заказчику в момент финальной оплаты». Это должно быть зафиксировано в договоре.
Красный флаг: Любые оговорки вида «мы сохраняем права на переиспользование компонентов». Особенно опасно для FinTech — ваши алгоритмы скоринга не должны оказаться в продукте конкурента.
12. Готовы ли вы подписать NDA?
Хороший ответ: «Да, это стандартная процедура». Профессиональные студии подписывают NDA без вопросов — это норма рынка.
Красный флаг: «Нам это не нужно, мы и так не разглашаем». Устные гарантии не работают в арбитраже.
13. Какие гарантии прописаны в договоре?
Хороший ответ: Гарантийный период (минимум 30 дней), чёткие критерии приёмки работ, ответственность за срыв сроков. Некоторые студии предлагают SLA на гарантийный период.
Красный флаг: «Гарантии — стандартные, по ГК РФ». Это означает, что студия намеренно уходит от конкретики. Попросите показать шаблон договора заранее.
14. Что произойдёт с проектом, если ваша студия закроется?
Хороший ответ: Весь код в вашем репозитории с первого дня. Нет зависимости от серверов студии. Документация позволяет любому разработчику подхватить проект.
Красный флаг: Замешательство или «такое не произойдёт». Студии закрываются. Это реальность рынка — особенно в периоды экономической нестабильности.
15. Дадите контакты двух последних клиентов для референс-колла?
Хороший ответ: «Конечно, вот контакты». Компания, которой нечего скрывать, без проблем даёт референсы.
Красный флаг: «Клиенты не хотят раскрывать свои контакты» или отговорки о конфиденциальности. Можно попросить анонимный e-mail или встречу в зуме без упоминания имён — хорошая студия найдёт способ.
Особенности для FinTech и EdTech
Далее — о ключевых аспектах что спросить разработчика.
Два дополнительных вопроса, если вы строите FinTech:
- «Есть ли у вас опыт работы с 152-ФЗ, PCI DSS или требованиями ЦБ?» — хороший ответ включает конкретные проекты и описание того, как compliance был реализован технически.
- «Как вы обеспечиваете безопасность финансовых данных?» — ожидаем: шифрование at rest и in transit, разграничение доступов, логирование всех операций.
Два вопроса для EdTech:
- «Работали ли вы с видеохостингом и стримингом?» — важно для LMS с видеокурсами. Студия должна понимать разницу между хранением видео и его стримингом с адаптивным битрейтом.
- «Есть ли опыт интеграции со сторонними LMS (Moodle, Teachable, GetCourse)?» — если планируете не строить всё с нуля.
Итог: как использовать этот чек-лист
Опыт показывает: что спросить разработчика требует системного подхода.
Проведите звонок на 45–60 минут с каждым из 2–3 финалистов. Задавайте вопросы не по списку, а в разговоре — смотрите не только на ответы, но на то, как быстро отвечают, уточняют ли они детали вашего продукта, предлагают ли альтернативные решения.
Хорошая студия задаёт вопросы сама: о ваших пользователях, о compliance-требованиях, о планах масштабирования. Студия, которая сразу говорит «сделаем» без уточнений — берётся за проект не думая.
Если хотите проверить, как IT2BE отвечает на эти 15 вопросов — запишитесь на 30-минутный Zoom-колл. Отвечаем прямо, показываем реальные проекты и даём контакты клиентов без лишних просьб.
FAQ о том, что спросить разработчика
Понимание что спросить разработчика критически важно для принятия решений.
Как проверить портфолио разработчиков без технических знаний?
Попросите рассказать о конкретном проекте: с какой проблемой пришёл клиент, какие решения рассматривались, почему выбрали именно этот подход, с какими трудностями столкнулись. Хорошая студия объясняет решения понятно для нетехнического заказчика. Также можно запросить референс-колл с предыдущим клиентом — это самая честная проверка.
Нужен ли NDA при разработке MVP?
Да, особенно в FinTech. NDA защищает вашу бизнес-модель, алгоритмы и данные пользователей от разглашения. Профессиональные студии подписывают NDA без возражений — это стандарт рынка. Отказ от NDA или попытки его размыть — красный флаг.
Что значит «фиксированная цена» в договоре разработки?
Фиксированная цена означает, что итоговая стоимость не изменится при условии неизменного ТЗ. Любые изменения в scope оформляются отдельным change request с согласованной стоимостью. Это отличается от Time & Material, где счёт выставляется по факту потраченных часов. Для seed-стартапов фиксированная цена предпочтительнее — вы знаете точную цифру для pitch-deck.
Как выбрать между junior- и senior-командой для MVP?
Для FinTech MVP — только senior или mixed команда с сильным тимлидом. Цена ошибки в финансовых данных слишком высока. Для EdTech без сложной бизнес-логики подойдёт mixed команда. Полностью junior-команда для MVP не подходит: скорость разработки ниже из-за частых ревью и переделок, а технический долг делает масштабирование дорогим.