18 авг. 2025 г.·8 мин
Дэвид Сакс об ИИ + SaaS: новый плейбук для стартапов
Практическое разложение плейбука AI + SaaS, часто ассоциируемого с Дэвидом Саксом: что меняется, что остаётся и как строить устойчивый бизнес.
Практическое разложение плейбука AI + SaaS, часто ассоциируемого с Дэвидом Саксом: что меняется, что остаётся и как строить устойчивый бизнес.
ИИ — это не просто ещё одна фича, которую добавляют в подписное приложение. Для основателей он меняет представление о «хорошей» продуктовой идее, скорость, с которой конкуренты могут вас скопировать, то, за что клиенты готовы платить, и работает ли ваша бизнес‑модель, когда в счёте появляются расходы на inference.
Этот пост — практическая синтеза часто обсуждаемых тем, связанных с Дэвидом Саксом и более широкой беседой про ИИ + SaaS — это не дословный разбор или биография. Цель — перевести повторяющиеся идеи в решения, которые вы реально можете принять как основатель или продуктовый лидер.
Классическая SaaS‑стратегия вознаграждала постепенные улучшения: выберите категорию, постройте более чистый рабочий процесс, продавайте места и полагайтесь на издержки переключения со временем. ИИ смещает центр тяжести в сторону результатов и автоматизации. Клиенты всё чаще спрашивают: «Можете ли вы сделать работу за меня?», а не «Можете ли вы помочь мне лучше управлять работой?».
Это меняет стартовую линию стартапа. Понадобится меньше UI, меньше интеграций и меньшая начальная команда — но потребуется более чёткое доказательство того, что система точна, безопасна и стоит использовать каждый день.
Если вы оцениваете идею или пытаетесь перепозиционировать существующий SaaS‑продукт, это руководство поможет вам выбрать:
Держите в голове четыре вопроса: Какую задачу выполнит ИИ? Кто ощущает боль настолько, чтобы оплатить? Как ценообразование будет отражать измеримую ценность? Что делает ваше преимущество долговечным, когда другие получают доступ к схожим моделям?
Остальная часть статьи строит современный «плейбук стартапа» вокруг этих ответов.
Классический SaaS работал, превращая софт в предсказуемую бизнес‑модель. Вы продавали подписку, расширяли использование со временем и полагались на закрепление в рабочих процессах: когда команда выстраивает привычки, шаблоны и процессы в вашем продукте, уходать становится трудно.
Это закрепление часто подтверждалось очевидной ROI. Пич был прост: «Платите X в месяц, экономьте Y часов, снижайте ошибки, закрывайте больше сделок». Если вы это стабильно давали, получали пролонгации — и пролонгации создавали компаунд‑рост.
ИИ ускоряет конкуренцию. Фичи, которые раньше делали кварталами, теперь копируются за недели, иногда просто подключением к тем же провайдерам моделей. Это сжимает «фичевоe рво» многих SaaS‑компаний.
AI‑native конкуренты стартуют с другой точки: они не просто добавляют фичу в существующий поток — они пытаются заменить сам рабочий процесс. Пользователи привыкают к копилотам, агентам и интерфейсам «просто скажи, чего хочешь», что сдвигает ожидания от кликов и форм к результатам.
Так как ИИ в демо выглядит магически, планка дифференциации быстро растёт. Если все умеют генерировать сводки, черновики или отчёты, реальный вопрос становится: почему клиент должен доверить вашему продукту делать это внутри своего бизнеса?
Несмотря на технологический сдвиг, фундамент остаётся: реальная боль клиента, конкретный покупатель, готовность платить и удержание, основанное на постоянной ценности.
Полезная иерархия для фокуса:
Результат (value) > фичи (чек‑листы).
Вместо того, чтобы отправлять AI‑чек‑лист («мы добавили авто‑заметки, авто‑письма, авто‑тэги»), лидируйте результатом, который клиенты узнают («сократить время закрытия на 20%», «уменьшить бэклог поддержки вдвое», «формировать соответствующие отчёты за минуты»). Фичи — это подтверждения, а не стратегия.
ИИ упрощает копирование поверхностного слоя, поэтому вы должны владеть более глубинным результатом.
Многие AI + SaaS стартапы застревают, потому что начинают с «ИИ» и только потом ищут задачу. Лучше выбрать клин — узкую точку входа, которая соответствует срочности клиента и вашему доступу к нужным данным.
1) AI‑фича (внутри существующей категории продукта). Вы добавляете одну AI‑возможность в знакомый рабочий процесс (например, «сворачивать тикеты», «готовить follow‑up», «авто‑тэгать счета»). Это может быть самый быстрый путь к ранней выручке, потому что покупатели уже понимают категорию.
2) Копилот (человек в цикле). Продукт сидит рядом с пользователем и ускоряет повторяющуюся задачу: подготовка, триаж, исследование, ревью. Копилоты хороши, когда качество важно и пользователь требует контроля, но нужно доказать ежедневную ценность — не только красивое демо.
3) AI‑первичный продукт (рабочий процесс перестроен вокруг автоматизации). Здесь продукт не «софт + ИИ», а автоматизированный процесс с ясными входами и выходами (часто агентный). Это может быть наиболее дифференцированным, но требует глубокой доменной ясности, строгих ограждений и надёжных потоков данных.
Пользуйтесь двумя фильтрами:
Если срочность высока, но доступ к данным слаб, начните как копилот. Если данных много и рабочий процесс хорошо определён — рассмотрите AI‑первичный.
Если ваш продукт — тонкий интерфейс поверх товарной модели, клиенты могут переключиться, как только большой вендор что‑то подобное запустит в комплекте. Антидот — не паника, а владение рабочим процессом и доказательство измеримых результатов.
Когда многие продукты могут подключаться к схожим моделям, преимущество часто смещается от «лучшего ИИ» к «лучшей досягаемости». Если пользователи никогда не сталкиваются с вашим продуктом в повседневной работе, качество модели не имеет значения — вы не получите достаточного использования, чтобы пройти к product‑market fit.
Практическая цель позиционирования — стать дефолтным способом выполнения задачи внутри инструментов, которыми люди уже пользуются. Вместо просьбы принять «ещё одно приложение» вы появляетесь там, где уже идёт работа — почта, документы, тикеты, CRM, Slack/Teams, хранилища данных.
Это важно потому что:
Интеграции & маркетплейсы: постройте минимально полезную интеграцию и опубликуйте её в релевантном маркетплейсе (например, CRM, support desk, чат). Маркетплейсы дают discovery с высоким намерением, а интеграции снижают трение при установке.
Outbound: нацеливайтесь на узкую роль с болезненным, частым рабочим процессом. Лидируйте конкретным результатом («сократить triage на 40%») и быстрым шагом доказательства (настройка за 15 минут, а не пилот на недели).
Контент: публикуйте руководства «как мы делаем X», разборы и шаблоны, которые соответствуют работе вашего покупателя. Контент особенно эффективен, когда он включает артефакты, которые люди могут скопировать (промпты, чек‑листы, SOP).
Партнёрства: объединяйтесь с агентствами, консультантами или смежным софтом, который уже обладает вашей аудиторией. Предлагайте совместный маркетинг и реферальную маржу.
ИИ меняет ценообразование, потому что стоимость и ценность не привязаны однозначно к «сидению». Пользователь может нажать одну кнопку, которая запускает дорогостоящий рабочий процесс, или проводить весь день в продукте, выполняя дешёвые задачи. Это толкает многие команды от планов по местам к ценообразованию по результатам, использованию или кредитам.
Цель — согласовать цену с доставленной ценностью и стоимостью обслуживания. Если ваш счёт API растёт с токенов, изображений или вызовов инструментов, ваши планы должны иметь чёткие лимиты, чтобы тяжёлое использование не свело маржу в минус.
Starter (индивидуальный / небольшой): базовые функции, небольшой ежемесячный пакет кредитов, стандартное качество модели, поддержка через сообщество или e‑mail.
Team: общая рабочая область, больше кредитов, коллаборация, интеграции (Slack/Google Drive), админ‑контролы, отчётность по использованию.
Business: SSO/SAML, журналы аудита, ролевой доступ, большие лимиты или кастомные пуллы кредитов, приоритетная поддержка, инвойсинг, удобный для закупок.
Обратите внимание, что масштабируются лимиты, контролы и надёжность — не только «ещё фичи». Если вы всё же оставляете плейсы, подумайте о гибриде: базовая плата платформы + плейсы + включённые кредиты.
«Free forever» звучит дружелюбно, но приучает клиентов относиться к продукту как к игрушке и быстро сжигает деньги.
Также избегайте неясных лимитов («неограниченный ИИ») и сюрпризных счетов. Покажите счётчик использования в продукте, отправляйте предупреждения (80/100%) и делайте оверейджи явными.
Если ценообразование кажется запутанным, скорее всего так и есть — сузьте единицу, покажите счётчик и упростите первый план покупки.
AI‑продукты часто выглядят «магическими» в демо, потому что промпт подобран, данные чистые, и человек управляет выводом. Ежедневное использование грязнее: реальные данные имеют пограничные случаи, рабочие процессы имеют исключения, и людей судят по моменту, когда система уверенно ошибается.
Доверие — скрытая фича, которая двигает удержание. Если пользователи не доверяют результатам, они тихо перестают пользоваться продуктом, даже если были впечатлены в первый день.
Onboarding должен уменьшать неопределённость, а не только объяснять кнопки. Покажите, в чём продукт хорош, в чём нет, и какие входы важны.
Первая ценность наступает, когда пользователь получает конкретный результат быстро (черновик, который можно использовать; тикет, решённый быстрее; отчёт, созданный). Сделайте этот момент явным: выделите, что изменилось и сколько времени сэкономлено.
Привычка формируется, когда продукт вписывается в повторяющийся рабочий процесс. Сделайте лёгкие триггеры: интеграции, плановые прогонки, шаблоны или «продолжить с того, где остановился».\n Пролонгация — это аудит доверия. Покупатели спрашивают: «Это стабильно работало? Снизило ли риск? Стало ли частью работы команды?» Продукт должен отвечать этими данными — использованием и ясной ROI.
Хороший AI‑UX делает неопределённость видимой и облегчает восстановление:\n\n- Ограждения: ограничения по источникам, безопасные режимы, проверки политик\n- Индикаторы уверенности: показывайте, когда система догадалась, и почему (цитаты, ссылки на источники, свежесть данных, покрытие)\n- Лёгкий откат: откат в один клик, история версий, «восстановить предыдущее состояние»\n- Человек в цикле: утверждения для чувствительных шагов (отправка писем, обновление записей, возвраты) и пути эскалации, когда ИИ не уверен
SMB терпит случайные ошибки, если продукт быстрый, доступный и явно повышает throughput — особенно когда ошибки легко заметить и отменить.
Enterprise ожидает предсказуемого поведения, аудируемости и контролей. Им нужны права доступа, логи, гарантии по обработке данных и понятные режимы отказа. Для них «в основном правильно» мало; надёжность — часть решения о покупке, а не бонус.
Моат — это простая причина, по которой клиент не может легко перейти к копии в следующем месяце. В AI + SaaS «наша модель умнее» редко держится — модели быстро меняются, конкуренты могут взять те же возможности.
Сильные преимущества чаще находятся вокруг ИИ, а не внутри него:\n\n- Запатентованный рабочий процесс: вы владеете уникальным способом выполнения работы — экраны, утверждения, передачи задач и пограничные случаи — замена потребует обучения людей и переписывания процессов\n- Дистрибуция: у вас уже есть внимание (аудитория, партнёр, листинг), поэтому вы получаете клиентов дешевле и быстрее\n- Бренд и доверие: особенно в регулируемой или чувствительной работе команды остаются с инструментами, которые кажутся безопасными и предсказуемыми\n- Права на данные (не просто «данные»): защищаемость приходит от разрешений использовать данные, чётких контрактов и настроек, управляемых клиентом — а не от расплывчатых заявлений о «владении данными»\n- Интеграции: глубокие связи с системами учёта (CRM, тикеты, ERP, identity) создают трения при переключении и делают ваш продукт дефолтом
Многие команды преувеличивают «мы обучаем на данных клиентов». Это может отразиться. Покупатели всё чаще хотят обратного: контроль, аудируемость и опцию держать данные изолированными.
Лучше позиционирование: явные разрешения, чёткие правила хранения и настраиваемое обучение (включая «без обучения»). Защищаемость может прийти от того, что вы — вендор, которого юридические и security‑команды одобряют быстро.
Вам не нужны секретные датасеты, чтобы быть трудозаменимым:\n\n- Система утверждений и исключений, которая повторяет реальную работу команды (кто может переопределить, когда эскалировать, как документировать)\n- Библиотека переиспользуемых плейбуков (шаблоны, политики, чек‑листы), зашитая в UI\n- Человек в цикле и контролы (пороги уверенности, очереди ревью, откат), делающие ИИ безопасным в продакшене\n- Интеграции‑обеспечивающий контекст (доступ к CRM/тикетам/документам с учётом прав) — чтобы ответы опирались на системы клиента
Если ваш ИИ‑вывод — демо, то ваш рабочий процесс — это моат.
Традиционная SaaS‑юнит‑экономика предполагает дешёвое обслуживание: после постройки продукта каждый дополнительный пользователь почти не двигает затрат. ИИ меняет это. Если ваш продукт запускает inference на каждый рабочий процесс — суммарные COGS растут с использованием. Это значит, что «отличный рост» может тихо сжимать валовую маржу.
С AI‑фичами переменные затраты (inference, вызовы инструментов, retrieval, GPU‑время) могут расти линейно или даже быстрее с активностью клиента. Клиент, который любит продукт, может быть и самым дорогим клиентом.
Поэтому валовая маржа — не просто финансовая строка; это ограничение дизайна продукта.
Отслеживайте юнит‑экономику на уровне клиента и действия:\n\n- CAC и срок окупаемости CAC\n- удержание (logo и net revenue) и расширение vs. сокращение\n- COGS на пользователя / на рабочую область (и на ключевое действие)\n- кривые использования: действия на пользователя со временем, пик vs steady‑state\n- валовая маржа по когортам (тяжёлые vs лёгкие пользователи)
Практичные рычаги, которые обычно важны сразу:\n\n- кэширование и дедупинг (не пересуммируйте одно и то же)\n- выбор модели под задачу (малые модели для классификации, большие — только для сложного reasoning)\n- жёсткие лимиты и здравые дефолты (rate limits, caps на контекст, батчи)\n- оптимизация промптов и контекста (короче входы, лучшее retrieval, меньше вызовов внешних инструментов)
Стартуйте с API, пока ищете product‑market fit: скорость важнее совершенства.
Рассмотрите дообучение или кастомные модели, когда (1) cost inference — ключевой драйвер COGS, (2) у вас есть проприетарные данные и стабильные задачи, и (3) улучшение производительности прямо переводится в удержание или готовность платить. Если нельзя связать инвестицию в модель с измеримым бизнес‑результатом, продолжайте покупать и фокусируйтесь на дистрибуции и использовании.
AI‑продукты покупают не потому, что демо умное — а потому, что риск кажется управляемым, а upside ясен. Бизнес‑покупатель отвечает на три вопроса: Улучшит ли это измеримый показатель? Впишется ли это в нашу среду? Доверим ли мы этому наши данные?
Даже средние компании теперь ищут базовый набор «enterprise‑ready» сигналов:\n\n- Базовая безопасность: SSO/SAML, ролевой доступ, шифрование в транзите/в покое\n- Админ‑контроли: provision пользователей, рабочие области, лимиты/защиты по использованию\n- Аудируемость: журналы аудита, история/версия, трассируемость действий, сгенерированных ИИ\n- Ясность по работе с данными: что хранится, что отправляется провайдерам моделей, опции хранения и используется ли что‑то для обучения
Если у вас это документировано, ссылайтесь на /security в начале цикла продаж. Это сокращает коммуникацию и повышает доверие.
Разные заинтересованные стороны покупают по разным причинам:\n\n- Руководители (CFO/COO/VP): лидируйте результатами — сэкономленные часы, сокращение времени цикла, меньше ошибок, быстрее сбор выручки, выше конверсия. Держите историю простой: до/после и правдоподобная модель ROI.\n- Лидеры команд и конечные пользователи: лидируйте удобством — как это вписывается в их поток, что заменяет и чего не делает. Покажите «день 1» ценность (шаблоны, интеграции, дефолты) и «день 30» (автоматизация, сводки, follow‑up).
Используйте доказательства, соответствующие уровню риска покупателя: короткий платный пилот, референс‑звонок, лёгкий кейс с метриками и чёткий план развёртывания.
Цель — сделать «да» безопасным и ценность — неизбежной.
ИИ меняет смысл «легкости». Небольшая команда может выпустить опыт, похожий на гораздо более крупный продукт, потому что автоматизация, лучшие инструменты и model APIs сжимают работу. Ограничение смещается с «можем ли мы это построить?» на «можем ли мы быстро решать, быстро учиться и получать доверие?»
Ранние фазы: команда из 3–6 человек часто выигрывает у 15–20‑членной команды, потому что издержки координации растут быстрее, чем выход. Меньше handoff’ов — быстрее циклы: звонки с клиентами утром, фиксы днём, проверка результатов на следующий день.
Цель — не оставаться крошечным вечно, а оставаться сфокусированным, пока клин не доказан.
Нужны не все функции, а чёткие владельцы по задачам обучения:\n\n- Product owner (часто основатель): задаёт клин, определяет job‑to‑be‑done и держит scope узким\n- Growth / distribution: владеет каналом (outbound, контент, партнёры, сообщество) и отслеживает конверсию end‑to‑end\n- Customer success (даже part‑time): превращает пилоты в привычку, документирует возражения и собирает доказательства\n- Engineering / ML: один сильный generalist и глубина по ML только если это действительно критично для качества
Если никто не отвечает за удержание и onboarding, вы будете выигрывать демо, но не ежедневное использование.
Большинство команд должны покупать или использовать managed‑сервисы для рутинных частей, чтобы инженерное время шло на продуктовую грань:\n\n- Купить: auth, billing, analytics, feature flags, CRM, базовый support tooling\n- Использовать: провайдеры моделей и инструменты оценки, пока нет явной причины не использовать их\n- Построить: рабочий процесс, петлю обратной связи по данным и UX, которые делают результаты лучше
Практическое правило: если это не будет дифференциатором через 6 месяцев — не стройте.
Одна из причин, почему AI + SaaS команды могут оставаться маленькими — построение правдоподобного MVP быстрее, чем раньше. Платформы вроде Koder.ai подкрепляют этот сдвиг: вы можете создать веб‑, бэкенд‑ и мобильные приложения через чат‑интерфейс, экспортировать код или развернуть — полезно при итерации клина и быстрой доставке экспериментов.
Две функции особенно полезны для плейбука выше: planning mode (чтобы держать дисциплину по scope перед билдом) и snapshots/rollback (чтобы безопасно быстро итератить onboarding, ценовые ворота или изменения workflow).
Сделайте модель простой и повторяемой:\n\n- Еженедельный обзор метрик: активация, время до первой ценности, удержание, стоимость на задачу и pipeline\n- 5–10 разговоров с клиентами в неделю: записывайте, суммируйте и кладите в бэклог\n- Ритм релизов: маленькие релизы 2–3 раза в неделю; одна большая ставка каждые 2–3 недели
Этот ритм заставляет ясно отвечать: что мы узнаём, что меняем и двигают ли изменения показатели?
Этот раздел переводит сдвиг «ИИ + SaaS» в действия, которые вы можете запустить на этой неделе. Скопируйте чек‑лист и используйте дерево решений, чтобы стресс‑тестировать план.
Короткое «если/то» руководство:\n\n1) Выберите клин\n- Если клин требует изменения ядра систем → сузьте (начните как add‑on)\n- Если можно дать ценность внутри существующего рабочего процесса → делайте это первым\n\n2) Проверьте покупателя\n- Если пользователи в восторге, но никто не держит бюджет → переформулируйте для владельца бюджета\n- Если покупатель требует доказательств → проведите 2‑недельный пилот с конкретной метрикой\n\n3) Установите цену\n- Если затраты растут с использованием → избегайте unlimited; добавьте tiers/лимиты\n- Если ценность масштабируется с результатами → думайте о pricing, основанном на результатах или workflow\n\n4) Выберите дистрибуцию\n- Если проблема срочная и специфичная → outbound\n- Если многие её ищут → контент/SEO\n- Если это живёт внутри платформы → маркетплейс + интеграции\n\n5) Закрепите удержание\n- Если есть «wow» в демо, но недельное отваливание → поправьте onboarding + привычные триггеры\n- Если проблемы доверия блокируют развёртывание → добавьте контролы, видимость и governance
Посмотрите другие плейбуки и фреймворки на /blog. Если хотите глубже по этой теме, см. /blog/david-sacks-on-ai-saas-a-new-startup-playbook.
“ИИ + SaaS” означает, что ценность продукта всё чаще измеряется через завершённые результаты, а не просто через улучшенный интерфейс для ведения работы. Вместо помощи в учёте задач от продукта ждут, что он будет выполнять части работы (подготовка черновиков, маршрутизация, решение запросов, ревью) при условии безопасности, точности и экономичности в масштабе.
ИИ сокращает время, за которое конкуренты копируют фичи, особенно когда все используют одни и те же фундаментальные модели. Это смещает стратегию от «отличия фич» к:
Выбирайте по тому, сколько автоматизации вы можете безопасно доставить сегодня:
Используйте два фильтра:
Если неотложность высокая, но данных мало — начните как . Если данные обильны и процесс хорошо определён — рассматривайте . Если нужно быстро получить выручку — в существующем рабочем процессе может быть хорошим входом.
«Риск обёртки» — это когда продукт по сути тонкий UI поверх товарной модели, поэтому клиент может переключиться, как только крупный вендор что‑то подобное пустит в комплекте. Уменьшите риск, если:
Ставьте целью быть дефолтным способом выполнения задачи там, где люди уже работают, а не «ещё одно приложение». Ранние каналы, которые обычно работают:
Практическая последовательность:
Ценообразование по местам часто не работает, потому что ценность и затраты масштабируются с использованием, а не с логинами. Опции:
Избегайте «неограниченного ИИ», показывайте в продукте счётчик использования, отправляйте предупреждения и делайте оверейджи явными, чтобы не получить сюрпризные счёта и отрицательную маржу.
ИИ вводит реальные переменные COGS (токены, вызовы инструментов, время на GPU), поэтому рост может незаметно съесть маржу. Слежение:
Рычаги для контроля затрат:
Ретеншен зависит от доверия продукта в реальных, грязных рабочих процессах. Полезные паттерны:
Для бизнес‑покупателей сделайте «да» безопасным через понятную политику работы с данными, админ‑контролями и аудируемость — начните с публичной страницы /security и простых метрик пилота.