Сочи · работаем по РФ и СНГ Пн–Пт 10–19 · Сб 11–16 (МСК)
Текст этой страницы без разметки — markdown-версия. Полный список страниц сайта — llms.txt, тексты всех страниц целиком — llms-full.txt.
Формат направления · продукт по подписке от 200 000 ₽ платформа от 900 000 ₽

SaaS: половина работы здесь — про деньги во времени

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

  • Тариф и лимит проектируются вместе с моделью данных, а не после неё
  • Чужие компании внутри одной системы: разделение данных — отдельная работа
  • Что происходит после неоплаты, написано до запуска, а не решается в тот день
от 200 000 ₽ эквайринг на ваше юрлицо 9 лет в разработке
300+проектов за 9 лет
9лет в разработке
от 200 000 ₽проверяемая первая версия подписного продукта
от 900 000 ₽платформа: когда сервис и есть бизнес
7 решений о подписке, которые принимают до кода Перейти к проверке готовности к подписке
Разбираемся

Подписка — это устройство продукта, а не способ оплаты

Самая дорогая ошибка в таком проекте — отложить разговор о деньгах на конец разработки. К этому моменту модель данных уже написана, и она почти наверняка не умеет того, что нужно тарифу.

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

В подписном продукте два разных «кто». Есть компания-клиент — она платит, у неё тариф и лимиты. И есть сотрудники этой компании — они работают, у них роли и права внутри. Путаница между ними даёт самые неприятные ошибки: сотрудник видит платёжные данные компании, или наоборот — администратор не может отключить уволившегося. Разделение проектируется в первый день и стоит немного; починка после запуска стоит дорого, потому что затрагивает каждую проверку в системе.

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

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

Чего мы не называем: конверсию из пробного в платный, долю отказов и другие рыночные доли. У нас нет своей измеренной статистики по подписным продуктам, а чужую пересказывать как свою мы не станем. На разборе считаем на ваших числах, если они есть.

Три способа брать деньги за доступ

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

Что сравниваемПо рабочим местамПо объёмуПо набору функций
За что платят За каждого сотрудника, который работает в системе За сделки, документы, отправки, хранение — то, что считается само За доступ к части возможностей продукта
Что должен уметь продукт Знать число активных сотрудников и не пускать сверх лимита Считать в момент действия, а не в конце месяца, и предупреждать заранее Каждой функции отвечать, доступна ли она этой компании
Где обычно ломается Сотрудника «уволили», но не отключили — и место занято Лимит кончился посреди рабочего дня, и работа встала без предупреждения Проверки доступа расползаются по коду, и где-то одной не оказывается
Кому подходит Продуктам, где ценность растёт от числа людей в команде Продуктам, где выгода клиента прямо связана с оборотом Продуктам с широким охватом задач и очень разными клиентами
Цена решения Самый предсказуемый вариант в разработке Дороже: считать надо точно, а спорить о цифрах будут Дороже всех в сопровождении: каждая новая функция — новое решение о тарифе

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

Шесть частей, которые есть только у подписки

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

Тарифы и лимиты

Не прайс на сайте, а механизм внутри: что считаем, когда предупреждаем о приближении к границе и что происходит при её достижении. Вынесено в настройки — тарифы меняются чаще кода.

Пробный период и первое списание

Как начинается, чем ограничен, что происходит в день окончания. Отдельно — переход к оплате: с картой заранее или без неё. Это решение о продукте, а не о маркетинге.

Продление и неудачный платёж

Повторные попытки, письма, режим только для чтения, отключение. Самый неприятный сценарий продукта и самый частый: карта истекает у всех рано или поздно.

Разделение данных между компаниями

Чужие организации внутри одной системы. Проверка принадлежности на каждом запросе, а не на экране. Одна пропущенная проверка здесь стоит дороже всей остальной разработки.

Администратор на стороне клиента

Сам приглашает сотрудников, раздаёт права, отключает ушедших, видит счета. Без этого экрана каждое кадровое движение у клиента превращается в письмо в вашу поддержку.

Выгрузка и удаление данных

Клиент должен уметь забрать своё и уйти. Это одновременно требование к продукту и лучший аргумент в продаже: отсутствие выхода отпугивает больше, чем цена.

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

Спросить про свою подписку

Не решили, за что брать деньги?Напишите, что у вас за продукт и кому вы его продаёте. Скажем, что разумнее ограничивать — места, объём или функции, — и что из этого потребует от модели данных больше всего. Без счёта и без созвона.

Спросить в Telegram Сначала посчитать экономику

Путь подписчика: от регистрации до продления

Пять шагов глазами вашего клиента. Обратите внимание на последние два: именно там подписные продукты теряют деньги, и зависит это не от качества продукта, а от того, что заложено в код.

  1. Завёл компанию, а не просто аккаунт

    Первый вошедший становится администратором своей организации. Это не мелочь: если регистрируется «просто человек», потом нельзя ни пригласить коллег, ни передать владение при его уходе.

    В системе: создаётся организация; пользователь связывается с ней ролью, а не наоборот

    один раз
  2. Дошёл до пользы в пробном периоде

    Не «посмотрел интерфейс», а сделал то, ради чего продукт нужен. Если до этого места человек не добрался, решение о платеже он примет по пустому экрану — и примет его не в вашу пользу.

    В системе: отмечается факт первого полезного действия; это и есть главный показатель продукта

    первые минуты
  3. Привёл коллег

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

    В системе: приглашения, роли внутри организации, отключение ушедших самим администратором

    первая неделя
  4. Упёрся в лимит

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

    В системе: счётчик считает в момент действия; уведомление уходит до достижения лимита, а не после

    через месяцы
  5. Не заметил, что платёж не прошёл

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

    В системе: повторные попытки по расписанию, письма ответственному, режим только для чтения до отключения

    каждый период

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

Семь решений, которые принимают до кода

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

Отметьте то, что уже решено

Вердикт появится после первой отметки. Ничего никуда не уходит: это список к вашей внутренней встрече, а не заявка.

Решено 0 из 7

Второй пункт стоит дороже остальных. Продукт, написанный под одного пользователя, при переходе к компаниям переделывается целиком: организация появляется в каждой таблице и в каждой проверке прав. Если корпоративные клиенты у вас предполагаются хотя бы через год, закладывать это надо сразу.

Чего подписка не чинит

Четыре ожидания, с которыми приходят чаще всего. Все четыре разумны, и ни одно не выполняется само собой от того, что продукт продаётся ежемесячно.

ОжиданиеЧто на самом делеЧто с этим делать
«Подписка даст предсказуемый доход» Предсказуем он становится, когда клиенты остаются. Пока продукт новый, отказы идут быстрее, чем приходят новые подписчики Считать экономику до разработки: сколько стоит привлечь клиента и сколько месяцев он должен остаться, чтобы это окупилось. Это отдельная работа, и делается она на бумаге
«Сделаем продукт — клиенты сами найдутся» Подписной продукт продаётся сложнее разовой услуги: человеку надо не заплатить, а согласиться платить дальше Проверять спрос до разработки, самым дешёвым способом, который даёт ответ. Как выбирается такой способ — на соседней странице
«Будем править на лету, это же облако» Править действительно можно в любой день, но в системе одновременно работают чужие компании, и каждая правка касается всех сразу Закладывать выкладку без остановки, откат и предупреждение о работах. Это часть архитектуры, а не поддержки, и стоит она дешевле всего в начале
«Данные клиентов защищены, у нас же логин и пароль» Вход отделяет людей от посторонних. Компании друг от друга отделяет проверка принадлежности на каждом запросе — и именно её забывают Проверять принадлежность в одном месте кода, а не в каждом обработчике, и отдельно тестировать попытку добраться до чужой записи по прямой ссылке

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

От чего зависит цена

Своей сметы у формата нет. Проверяемая первая версия — вход в направление, от 200 000 ₽; продукт, которым пользуются каждый день, — вторая ступень, от 450 000 ₽; платформа, где сервис и есть бизнес, — третья, от 900 000 ₽. Разброс внутри задают четыре вещи.

  1. Продаёте людям или компаниям

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

  2. Что именно считает тариф

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

  3. Насколько подробен сценарий неоплаты

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

  4. Сколько клиентов должно жить в одной системе

    Десяток компаний и тысяча компаний — это разные решения о хранении, о выгрузках и о том, что делать, когда одна из них создаёт нагрузку на всех остальных. В первой версии мы обычно не строим под тысячу: это трата денег на то, чего ещё нет. Но модель данных закладывается так, чтобы не переписывать её при росте.

Три сметы направления с составом и сроками — на странице веб-сервисов. Цену вашей подписки для клиентов мы не назначаем: это предмет юнит-экономики, а не разработки.

Эта страница — один из форматов направления

Здесь написано только про подписку и всё, что из неё следует. Три сметы, устройство кода и то, что остаётся у вас после проекта, — на странице направления.

Устройство кода, миграции, записанные решения и автоматическая выкладка — общие для направления и разобраны в блоке для технического специалиста. Для подписного продукта добавляются контейнеры и очереди: первое даёт одинаковое окружение, второе снимает долгие операции с экрана пользователя. Разработка веб-сервисов

Когда подписной продукт вам не нужен

Четыре случая. Первые два означают, что продукт нужен, а подписка — нет; третий и четвёртый — что начинать надо не с разработки.

  1. Если клиент пользуется продуктом один раз

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

  2. Если пользователи — только ваши сотрудники

    Внутренняя система не продаётся, и тариф внутри неё считать не у кого. Тогда весь описанный здесь пласт работы отпадает: нет ни пробного периода, ни неоплаты, ни разделения между компаниями. Это автоматизация или своя система под процесс, и считаются они иначе.

  3. Если экономика не сходится на бумаге

    Бывает, что продукт работает и нравится, но стоимость привлечения клиента не окупается за то время, которое он остаётся. Никакая разработка этого не исправит. Проверяется это разбором юнит-экономики — быстрее и дешевле, чем первой версией продукта.

  4. Если задачу закрывают готовые сервисы

    Свой подписной продукт — это не только разработка, но и вечное сопровождение: платежи, поддержка, обновления, чужие меняющиеся правила. Если то же самое собирается из готовых сервисов и связок между ними, мы скажем это на разборе. Такой ответ мы даём регулярно, и он означает отказ от заказа.

Куда идти, если задача звучит иначе

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

Если не считали, сойдётся ли Разбор юнит-экономики Сколько стоит привести подписчика и сколько месяцев он должен остаться, чтобы это окупилось. Считается на бумаге и отвечает на вопрос, который разработка не решает никак Если продукт нужен вам самим CRM на заказ Система под собственный процесс, без тарифов и подписчиков. Там разговор начинается со сравнения с готовой коробкой — и чаще всего ею же заканчивается Если продукт должен жить среди чужих систем Интеграции между системами Подписной продукт почти всегда обменивается данными с учётом и платёжными сервисами клиентов. Что происходит при сбое и при смене чужого интерфейса — отдельная работа со своими правилами Если пользователи не выходят из мессенджера Сервис внутри Telegram Иногда продукт для небольших команд дешевле и удобнее жить прямо в мессенджере, без отдельного входа и установки. Ограничения такого пути названы там же, на его странице

Разработка SaaS-платформы: что стоит знать до заказа

SaaS отличается от обычного веб-сервиса одним свойством: доступ продаётся по времени и продаётся заново каждый период. Из этого свойства вырастает всё остальное — тарифы и лимиты, пробный период, продление, поведение при неудачном платеже, разделение данных между чужими друг другу компаниями и возможность забрать свои данные при уходе. Ни одна из этих частей не прикручивается в конце: они пронизывают модель данных целиком.

За что берут деньги в подписном продукте

Три распространённых способа: по рабочим местам, по объёму и по набору функций. Первый самый предсказуемый в разработке — продукт должен знать число активных сотрудников компании и не пускать сверх лимита. Второй требует считать в момент действия и предупреждать о приближении к границе, иначе работа у клиента встанет посреди дня. Третий дороже всех в сопровождении: каждая новая возможность продукта превращается в новое решение о тарифах.

Способы можно смешивать, но в первой версии это редко оправданно: смешанный тариф означает несколько механизмов ограничения и несколько мест, где они могут разойтись между собой. Разумнее начать с простого и усложнять тогда, когда станет понятно, за что клиенты действительно готовы доплачивать.

Почему компания и пользователь — разные сущности

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

Что происходит, когда платёж не прошёл

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

Сколько стоит разработка SaaS

Проверяемая первая версия — вход в направление веб-сервисов, от 200 000 ₽. Продукт, которым пользуются каждый день, относится ко второй смете, от 450 000 ₽; платформа, где сервис и есть бизнес, — к третьей, от 900 000 ₽. Разброс внутри ступени задают четыре вещи: продаёте вы людям или компаниям, что именно считает тариф, насколько подробен сценарий неоплаты и сколько клиентов должно жить в одной системе.

Чего мы не называем: конверсии из пробного периода в платный, доли отказов и прочих рыночных показателей. Своих измерений по подписным продуктам у нас нет, а чужие цифры выдавать за свои мы не станем. Что считать и как — разбирается на вашем продукте, и делается это до разработки

Вопросы про подписной продукт

Шесть вопросов, которые задают именно про подписку. Про договор, этапы оплаты и гарантии — на странице оплаты и гарантий, чтобы ответы не расходились между страницами.

Начать без платежей можно и часто нужно: первая версия проверяет, нужен ли продукт вообще. Но решить, что именно будет ограничивать тариф, надо до разработки — даже если сам механизм появится позже. Причина в том, что ограничивать можно только то, что продукт считает, а счёт закладывается в модель данных. Добавить платежи к готовому продукту просто; добавить точный счёт объёма — значит переписать половину.

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

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

То, что вы решите и объявите заранее. Обычная последовательность: несколько повторных попыток списания, письма ответственному, режим только для чтения, потом закрытие доступа с сохранением данных на оговорённый срок. Выгрузка при этом должна оставаться доступной — клиент обязан уметь забрать своё. Это и требование к продукту, и сильный аргумент в продаже: отсутствие выхода отпугивает покупателей сильнее цены.

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

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

Опишите продукт — скажем, за что в нём разумно брать деньги

  • Разбор 30 минут: кому продаёте, что ограничивает тариф, что при неоплате
  • Скажем, что придётся заложить в модель данных с первого дня
  • Если задачу закрывают готовые сервисы, услышите это первым и бесплатно
Николай Старостов, основатель Starostoff
Николай Старостов Основатель. Разбор веду лично, не передаю менеджеру
Куда прислать ответ

Ответ в течение рабочего дня

Заявка принята

Вернёмся в течение рабочего дня. Если срочно — напишите в Telegram.