Хотите создать свой ИТ SAAS-бизнес? Работать в РФ и по миру? Детальное руководство для запуска и "пища" для размышлений

Привет, меня зовут Максим Кульгин, я основатель нескольких SaaS — проектов в РФ. Мы защищаем от скликивания рекламы, собираем необходимые для успешной коммерции данные. Сегодня попытаюсь вдохновить вас на создание своего SaaS-бизнеса. На изображении, кстати, доходность SAAS по миру: краснее = прибыльнее! А в конце статьи будет несколько полезных ссылок.

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

SaaS дословно — это «программное обеспечение как услуга», «software as service» — модель продажи ПО, когда оно полностью обслуживается провайдером, расположено (по крайней мере в части главного функционала) на его серверах, а клиент получает доступ к требуемой функциональности посредством «тонкого клиента» (в основном браузера или мобильного приложения) .

За последние пару лет это новшество стало настолько популярным, что все только о нём и говорят. Количество компаний, использующих SaaS, уже перевалило за 86% и будет только расти. Все мировые ИТ-воротилы — Google, Microsoft, Apple, Yandex — создают всё больше и больше продуктов, продаваемых по методу SaaS.

И теперь вопрос только один — как вскочить в этот поезд? То есть, как сделать SaaS-продукт? Как его продавать с выгодой? Как это всё сделать быстро?

Мои компании работают по модели SaaS. Для нас это не дань моде и не способ наращивания монетизации. Просто невозможно иным способом предоставить те услуги, которые мы оказываем: пулы серверов и нейронки (которые задействуются для парсинга данных или защиты от скликивания) попросту не могут быть втиснуты на компьютеры клиентов.

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

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

«Погодите, — удивитесь вы, — а при чем же тут SaaS?»

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

В западном мире редко встретишь предпринимателя, который бы не пытался встроиться в новую систему. По данным прошлогоднего исследования BetterCloud к 2025 году «буквально каждая организация станет SaaS».

Аналитики The Business Research Company оптимистично предсказывают, что к концу 2023 года рынок SaaS перевалит за 250 млрд. долларов. К 2027-му они предсказывают вообще 330 млрд. У нас в стране всё немного менее предсказуемо, но мировые тенденции в ИТ всегда отражаются точно, просто в иных масштабах.

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

Создание продуктов SaaS в 2023 году — это стратегический шаг, который не только окупится, но и принесет конкурентное преимущество.

Пока что США лидирует на рынке разработки приложений SaaS, но темпы роста в разных регионах постепенно меняются.

Если оценивать рынки с точки зрения потенциала в долгосрочной перспективе (отталкиваясь от темпов роста) , то самым прибыльным обещает стать Азиатско-Тихоокеанский регион.

Если же говорить о надежности вложений (отталкиваясь от развития ИТ-инфраструктуры) , то западные страны остаются самым безопасным выбором.

Вот приблизительная оценка доходов SaaS-продуктов по регионам.

В настоящее время в мире насчитывается более 30 000 SaaS-компаний. Трудно сказать насколько сильна конкуренция в общем: сферы применения ПО безграничны, в каждой из них своя доходность, трудность реализации и, соответственно, уровень соревнования. Доминирующее положение имеют AWS, Microsoft и Google — вместе они занимают примерно 60% рынка облачных приложений.

Наиболее вдохновляющими примерами облачных компаний могут послужить Salesforce, Slack и Shopify — все три предоставляют доступ к совершенно разным типам сервисов и являются лидерами в своих отраслях.

Salesforce предлагает CRM-решения и автоматизацию маркетинга, Slack — хорошо известный инструмент для внутренней коммуникации, а Shopify — поставщик SaaS для предприятий электронной коммерции.

Slack на днях прекратил работу в РФ, всем пришлось мигрировать на другие решения. Но на приветственной странице по-прежнему можно видеть бренды российских компаний.

Недавно, в 2021-ом Salesforce купили Slack за 27 млрд. долларов.

Итак, чем же модель SaaS так хороша? Что делает её таким полезным инструментом, когда речь заходит о бизнес-операциях?

Преимущество удобно рассмотреть с двух позиций: со стороны пользователей и со стороны разработчиков.

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

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

Опрос, проведенный BetterCloud, показал, что основными причинами, по которым ИТ-специалисты покупают SaaS-приложения, являются:

• экономическая эффективность;
• безопасность и простота использования.

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

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

Их несколько. Поскольку они менее очевидны, их стоит рассмотреть подробнее.

1. Более длительный доход при минимальных усилиях.

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

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

2. Значительное расширение клиентской базы.

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

А это значит, что потенциальные клиенты будут легко идти на пробное использование. Если продукт действительно хорош — конверсия и приток новых клиентов будет фантастической!

3. Надежность и доступность.

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

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

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

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

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

1. Ежемесячная/годовая подписка.

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

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

2. Ценообразование, основанное на использовании.

Плата взимается в зависимости от того, какое количество услуг или данных было получено. Так работает Amazon Web Services — количество транзакций или гигабайтов переданных данных определяют сумму платежа.

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

3. Фримиум.

Как несложно догадаться из названия, образованного из слов «free» и «premium» — такие тарифные планы подразумевают сочетание платного и бесплатного: пользователь получает доступ к ограниченному количеству функций (или иной мере продукта/услуги) и должен платить за всё, что «сверху».

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

Пользователю дается некоторая свобода, чтобы он «вошел во вкус» и «дозрел» до покупки заветной «pro», дающей неограниченный доступ.

Фримиум имеет очевидные психологические преимущества. Во-первых, поддерживается лояльность клиентов: если у них небольшие запросы (а в большинстве случаев это так, особенно на начальном уровне пользования сервисом) — они ничего не платят. Во-вторых, такой метод монетизации отлично способствует «вирусному» распространению сервиса и обеспечивает относительно легкий выход на рынок.

Есть и более сложные схемы, которые основаны на частичном сочетании рассмотренных базовых вариантов.

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

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

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

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

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

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

Развертывание с нулевым временем простоя

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

Нулевое время простоя — это стратегия, когда SaaS-сайт никогда не впадает в состояние хотя бы частичной неисправности.

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

У каждого из этих способов есть свои преимущества и недостатки. На данном этапе погружение в технические особенности преждевременно, со временем всё прояснится само собой.

Обеспечение безопасности

SaaS — это когда вообще все заботы берет на себя разработчик, в том числе по охране безопасности клиента.

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

Основные проблемы безопасности:

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

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

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

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

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

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

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

Надежная команда

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

В этом SaaS не сильно отличается от других сфер бизнеса.

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

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

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

Наиболее общим ответом был бы JavaScript как на стороне клиента (Angular, React, Vue. js) , так и на стороне сервера (Node. js) . Его же удобно использовать и на смартфонах (React Native) .

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

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

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

Продолжим разговор о технологиях.

При создания ПО для SaaS также потребуется надежная облачная база данных. Если говорить о реляционных базах данных, то сейчас два основных конкурента: MySQL и PostgreSQL. Разработчиков много, проблем поиска специалиста не возникнет.

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

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

Шаг 1. Исследование рынка.

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

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

Здесь как нельзя лучше использовать подход «сначала продайте, потом делайте», о котором мы даже написали целую статью. Статья настоятельно рекомендуется к прочтению всем, кто задумывается о создании своего стартапа. Отдельную ценность добавляют более чем 80 комментариев в обсуждении.

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

Шаг 2. Определение требований, разработка бизнес-плана.

После углубленного исследования рынка можно приступать к составлению списка требований и созданию бизнес-плана.

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

При составлении бизнес-плана нужно задать себе несколько вопросов:

• На какие болевые точки направлен продукт?
• В чем заключается УТП (уникальное торговое предложение) ?
• Как выделиться среди конкурентов?
• Кто целевая аудитория?
• Каковы бюджетные ограничения?
• Какие модели ценообразования подойдут лучше всего?
• Каков ожидаемый коэффициент прибыльности?

Когда дело создается SaaS, необходимо учитывать три основных момента:

• возможности интеграции;
• кастомизация;
• безопасность.

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

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

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

Шаг 3. Создание MVP.

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

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

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

На первом шаге мы не создаем ничего реального — только сайт, лендинг или формочки без какого-либо работающего кода. Только собираем реакции посетителей.

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

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

• Какие функции были самыми популярными?
• Что нужно изменить или даже удалить?
• Подтвердились ли предположения о целевой аудитории?
• Имеется ли спрос на продукт?
• Не разочаровываются ли пользователи?
• Нужно ли менять ценовую политику?

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

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

Шаг 4. Создание команды.

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

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

Здесь нет однозначного рецепта:

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

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

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

Шаг 5. На взлёт!

Финишная прямая! Ну, почти. Всё для завершения проекта есть. Осталось только нарастить необходимую функциональность на ту самую «минимально жизнеспособную версию» — и вперёд!

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

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

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

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

Чтобы проект успешно развивался в долгосрочной перспективе — нужен целый ряд составляющих:

• правильная стратегия;
• высокопрофессиональная команда;
• свежие идеи.

Когда всё сделано правильно, случается то, что в народе называется «пришла удача».

Если есть уже работающее традиционное настольное ПО, то можно рассмотреть возможность его преобразования в SaaS.

Но надо убедиться, что ПО останется доступно широкому кругу клиентов. Если ПО очень специфическое, требует вычислительных ресурсов на стороне клиента, то перевод его в формат SaaS будет, конечно, неосуществимой идеей.

Вот ключевые шаги для перевода ПО на модель SaaS:

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

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

Невозможно рассчитать время, необходимое на создание сервиса, без знания требований и точной оценки возможностей команды разработчиков.

Как правило, от первых шагов до первых клиентов уходит от 4 месяцев до года.

Для грубой оценки, вот данные по созданию сервиса уровня Slack в формате «вид работы» — «затраченное время в часах»:

• IOS — 850
• Android — 850
• Серверная часть — 900
• UI/UX-дизайн (для одной платформы) — 80
• итого — 2680

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

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

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

Если используется удаленная работа, то месторасположение членов команды может оказать значительное влияние на конечную стоимость. Не секрет, что программисты в Южной Азии или Южной Америке могут просить на порядок меньше, чем программисты из США или Канады. Но и качество работы тоже в среднем будет зависеть от региона. Термин «индусский код» уже давно вошел в обиход.

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

Давайте просто прикинем стоимость. Для этого возьмем числа из оценки времени выше. Итак, 850 часов на разработку под Android. Если привлечь самого дешевого американского разработчика, то получится почти 35 тыс. долларов. А это дорого и качество не очень.

Здесь-то и начинаешь ценить нашу непритязательность и наш высочайший уровень образования. Российский студент (даже не на полный рабочий день) — лучший работник по соотношению цены и качества. Дополнительным плюсом будет и плотность квалифицированных разработчиков в России: найти или заменить специалиста не составит особого труда.

Всё-таки не правильно смешивать оценку стоимости разработки полноценного сервиса и затраты на минимально жизнеспособную версию — требования к надежности, отказоустойчивости совершенно разные. Для западных рынков стоимость MVP, как правило, потребует от 15 до 50 тыс. долларов в зависимости от сложности работы. В нашей стране эту величину можно попробовать уменьшить в 3−5 раз.

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

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

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

• 618 000 ₽ в месяц. SaaS в России. Делимся нашим опытом, графиками и цифрами. Посвящается тем, кто надеется побыстрее
• С 0 до 430 000 рублей в месяц. Опыт развития SAAS-сервиса в России. Медленно всё
• Как получить грант 4 млн. рублей от ФСИ на запуск вашего ИТ стартапа? Наш опыт с детальным разбором заявки
• Как стать резидентом Сколково? Наш опыт с детальным разбором заявки
• Делаете стартап? — Сначала продай, а потом делайте! Можно иначе? Да, но продай сначала
• 12 правил стартапа, написанных горючими слезами
• Путь стартапа. От идеи до рабочего бизнеса. 18 шагов опыта
• 77 полезных вещей, которые узнал после создания 10+ технологических стартапов
• Как получить более 20 000 пользователей по миру за три месяца с бюджетом $50?
• 19 лучших рекламных сетей для рекламодателей — альтернативы Google и Facebook (Meta) в условиях санкций
• Статистика по скликиванию рекламы на 2022 год. Сколько воруют денег?

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

Как вы думаете: сегодняшний рынок SaaS — это «голубой» или «красный океан»? Ещё можно создать прорывной продукт на рынке SaaS? Пишите в комментариях или подписывайтесь на канал Телеграм (ссылка была выше) .