Разработка SaaS-продуктов

Что входит в разработку SaaS-продуктов?

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

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

Чем это отличается от индивидуального ПО?

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

Особенность модели SaaS

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

Кому это подходит?

Разработка SaaS-продуктов обычно подходит таким профилям:

• Предпринимателям, которые хорошо знают повторяющуюся проблему отрасли и хотят превратить ее в продукт.
• Компаниям, которые хотят предлагать другим фирмам метод или инструмент, используемый ими в собственном бизнесе.
• Агентствам и консалтинговым фирмам, которые хотят с помощью программного обеспечения охватить больше клиентов услугой, которую оказывают в формате консалтинга.
• Софтверным компаниям, которые хотят перенести свое устанавливаемое ПО на облачную модель подписки.

Планирование MVP: с чего начинается разработка SaaS-продуктов?

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

Процесс шаг за шагом

Проекты по разработке SaaS мы ведем в таком порядке, что результат каждого шага переходит в следующий:

1. Исследование: вместе уточняем целевого клиента, проблему, которую нужно решить, конкурентов и модель дохода.
2. Проверка гипотезы: ищем отклик на идею в разговорах с потенциальными пользователями и испытаниях прототипа.
3. Объем MVP: фиксируем письменно функции первой версии, тарифы и показатели, которые будем измерять.
4. Дизайн и прототип: испытываем регистрацию, первое использование и основные рабочие сценарии на кликабельных экранах.
5. Циклы разработки: развиваем продукт короткими циклами и в конце каждого цикла вместе просматриваем рабочую версию.
6. Закрытое тестирование: испытываем продукт в реальных условиях на ограниченном числе пользователей и собираем обратную связь.
7. Запуск: открываем продукт для всех вместе с платежной инфраструктурой и каналами поддержки.

Сначала проверить проблему

Перед тем как вкладываться в разработку SaaS, до написания кода нужно четко ответить на такие вопросы: кто целевой клиент? Как он решает эту проблему сегодня? Чем он недоволен в существующем решении? Готов ли он платить за лучшее решение? Разговоры с потенциальными клиентами, кликабельный прототип или простая страница предварительной регистрации помогут получить ответы на эти вопросы, не неся затрат на разработку.

Сузить объем первой версии

При определении объема MVP мы советуем разделить функции на три группы:

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

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

Проверять цены на раннем этапе

Хотя цена кажется решением, которое принимают после завершения продукта, она напрямую влияет на объем продукта. Какие функции войдут в какой тариф, будет ли бесплатный тариф и как определяется цена — за пользователя или по объему использования, нужно обсуждать на этапе MVP. В процессе разработки SaaS-продуктов практичный способ проверить допущения — рано опубликовать страницу с тарифами и измерить интерес.

Показатели, которые измеряются с самого начала

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

Архитектурные решения для разработки SaaS

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

Мультиарендная структура

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

Выбор технологий и план по команде

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

Безопасность и инфраструктура

Поскольку SaaS-продукт хранит данные ваших клиентов, безопасность — тоже часть процесса продаж; особенно подробные вопросы об этом задают корпоративные клиенты. Во время разработки мы используем как справочный источник список OWASP Top 10, в котором перечислены самые критичные риски безопасности веб-приложений. Шифрованное соединение, безопасное хранение паролей, возможность двухфакторной проверки, регулярное резервное копирование и журналирование критичных операций нужно предусмотреть уже в первой версии.

Готовность к росту

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

Обновления доходят до всех одновременно

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

Подписка и платежная инфраструктура

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

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

Тарифы обычно различаются по числу пользователей, объему использования или набору функций. Какая бы модель ни была выбрана, то, как лимиты будут применяться внутри продукта, нужно продумать с самого начала: что увидит пользователь, когда лимит исчерпан? Откроются ли новые функции сразу после повышения тарифа? Чтобы вы могли менять модель ценообразования без изменений в коде, мы советуем сделать данные о тарифах и лимитах редактируемыми со стороны администрирования.

Пробный период, повышение тарифа и отмена

• Пробный период: нужно ли запрашивать данные карты сразу и что произойдет по окончании срока.
• Смена тарифа: как считается остаток срока при повышении или понижении тарифа в середине периода.
• Отмена: закончится ли подписка сразу или в конце периода и как долго будут храниться данные.
• Годовая оплата: правила перехода между месячными и годовыми тарифами.
• Купоны и акции: на какие тарифы и на сколько периодов действуют скидки.

Неудачные платежи

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

Платежная организация и счета

Работа с платежной организацией, которая поддерживает повторяющиеся платежи и хранение карты (токенизацию), позволяет управлять подпиской, не храня данные карты на ваших серверах. Если вы продаете в Турции, после каждого успешного списания в процесс должно входить и выставление счета; если используются e-Fatura (электронная счет-фактура) или e-Arşiv (электронный архив счетов), этот шаг можно автоматизировать подключением через интегратора. Если вы планируете продавать за рубеж, отдельно нужно оценить валюту, налоги и местные способы оплаты.

Управление пользователями и первый опыт

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

Командные аккаунты и роли

• Приглашения: владелец аккаунта приглашает коллег в продукт по email.
• Роли: разделение прав по ролям вроде владельца аккаунта, администратора и обычного пользователя.
• Удаление пользователя: доступ уволившегося сотрудника можно закрыть сразу же.
• Корпоративный вход: для крупных клиентов возможность единого входа через аккаунты Google или Microsoft.

Первый опыт использования

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

Бэк-офис продукта

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

Данные, конфиденциальность и KVKK

Компании, которые пользуются вашим SaaS-продуктом, загружают в вашу систему данные своих клиентов. В таком случае с точки зрения закона Турции № 6698 о защите персональных данных (KVKK) нужно правильно определить роли оператора данных и обработчика данных, а договор и тексты уведомлений подготовить соответственно. Возможность для клиента экспортировать свои данные и удалить их при закрытии аккаунта тоже нужно предусмотреть как функцию продукта. Окончательную проверку договора и текстов о конфиденциальности разумно поручить юристу.

Запуск и после него: разработка SaaS-продуктов — постоянная работа

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

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

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

Поддержка клиентов и справочные материалы

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

Чек-лист подготовки к запуску

• Опубликованы ли условия использования, политика конфиденциальности и тексты по KVKK?
• Правильно ли отправляются письма о регистрации, сбросе пароля и подписке?
• Проверены ли сценарии неудачных платежей и отмены?
• Делаются ли резервные копии и пробовали ли восстановление?
• Работают ли отслеживание ошибок и измерение использования?
• Каким каналом и до кого будут доходить обращения в поддержку?

Что определяет объем работ

• Число и сложность основных функций в MVP.
• Модель подписки: число тарифов, ценообразование по использованию, правила пробного периода и купонов.
• Изоляция арендаторов и ожидания корпоративных клиентов по безопасности.
• Потребность в готовых интеграциях с бухгалтерскими системами, CRM, платежными или email-сервисами.
• Поддержка нескольких языков и нескольких валют.
• Объем экранов отчетов для клиентов и бэк-офиса.

Частые ошибки

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

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

Нужен ли мне технический сооснователь для разработки SaaS-продукта?

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

Чем MVP отличается от полного продукта?

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

Можно ли принимать платежи по подписке в Турции?

Можно. С платежной организацией, которая поддерживает повторяющиеся платежи, можно принимать оплату по подписке, не храня данные карты на своем сервере. Какая организация подойдет, зависит от вашей бизнес-модели и целевого рынка.

Сколько длится процесс разработки SaaS?

Срок зависит от объема MVP, сложности модели подписки и потребности в интеграциях. Когда объем работ определен, мы готовим график, разбитый на этапы.

Что определяет объем разработки SaaS?

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

Можем ли мы потом передать продукт нашей собственной команде?

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

Давайте вместе оценим идею вашего продукта

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