Как заказать разработку и не получить систему, которую страшно развивать
15 вопросов подрядчику в формате переписки - что нормально, а что тревожно
Вы планируете заказать CRM, маркетплейс, SaaS или внутреннюю систему - и не хотите через год переписывать всё с нуля.
Ниже - как может выглядеть переписка с подрядчиком: ваши вопросы и два типа ответов. Зелёная галочка - нормально. Красный крест - повод насторожиться.
Правило: Если 5+ пунктов с «тревожными» ответами - не вносите полную предоплату. Начните с проработки или пилота.
Представитель компании
был недавно
01 · Есть этап проработки до кода
Расскажите, как у вас выглядит старт. До кода что будет на руках - ТЗ, макеты, карта сценариев?
Да, сначала отдельный этап: соберём ТЗ, накидаем макеты и карту сценариев. Код - только когда вы окнете объём. Так спокойнее для обоих.
Да норм, сразу в код пойдём - по ходу разберёмся, что нужно. ТЗ потом допишем, если понадобится.
02 · Макеты в Figma - до разработки
А экраны до разработки где смотреть? Хочу пройтись по сценариям, пока не поздно.
Конечно, всё в Figma до старта кода. Покажем ключевые экраны, вы потыкаете - правки в макетах быстрее и дешевле, чем в коде.
Ну мы обычно сразу верстаем, а вы по ходу смотрите. Дизайн там по месту докрутим, не переживайте.
03 · Регулярные демо
Как часто смогу видеть, что получается? Есть тестовый стенд или только в конце?
Раз в одну–две недели - созвон и ссылка на staging. Не сюрпризом в конце - видите прогресс по ходу.
Покажем, когда будет что показывать 🙂 Сейчас рано отвлекать - лучше сразу сделать нормально и один раз сдать.
04 · Критерии приёмки в договоре
А как понимаем, что этап сдан? Это где-то в договоре прописано или на словах?
В договоре: что входит в этап, как принимаете, сколько дней на замечания. Без этого мы сами не стартуем - так меньше ссор потом.
Ну сдадим, вы посмотрите. Если что - подправим, мы же не звери. В договор детали обычно не лезем, там и так много бумаги.
05 · Код в вашем GitLab с первого дня
Код чей будет? Когда дам доступ к репозиторию - с первого дня или в конце?
Ваш GitLab с первого коммита. Создаёте репо, добавляете нас - всё прозрачно, код ваш с самого начала.
Пока крутим у себя, в конце перенесём. Или доступ после предоплаты - так у всех, а то сливают наработки.
06 · Code review
Кто смотрит код за разработчиками? Есть человек, который ревьюит и архитектуру держит?
Да, значимые PR смотрит senior - архитектура, безопасность. Не один человек «на доверии» всё мержит.
Да я сам всё пишу, 10 лет опыт - ревью только время съедает. Зачем усложнять?
07 · Тесты по ключевой логике
А если сломается оплата или расчёт - у вас это как-то тестами прикрыто?
По ключевым сценариям - да, автотесты. Не 100% покрытие, но оплата, статусы, расчёты - обязательно. Можем показать, что именно.
Тесты потом добавим, сначала фичи важнее. Мы и так всё руками проверяем перед сдачей, норм.
08 · Документация для передачи
Если потом свою команду подключу - README, деплой, доступы будет?
Да, README, как поднять окружение, доступы - либо в проекте, либо отдельным этапом с датой. Чтобы не «разбирайтесь сами по коду».
Код же понятный, там разберутся. Документацию отдельно не закладывали - это же лишние часы.
09 · Команда, а не один человек
Кто конкретно делает - один человек на всё или команда? А если ключевой заболеет?
Команда: дизайн, бэк, фронт, DevOps. Если кто-то выпадает - есть замена, не всё на одном человеке.
Я fullstack, сам всё закрою. Быстрее и дешевле, чем возить толпу. Если что - найду кого на подхват, но в основном я.
10 · Архитектура до старта
Можете до старта набросать, как система устроена - модули, база, интеграции?
Да, короткая схема до кода: что за что отвечает, где данные, какие интеграции. Не «сделаем и увидите».
На MVP архитектура не критична - главное быстрее выкатить. Потом, если вырастет, переделаем.
11 · Интеграции в смете явно
1С, платежи, телефония - это в смете отдельно или «включено»?
Интеграции отдельной строкой в scope, с рисками. Если API капризничает - обсуждаем заранее, не «допилим потом».
Да это мелочь, входит в общую цену. API обычно простые, на месте разберёмся.
12 · Договор и процесс
Работаем по договору? Кто мой контакт - не только чат, куда писать по делу?
Договор, безнал, NDA если нужно. Контакт - живой, с доступом к тем, кто код пишет, не «менеджер передаст».
Давайте в Telegram, договор потом, когда поймём что работаем. Мы же нормальные ребята, зачем бюрократия.
13 · Оплата этапами
Оплата как - сразу весь бюджет или по этапам?
По этапам: предоплата за один этап вперёд, следующий - после того как примете предыдущий. Не замораживаете всё сразу.
Обычно 50% в начале, 50% в конце - так проще. Или полная предоплата, мы же материалы и людей бронируем.
14 · Диапазон до детального ТЗ
Откуда цифра в смете? Для точной цены что ещё нужно?
Сейчас - диапазон после разбора задачи. Точная сумма после нормального ТЗ: модули, API, сценарии. Иначе это угадайка для всех.
Ну примерно 2,5 млн, плюс-минус. Точнее скажем по ходу - сейчас сложно, вы же сами до конца не знаете, что хотите.
15 · Условия выхода
Если не сработаемся - код, домен, сервер остаются у меня?
Код ваш с первого дня, доступы ваши. Пропишем, как передаём - чтобы не «без нас ничего не работает».
Система у нас на сервере, так удобнее поддерживать. Перенос - отдельная история, если решите уходить.
Краткий итог
Большинство техдолгов начинается не с плохого кода, а с пропущенных вопросов до договора.
Если подрядчик уверенно закрывает 12–15 пунктов - риск существенно ниже. Если меньше половины - не спешите с полной предоплатой.
Что делать дальше
- Используйте эти вопросы на созвоне с подрядчиком.
- Зафиксируйте ответы письменно - устных «да-да» недостаточно.
- Сравните 2–3 подрядчиков по одним пунктам.
Материал носит рекомендательный характер и не является юридической или технической экспертизой конкретного проекта.
Эта страница — переписка, не для печати
Для созвона используйте деловой чек-лист: в каждом пункте «Спросите», «Нормально» и «Насторожило».
Откройте версию для печати или скачайте PDF внизу статьи.
