Как выбрать подрядчика на custom SaaS и не сжечь бюджет на MVP

Вы решили строить собственный SaaS-продукт. Уже есть гипотеза, первые потенциальные клиенты и бюджет. Остался один вопрос: кому это отдать? Именно здесь большинство проектов начинают умирать — не на этапе разработки, а на этапе выбора команды. Неправильный подрядчик не просто потратит ваши деньги: он потратит их на то, что не нужно рынку. Этот гайд написан на основе опыта команды LEGKO, которая прошла через десятки SaaS-проектов — от маленьких MVP до многомодульных B2B-платформ. Здесь — только то, что работает на практике.

Главное

• Начинайте с MVP, который решает одну острую проблему, а не с копирования функционала гигантов.
• Требуйте от подрядчика прозрачности на этапе Discovery: дизайн и архитектура должны быть согласованы до написания первой строки кода.
• Владелец продукта со стороны клиента — обязательное условие успеха, без него проект теряет фокус.
• Исходный код, доступы к инфраструктуре и документация — это ваша собственность, которую вы должны получить по завершении каждого этапа.

Когда нужен custom SaaS, а когда достаточно no-code

Прежде чем искать подрядчика, ответьте на один вопрос: точно ли вам нужна разработка с нуля? Если ваша бизнес-логика укладывается в стандартные сценарии — управление задачами, простая CRM, лендинг с формой — no-code-инструменты закроют задачу быстрее и дешевле. Custom SaaS оправдан, когда у вас есть уникальная бизнес-логика, которую нельзя собрать из готовых блоков, или когда масштаб предполагает тысячи пользователей с нетривиальными правами доступа, интеграциями и нагрузкой.

Признаки того, что пора в custom-разработку

• Уникальный процесс: ваш продукт автоматизирует что-то специфичное для отрасли, чего нет в готовых решениях.
• Интеграции: вам нужно подключить несколько внешних систем с нестандартными API.
• Монетизация: вы планируете продавать подписку и управлять тарифами — это требует собственной биллинговой логики.
• Данные: продукт работает с чувствительными данными, которые нельзя хранить на серверах no-code-платформ.

Если хотя бы два пункта совпадают — custom SaaS оправдан. Если нет — сначала проверьте гипотезу на Bubble, Webflow или Glide, и только потом идите к разработчикам.

Как упаковать MVP в 4–8 недель: стратегия выживания

MVP — это не «продукт со всеми функциями, но сделанный быстро». Это продукт с минимальным набором функций, достаточным для проверки одной ключевой гипотезы. Хороший подрядчик помогает вам безжалостно резать список требований, а не соглашается на всё подряд.

Четыре-восемь недель — реалистичный горизонт для MVP, если команда начинает с чёткого понимания User Stories, а не с размытого «хотим как Notion, но для строителей». Для этого нужно:

• Выбрать один ключевой сценарий: какое действие пользователь должен совершить, чтобы получить ценность прямо сейчас?
• Составить список «нет»: всё, что не влияет на этот сценарий, уходит в бэклог следующих спринтов.
• Зафиксировать критерии готовности: MVP считается готовым не тогда, когда команда говорит «готово», а когда реальный пользователь прошёл сценарий без помощи разработчика.

Подрядчик, который на первой встрече не задаёт вопросов о пользователях и их болях, а сразу переходит к стеку технологий — тревожный сигнал. Хорошая команда сначала разбирается в проблеме, потом предлагает решение.

Анатомия сметы: на что вы на самом деле тратите деньги

Смета на SaaS-разработку пугает не суммой, а непрозрачностью. Когда вы видите строку «Разработка бэкенда — 500 часов», вы не понимаете, что именно за эти часы будет сделано. Зрелый подрядчик раскладывает смету по модулям и User Stories, а не по ролям.

Из чего складывается стоимость custom SaaS

• Discovery и проектирование: анализ требований, архитектура, прототип. Это не «лишние расходы» — это страховка от переделок.
• Дизайн: UI-кит, экраны ключевых сценариев, адаптив. Дизайн, согласованный до разработки, экономит время на правках.
• Фронтенд и бэкенд: разделённые по модулям — авторизация, биллинг, дашборд, интеграции.
• QA: тестирование каждого модуля, а не финальная проверка «на глаз».
• DevOps: настройка инфраструктуры, CI/CD, мониторинг. Без этого продукт не доедет до пользователей.
• Поддержка после запуска: первые недели после релиза — самые уязвимые, команда должна быть на связи.

Если подрядчик даёт смету без разбивки по модулям и без объяснения, что входит в каждую строку — попросите детализацию. Если отказывает, это уже ответ на вопрос о зрелости команды.

Артефакты, без которых нельзя начинать разработку

Разработка без артефактов — это строительство дома без чертежей. Команда строит то, что поняла на созвоне, а не то, что вы имели в виду. Результат — бесконечные правки и раздутый бюджет.

До написания первой строки кода у вас должны быть согласованы:

• User Stories: «Как [роль], я хочу [действие], чтобы [результат]» — для каждого ключевого сценария MVP.
• Прототип или wireframes: интерактивный или статичный, но достаточно детальный, чтобы разработчик понял логику переходов.
• Архитектурная схема: как устроена база данных, какие сервисы взаимодействуют, где хранятся данные.
• Дизайн ключевых экранов: не обязательно все экраны, но главный сценарий должен быть отрисован.
• Критерии приёмки: для каждой User Story — конкретные условия, при которых задача считается выполненной.

Этап, на котором создаются эти артефакты, называется Discovery. Хороший подрядчик выделяет его в отдельный оплачиваемый этап — и это правильно. Discovery стоит денег, но экономит их в разы на этапе разработки.

Типичные ловушки: почему проекты раздуваются до бесконечности

Scope creep — расползание объёма — главный убийца SaaS-проектов. Он начинается незаметно: «давайте добавим ещё одну роль», «а можно сделать экспорт в Excel», «клиент попросил уведомления по SMS». Каждое такое решение кажется маленьким, но в сумме они удваивают сроки и бюджет.

Как не попасть в ловушку расползания объёма

• Зафиксируйте скоуп письменно до старта разработки и договоритесь, что любое изменение проходит через формальный процесс оценки.
• Назначьте владельца продукта со своей стороны — человека, который принимает решения о приоритетах и говорит «нет» новым хотелкам в рамках текущего этапа.
• Работайте спринтами с фиксированным содержанием: то, что не вошло в спринт, идёт в следующий, а не добавляется в текущий.
• Оценивайте каждое изменение в часах и деньгах до того, как одобрить его.

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

Красные флаги при выборе подрядчика

• Смета выдана за 24 часа без уточняющих вопросов.
• Команда не может показать реальные кейсы с описанием задачи и результата.
• Нет отдельного этапа Discovery — сразу предлагают «начать кодить».
• Договор не содержит пункта о передаче прав на исходный код.
• Нет выделенного менеджера проекта — «будем общаться напрямую с разработчиком».

Приёмка проекта: как забрать работающий продукт, а не набор багов

Приёмка — это не момент, когда подрядчик говорит «готово» и отправляет ссылку. Это процесс, который начинается с первого спринта и заканчивается тем, что вы лично проверили каждый сценарий по заранее согласованным критериям.

Чеклист приёмки MVP

• Функциональное тестирование: каждая User Story проверена по критериям приёмки, дефекты зафиксированы и исправлены.
• Доступы: вы получили доступ к репозиторию с исходным кодом, к серверной инфраструктуре, к панели управления доменом и SSL.
• Документация: есть описание архитектуры, инструкция по развёртыванию и описание API — достаточное, чтобы другая команда могла продолжить разработку.
• Нагрузочное тестирование: продукт проверен на ожидаемое количество одновременных пользователей.
• Мониторинг: настроены алерты на ошибки и падение сервисов.

Всё перечисленное выше — ваша собственность. Права на интеллектуальную собственность, исходный код и инфраструктуру должны быть прописаны в договоре явно. Если подрядчик уклоняется от этого пункта — это не партнёр, это риск.

Частые вопросы

Что лучше: фиксированная цена или Time & Material?

Для MVP в SaaS лучше подходит Time & Material, так как требования к продукту неизбежно меняются в процессе разработки. Фиксированная цена работает только тогда, когда скоуп детально описан и заморожен — что для первого MVP практически невозможно.

Кто должен писать ТЗ?

ТЗ — это результат совместной работы. Вы приносите знание о бизнесе и пользователях, подрядчик переводит это на язык технических требований. Если подрядчик просит вас написать ТЗ самостоятельно и потом «просто реализовать» — он снимает с себя ответственность за результат.

Что будет с кодом после завершения разработки?

Весь исходный код, инфраструктура и права на интеллектуальную собственность переходят заказчику. Это должно быть прописано в договоре до старта работ — не «по умолчанию», а явным пунктом.

Когда звать команду разработки?

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

Заключение

Выбор подрядчика на custom SaaS — это не тендер на минимальную цену. Это поиск команды, которая поможет вам сфокусироваться на бизнес-ценности и не даст утонуть в бесконечном списке фич. Признаки зрелого партнёра просты: выделенный Discovery-этап, прозрачная смета по модулям, артефакты до старта разработки и чёткий договор о передаче прав. Если хотя бы одного из этих пунктов нет — ищите дальше.

Команда LEGKO строит custom SaaS и MVP с выделенным этапом проектирования, прозрачной сметой и передачей всех прав заказчику. Если у вас есть гипотеза и вы хотите разобраться, как её упаковать в рабочий продукт — изучите другие материалы базы знаний или напишите нам напрямую, чтобы обсудить ваш проект.