SaaS / S+S *

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

В инете найти нужную инфу сложно, если не знаешь, что искать. Поэтому я и написал эту статью для тех, кто делает/хочет делать свой saas, но не знает, как продавать.

Почему saas – это другое

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

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

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

Сервис — это проверка физических и юридических лиц по открытым источникам. Пользователь вводит ИНН или ФИО и получает отчёт: есть ли долги, исполнительные производства, признаки банкротства, участие в сомнительных организациях и так далее. Отчёт собирается на лету по 10+ источникам.

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

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

Меня зовут Алексей, я делаю Steppo — расширение, превращающее клики в наглядные гайды. Последние полгода я усердно измеряю Time‑To‑Value (TTV): сколько секунд проходит между установкой и ценностью, когда человек говорит «Вау, оно работает!». Всё, что дольше 60 секунд, статистически превращается в болотце, где тонут конверсии.

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

Наша платформа для разработчиков продолжает развиваться и сегодня я расскажу о новой функционале - Секреты. Сервис секретов предназначен для хранения настроек к вашим приложениям, которые вы запускаете - локально, в CI/CD или в своих тестовых и продуктовых окружениях. Он является отличной альтернативой .env файлам и переменным окружениям в CI/CD системах.

«А как настроить интеграцию?», «Где скачать последнюю версию?», «Скиньте инструкцию, пожалуйста»

Я возглавляю Customer Success и мы работаем бок-о-бок с Pre-Sale инженерами, поэтому эти и еще десятки подобных вопросов я видел в чатах сопровождения клиентов с момента их создания. Как только я пришел на эту позицию, в 2022 году, я сразу понял, что вопросы циклично повторяются от клиента к клиенту, при чем, связано это не только со сложностью продукта, но и с тем, что мы все привыкли получать готовую информацию.

В какой-то момент я подумал: «Почему мы не можем просто один раз четко описать решение и забыть про эти повторяющиеся вопросы навсегда?» Но было несколько нюансов:

Piklema Predictive — российская компания, разрабатывающая решения для оптимизации горного производства через анализ данных диспетчеризации, цифровые советчики, MES-систем и планирования. За 4 года сотрудничества AvantIT выполнил три миграции их инфраструктуры между облаками (Azure → AWS → GCP → Azure), внедрил Kubernetes и настроил мониторинг, что позволило клиентам Piklema снизить затраты на производство на 15–20%.

Проблема:

Piklema столкнулась с двумя критичными ограничениями. Во-первых, их инфраструктура на Docker Compose не обеспечивала отказоустойчивость, требуемую промышленными заказчиками. Во-вторых, зависимость от грантов вынуждала ежегодно менять облачного провайдера, что приводило к ручным миграциям длительностью до 2 месяцев. Отсутствие мониторинга усугубляло риски: о нехватке ресурсов (например, места на диске) узнавали только после сбоев.

Цель проекта:

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

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

Если у вас уже есть MVP и вы даже смогли привлечь первых юзеров, перед вами встает целый ряд интересных задач: нужно разрабатывать новую функциональность, исправлять баги, обрабатывать запросы пользователей и искать способы привлечения новой аудитории. Крупным корпорациям в этом плане неплохо живется — обычно под каждую из таких задач формируется целый отдел. А что делать, если над вашим продуктом работает всего 5-6 человек?

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

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

Сегодня я расскажу о том, как мы этого добились. Не буду грузить вас объемными теориями и абстрактными понятиями (почти), а просто поделюсь практическими действиями, которые помогли именно нам. Вполне вероятно, что и вашей команде они смогут принести пользу.

Атаки с использованием похищенных учетных данных оказали огромное влияние в 2024 году, подпитываемые порочным кругом заражений инфостилерами и утечек данных. Но ситуация может усугубиться еще больше с появлением "Компьютерных агентов" (Computer-Using Agents) – нового типа ИИ-агентов, которые обеспечивают недорогую и простую автоматизацию обычных веб-задач, включая те, которые часто выполняются злоумышленниками.

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

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

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

За последние 8 лет я запустил больше 5 своих пет-проектов. Для меня не было проблемой разработать что-то, а вот продавать — тяжело. Тем более денег на продвижение всегда было мало или не было совсем.

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

Предположим, вы разработали первую версию вашего IT сервиса. Аудитория Хабра с этим справляется без особых проблем. При этом плюс-минус корректно определили свою целевую аудиторию и продукт действительно нужен. Даже есть первые продажи. Итак, как выйти на стабильный прирост аудитории?

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

Все эти проблемы можно решить или обойти – в этой статье поделюсь опытом того, как я это делал в своих проектах.

Disclaimer: я живу в США уже 8 лет (тут писал как получал гринкарту) и занимаюсь развитием стартапа B2C а теперь и B2B SaaS уже шесть лет именно на этом рынке. Поэтому мой опыт связан с американским/международным рынком, и подходы отработаны именно на нем.

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

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

Для этого вам потребуется какой-то сервис, который для вас переозвучит видео. Проведя исследование, я пришёл к выводу, что сейчас самый лучший по качеству сервис предоставляет (раск) rask.ai у них своя нейронка, и стоит их услуга примерно 100$ за 1 час переводов на 1 язык.

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

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

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

Disclaimer: я живу в США уже 8 лет и занимаюсь развитием стартапа B2C а теперь и B2B SaaS уже шесть лет именно на этом рынке. Поэтому мой опыт связан с американским/международным рынком, и подходы отработаны именно на нем.

Управление данными в корпоративных информационных системах становится всё более сложной задачей. Вслед за ростом бизнеса увеличивается объём и разнообразие обрабатываемой информации, что увеличивает нагрузку на ИТ-отделы.

Возьмём, к примеру, систему управления ИТ-услугами (ITSM) в крупной компании. По мере развития компании расширяется номенклатура типовых запросов в каталоге услуг. При традиционном подходе к организации каталога услуг для каждого типового запроса создается отдельная таблица, что снижает производительность системы и усложняет процесс её администрирования.

Расширенная модель записи (REM) является решением этой проблемы. Этот подход позволяет использовать одну таблицу для хранения типовых запросов. REM — это не теоретическая концепция, а проверенный на практике подход, который уже помогает оптимизировать работу информационных систем, ускорять разработку и снижать затраты на поддержку. Все бизнес-приложения SimpleOne используют REM подход: от систем управления ИТ-услугами до инструментов автоматизации корпоративных продаж.

Среда общих данных (СОД), как основополагающая часть технологий информационного моделирования (ТИМ), прочно заняла важное место в цепочке процессов цифровизации строительной отрасли.

Среда общих данных (СОД) - это программно-технический комплекс для совместной работы всех участников проекта с информационными моделями на всех стадиях жизненного цикла.

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

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

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

Добрый день! Меня зовут Игорь. Уже 3 года Я делаю бесплатный сервис для создания ментальных карт MIND IN MAP 🍀. За это время, я создал сотни ментальных карт для работы и учебы. В этой статье я делюсь опытом. Покажу как создавать ментальные карты и расскажу, где это можно делать бесплатно.

Самый конец 2007 года. Моя первая работа. В зоне ответственности — служба поддержки и мобильные сотрудники в пяти филиалах в разных областях. Объехать всех и проконтролировать — невозможно. Оставалось одно: доверять. Доверять всем: самим сотрудникам (часть из которых за штатом), менеджерам, региональным менеджерам, руководителям филиалов. Надо ли говорить, что цепочка доверия рвалась на раз-два и приводила к потерям сил, а главное, денег компании. Компания была большая, по-настоящему амбициозная и 400-500 тыс. руб. потерь на филиал в квартал немножко очень сильно лишали меня премии и остатков самоуважения. Ну а мобильные сотрудники тем временем спокойно филонили, увлекались схематозом и умудрялись эти самые премии получать — до первого попавшегося. Мы были бессильны.

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

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