Выбор разработчика — это лотерея, если не задавать правильные вопросы. Красивое портфолио ещё не гарантирует, что проект будет сдан в срок и без боли. А дешёвая цена почти гарантирует переделки.
Вот 10 вопросов, которые стоит задать до начала работы. Они сэкономят вам время, деньги и нервы.
1. Покажите похожие проекты
Не «покажите портфолио», а именно «покажите проекты, похожие на мой». Если вам нужен SaaS — смотрите SaaS-проекты. Если лендинг — лендинги. Опыт в вашей нише важнее общего количества проектов.
На что обращать внимание:
- Сайт работает быстро? Откройте Google PageSpeed и проверьте
- Адаптивная вёрстка? Откройте с телефона
- Проект живой? Или заброшен через полгода после запуска
- Можно ли связаться с владельцем проекта и спросить об опыте работы
Если разработчик не может показать ни одного работающего проекта — это серьёзный риск.
2. На каком стеке работаете?
Стек — это набор технологий. WordPress, Next.js, Laravel, Tilda — каждый инструмент подходит для своих задач.
Вам не нужно разбираться в технологиях — нужно понимать почему выбран именно этот стек.
Хороший ответ: «Для вашего проекта я предлагаю Next.js, потому что нужна высокая скорость загрузки, SEO, и в будущем вы планируете добавлять функционал».
Плохой ответ: «Я работаю только на WordPress» (без обоснования, подходит ли это вам).
Универсального стека не существует. Лендинг можно сделать на Tilda за 2 дня. Сложный SaaS-продукт на Tilda не сделаешь — нужен кастомный стек.
3. Как выглядит процесс работы?
Профессиональный разработчик имеет процесс. Он может описать этапы:
- Сбор требований / техническое задание
- Прототип / макет
- Дизайн (если не предоставляется заказчиком)
- Вёрстка и разработка
- Тестирование
- Запуск
- Поддержка
Если ответ «ну, начну делать и покажу результат» — это хаос, а не процесс. Будут переделки, непонимание и срыв сроков.
4. Как будем общаться?
Коммуникация — причина 70% провалов в проектах. Выясните заранее:
- Какой мессенджер / канал для связи?
- Как часто будут промежуточные показы?
- Есть ли фиксированное время для созвонов?
- Кто будет контактным лицом (сам разработчик или менеджер)?
Идеальный вариант: еженедельные короткие созвоны + Telegram для оперативных вопросов + трекер задач (Notion, Trello, Linear) для прозрачности.
Если разработчик пропадает на неделю без объяснений на этапе обсуждения — он будет пропадать и во время работы.
5. Что входит в ТЗ и кто его составляет?
Техническое задание — документ, который описывает что именно будет сделано. Без ТЗ результат непредсказуем.
Варианты:
- Заказчик пишет ТЗ — требует технических знаний, но даёт максимальный контроль
- Разработчик пишет ТЗ — удобно, но убедитесь, что вы его понимаете и согласны
- Совместная работа — оптимальный вариант: вы описываете что нужно, разработчик переводит в технические требования
ТЗ должно фиксировать: страницы, функционал, интеграции, дизайн, адаптивность, SEO-требования. Всё, что не записано в ТЗ, будет трактоваться по-разному.
6. Какие сроки и что на них влияет?
Спросите не только «когда будет готово», но и:
- Что может повлиять на сроки?
- Что будет, если сроки сорвутся?
- Есть ли буфер на непредвиденные ситуации?
Реалистичные сроки:
- Лендинг: 1–2 недели
- Корпоративный сайт (5–10 страниц): 3–6 недель
- Интернет-магазин: 1–3 месяца
- SaaS-продукт (MVP): 1–3 месяца
Если разработчик обещает SaaS за неделю — он либо не понимает задачу, либо обманывает.
7. Как устроена оплата?
Стандартные модели:
- Фикс — фиксированная стоимость за весь проект. Понятно, но требует детального ТЗ
- Почасовая оплата — гибко, но сложнее контролировать бюджет
- Этапная оплата — оптимальный вариант: оплата по завершении каждого этапа
Типичная схема для фикса: 30% предоплата, 30% после утверждения макета, 40% после запуска.
Никогда не платите 100% вперёд. Никогда. Даже если разработчик «проверенный» и «с рекомендациями». Предоплата — максимум 30–50%.
8. Что будет после запуска?
Сайт — не памятник. После запуска нужна поддержка: обновления, исправление багов, доработки.
Вопросы:
- Есть ли гарантийный период? (обычно 1–3 месяца на исправление багов бесплатно)
- Как оплачивается поддержка после гарантии?
- Кто будет поддерживать сайт, если вы прекратите сотрудничество?
Важно: убедитесь, что вы получите все доступы — хостинг, домен, код, админка. Если разработчик владеет хостингом — вы зависите от него. Это плохая позиция.
9. Кому принадлежит код?
По умолчанию в России автор кода — разработчик. Чтобы права перешли к вам — это должно быть прописано в договоре.
Убедитесь, что в договоре есть пункт о передаче исключительных прав на результат работы. Без этого формально вы не имеете права модифицировать код или передать его другому разработчику.
Также попросите доступ к репозиторию (GitHub, GitLab). Код должен храниться там, а не только на компьютере разработчика.
10. Есть ли договор?
Работа без договора — риск для обеих сторон. Договор фиксирует:
- Объём работ (ТЗ как приложение)
- Сроки
- Стоимость и порядок оплаты
- Права на результат
- Ответственность сторон
- Порядок приёмки
- Гарантийные обязательства
Для фрилансеров часто используется договор ГПХ (гражданско-правового характера). Для студий — стандартный договор на оказание услуг.
Если разработчик отказывается от договора — ищите другого. Это базовый уровень профессионализма.
Красные флаги
Бегите, если разработчик:
- Не может показать живые проекты
- Обещает сроки «в два раза быстрее» конкурентов
- Не задаёт вопросов о вашем бизнесе (ему всё равно что делать)
- Берёт 100% предоплату
- Не работает по договору
- Не использует систему контроля версий (Git)
- Не может объяснить свой выбор технологий простым языком
Зелёные флаги
Хороший знак, если разработчик:
- Задаёт много вопросов до начала работы
- Предлагает решения, а не просто берёт задачу «как есть»
- Честно говорит «это займёт дольше, чем вы думаете»
- Показывает процесс и готов к промежуточной приёмке
- Сам инициирует договор и ТЗ
Выбор подрядчика — это инвестиция. Потратьте на него больше времени, чем кажется нужным. Переделка обходится в 2–3 раза дороже, чем правильный выбор с самого начала.