Как запустить SaaS-проект № 2: необходимые функции

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

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

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

Используя существующее решение, вы получаете все это. Есть два подхода:

1. Использование размещенного сервиса, такого как Auth0. Основным преимуществом является простота интеграции с любой кодовой базой и сохранение пользовательских данных из вашей базы данных. Если вы взломаны, пользовательские данные остаются в безопасности. С другой стороны, если у вас будет много учетных записей, это может стать дорогостоящим.
2. Реализация библиотеки аутентификации, такой как Devise или Passport - этот подход мой любимый. Интеграция может быть немного более сложной (в зависимости от вашей структуры), и вы несете ответственность за хранение пользовательских данных. Но главное преимущество - дополнительная гибкость и стоимость 0 долларов.

Если вы планируете зарабатывать деньги с помощью SaaS, вам потребуется способ определить, за что их взимать. Я говорю о тарифных планах и их реализации. Вначале я советую идти с максимально простой ценой. Для FeedBear это был единый «Премиум» план с 14-дневным пробным периодом.

Таким образом, вам не нужно защищать функции на основе плана текущего пользователя или отслеживать их использование, что означает меньше кода. И меньше кода означает меньше ошибок и больше времени.

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

В общем, вы хотите две вещи:

1. Обрабатывайте платежи и снимайте деньги - для этого предназначены Stripe или Braintree. Мне также нравится хранить там как можно больше данных. Вам не нужно сохранять платежный адрес пользователя или идентификатор НДС в вашей базе данных. Сохраняйте только то, что вам нужно, запрашивайте другие вещи через API.
2. Разрешить пользователям платить и получать доступ к вашему приложению - это в основном работа с данными с первого шага. Это сложная часть.

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

1. Использование платежного сервиса . Такие инструменты, как Chargebee и Outseta, предоставляют встроенные решения, специально для SaaS, которые вы просто подключаете к своему бэкэнду и включаете в веб -интерфейс. Основным недостатком, конечно же, является добавленная стоимость.
2. Реализация библиотеки. Как вы, наверное, догадались, это мой любимый способ сделать это. Он бесплатный и довольно простой в настройке (опять же, YMMV в зависимости от того, какую платформу вы используете). В экосистеме Rails есть фантастическая жемчужина под названием Pay, которая работает со Stripe или Braintree.

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

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

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

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

Еще одна важная вещь, которую следует учитывать, - это определение объема данных для учетной записи. Это называется мульти-арендой. Вы не хотите оказаться в ситуации, когда данные из одной учетной записи «просачиваются» в другую. Например, сообщения из одного проекта FeedBear никогда не могут появляться в другом проекте.

Вы можете ограничить область данных на основе субдомена (например, FeedBear), URL-пути (например, Basecamp или Trello) или файла cookie сеанса. В экосистеме Rails посмотрите gem_sit_as_tenant или Apartment.

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

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

И когда я говорю об экономии времени и пропуске стандартного кода, я должен упомянуть Jumpstart. Это шаблон Ruby on Rails для запуска вашего проекта со всеми перечисленными выше функциями (и некоторыми другими), готовыми к работе. Если бы он существовал два года назад, он бы спас мне месяцы борьбы.

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