Кейс

От идеи до первых платящих пользователей: как мы запустили B2B-SaaS

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

Have a nice dayHave a nice day12 мин чтения
От идеи до первых платящих пользователей: как мы запустили B2B-SaaS

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

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

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

Ситуация: таблица, делающая реальную работу

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

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

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

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

Первой задачей было решить, что НЕ строить

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

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

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

Доска, покрытая стикерами, где рука перемещает большинство стикеров в колонку 'позже', оставляя лишь четыре в колонке 'запуск', снято в тёплом офисном свете
Определить объём запуска — это в основном акт вычитания. Четыре оставшихся стикера и стали продуктом.

Что мы на самом деле построили за одиннадцать недель

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

Недели 1–3: хребет

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

Недели 4–7: собственно работа

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

Недели 8–11: сделать безопасным для оплаты

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

Вопрос 'добавьте сюда немного ИИ', честный ответ

В её списке желаний был ИИ, как почти во всех списках сейчас. Мы возразили, и стоит объяснить почему, ведь это тот же совет, который мы даём почти всем. Задача, которую должна была выполнять первая версия — проверка известного набора документов по известному набору правил — это задача, которую правила делают лучше ИИ. Она предсказуема, она проверяема, и когда регулируемый клиент спрашивает "почему система это пометила", вы хотите ясного ответа, а не пожатия плечами.

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

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

Как получить первых платящих пользователей

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

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

  1. 1
    Начните с тех, кто уже просит
    Её первое обращение пошло только к клиентам, которые ранее предлагали заплатить. Тёплый спрос конвертируется ещё до того, как холодный вообще ответит.
  2. 2
    Подключите первых вручную
    Никакого самообслуживания-геройства на старте. Она провела каждого раннего пользователя вживую, превращая каждую точку замешательства в конкретную правку.
  3. 3
    Цена для основателей, не навсегда
    Ранние пользователи получили явно ограниченную по времени ставку основателя. Это вознаграждало их риск и давало поздним клиентам причину, почему цены растут.
  4. 4
    Используйте дедлайн как запуск
    Конференция была не маркетинговым трюком, прикрученным потом — это был принуждающий фактор, державший объём честным на всём пути.

Результат — и что он действительно значит

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

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

ПоказательИтогПочему это было важно
Время до первого платящего пользователя~11 недельТугой объём держал темп и боевой дух высокими
Функций при запуске4 основные функцииКаждая прошла тест 'откажутся ли платить'
Первые клиентыГорстка тёплых лидовВсе из её существующей доверяющей аудитории
ИИ в первой версииНетПравила сделали основную работу; ИИ ушёл в v2
Ежедневное время основательницыМинимальноеПродукт спроектирован так, чтобы быть скучным в эксплуатации
Иллюстративный снимок запуска — цифры округлены и смягчены ради анонимности.
От нуля до нескольких платящих клиентов — самый трудный скачок в ПО. Всё после него — другой, более лёгкий вид трудности.
веха, которая действительно считается

Где мы ошиблись

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

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

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

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

Если вы стоите там, где стояла она

То, что заставило это работать, было не хитрой архитектурой и не модным инструментом. Это была дисциплина в объёме и честность в спросе. У неё было доказательство, что люди этого хотят, ещё до того, как мы написали строчку кода, и мы были безжалостны в построении самой маленькой версии, за которую кто-то всё равно заплатит. Ни то ни другое не требует технического бэкграунда. Оба можно начать уже на этой неделе, самостоятельно.

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

Есть таблица, которая хочет стать ПО?

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

Посмотрите, как мы создаём ПО на заказ

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

Сколько на самом деле занимает запуск B2B-SaaS?
Если объём тугой, а спрос уже доказан, первая платная версия реалистична примерно за два-три месяца. Срок раздувается, когда основатели пытаются запустить полнофункциональный продукт вместо самой маленькой версии, за которую кто-то заплатит. Одиннадцать недель в этом кейсе были возможны лишь потому, что мы сократили двухстраничный список желаний до четырёх основных функций.
Нужно ли уметь программировать, чтобы создать SaaS?
Нет. У основательницы в этом кейсе вообще не было технического бэкграунда. Что действительно нужно — глубокое знание проблемы и честность в том, действительно ли люди хотят решения. Построение — наша задача; доменная экспертиза и отношения с клиентами — ваши, и это более трудная половина.
Должна ли моя первая версия включать ИИ?
Обычно нет. Большинство основных B2B-процессов основаны на правилах — предсказуемы, проверяемы и лучше обслуживаются обычной автоматизацией. ИИ заслуживает место там, где работа хаотична и языкова, как интерпретация документов, приходящих в неверном формате. Мы оставили ИИ здесь на вторую версию, и продукт всё равно зарабатывал без него.
Как получить самых первых платящих клиентов?
Начните с тёплого спроса — людей, которые уже вам доверяют и проявили интерес, не холодного открытого интернета. Подключите первых вручную, понаблюдайте, как они пользуются, и исправьте каждое замешательство, что увидите. Малая группа платящих основателей на старте куда ценнее большой волны любопытных незнакомцев, которые так и не конвертируются.
Какая самая частая ошибка на этом этапе?
Их, на самом деле, две. Недоинвестирование в первые пять минут, что новый пользователь проводит в продукте — онбординг решает, доверятся ли незнакомцы. И недооценка скрытой ручной работы, которую таблица тихо делает и воспроизведение которой в ПО всегда стоит больше, чем кто-либо ожидает. Заложите время на оба с самого начала.
Have a nice day
Have a nice day
Редакция

Have a nice day — это софтверная студия, которая помогает малому и среднему бизнесу перейти в цифру: автоматизация, ИИ и софт под заказ, который работает в повседневных процессах, а не только на слайдах.

Подходящие услуги