Зачем платить за SaaS, если его код лежит на GitHub: история Postiz

Postiz помогает планировать публикации в соцсетях. Его можно запустить на своём сервере или оформить подписку на облако. По README, на момент исследования обе версии давали одинаковые возможности.

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

Postiz вошёл в мою подборку из 100 проектов с TrustMRR. Его основатель связывает несколько скачков выручки с автоматизацией. Эта история даёт повод проверить, могут ли интеграции привлекать покупателей в новый SaaS.

Сначала планировщик, потом часть автоматизации

В репозитории ^[1] доступны исходники под AGPL-3.0, а рядом — ссылки на облако, документацию, API, SDK, модуль n8n и интеграцию Make. Пользователь может начать с самостоятельной установки, регистрации в облаке или подключения к другому инструменту.

Основатель Нево Давид пришёл к Postiz после опыта ^[2] с Novu и работы над Gitroom. В интервью Indie Hackers ^[3] он рассказывает, как сузил задачу продукта. Первые подписки появились, но затем рост замедлился.

Дальнейший рост он описывает так:

• Автоматизация помогла вырасти примерно с $6 тыс. до $12 тыс. MRR — ежемесячной повторяющейся выручки.

• Интеграция с OpenClaw совпала с ростом с $21 тыс. до $70 тыс. MRR за два месяца.

• В июне 2026 года основатель сообщил о $113 тыс. MRR.

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

Для человека, который вручную ведёт соцсети, Postiz решает задачу «разложить публикации по расписанию». У того, кто собирает автоматизацию, запрос другой: «из моего процесса должен получиться запланированный пост». Ему нужны API, понятная документация и способ проверить, что всё работает вместе.

Страницы для тех, кто уже выбирает

У Postiz есть сравнение с Buffer ^[4] и страница альтернативы Buffer ^[5]. Они адресованы человеку, который уже выбирает сервис для публикаций или ищет замену Buffer.

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

В исследовании я подтвердил наличие этих страниц, но не установил их позиции в поиске, трафик или выручку. Назвать SEO главным источником роста Postiz на этих данных нельзя.

Почему GitHub-звезда ещё ничего не говорит о покупке

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

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

Что из этой истории можно проверить у себя

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

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

Что показывать вместо списка возможностей API

Возьмём условный сервис для публикаций. Сценарий ниже придуман для эксперимента и не описывает кампанию Postiz.

Редактор ведёт таблицу материалов. Когда у строки появляется статус «Готово», автоматизация забирает текст, отправляет публикацию на финальную проверку и после подтверждения ставит её в расписание.

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

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

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

Как понять, сработал ли пример

Этапы проверки: визит → настройка → первый результат → оплата.

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

Для похожего продукта я бы отслеживал четыре события:

Это предложение для своего эксперимента; внутренней аналитики Postiz у нас нет.

Как запустить такой эксперимент

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

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

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

3. Собрать минимальную интеграцию и довести одну задачу до конца.

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

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

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

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

Я собрал для вас 100 таких разборов в боте GTM Directory ^[6]: как продукты находили первых пользователей, какие каналы пробовали и как менялась их стратегия роста. В каждом разборе есть хронология и ссылки на источники. База будет пополняться новыми кейсами. Открывайте бота и выбирайте кейс, близкий к вашему продукту.