Когда LLM дешевле, чем купить SaaS: минимальная единица продаваемого ПО

Когда LLM дешевле, чем купить SaaS: минимальная единица продаваемого ПО

Автор статьи собирается развивать River, небольшой open-source queue для Go/Postgres, в коммерческий продукт. Он анализирует, имеет ли смысл продавать ПО в эпоху LLM, когда любое корпоративное приложение можно заставить написать Claude.

Он приводит пример: компания платила Atlassian 400 долларов в месяц за Jira и решила писать аналог на Claude вместо покупки. Однако расчёты показывают, что даже если инженер стоит 200k в год (примерно 96 долларов в час), он не может потратить больше 4 часов в месяц на обслуживание custom Jira, чтобы окупить эту подписку. Это нереально. Зато для Salesforce (500 долларов за место, 50 мест = 25k в месяц) build может иметь смысл, это уже стоимость полутора инженеров.

Ключевые факты

  • Базовая экономика: инженер 200k/год стоит примерно 16.7k в месяц или 96 долларов в час. На поддержку 400 долларов подписки может потратить только 4 часа в месяц, чтобы break-even.
  • LLM сделали software дешевле, но не свободным. Даже с Claude нужна итеративная работа, тестирование, обслуживание. Build требует минимум 2 недели работы, плюс каждый месяц 1-2 часа поддержки.
  • Зона жизнеспособности (Zone of Viability), цена, при которой покупка разумнее build. Она зависит от новизны и сложности: достаточно уникальное ПО сложнее восстановить LLM, и цена должна это отражать.
  • Salesforce (500 долларов за место) на 50 мест = 25k месячно. Это стоимость 1.5 инженера full-time, поэтому build становится привлекательным, даже с LLM.
  • River использует модель freemium: базовые функции свободные (open-source), Pro версия платная (125 долларов в месяц за до 20 разработчиков). Цена достаточно низкая и функции достаточно сложные, чтобы находиться в зоне жизнеспособности.

Ред. Весь спор «писать или купить» сводится к одной цифре: 4 часа поддержки в месяц. Claude напишет вам клон Jira за неделю, а вот окупить его вы математически не успеете.

Почему это важно

LLM перевернули логику buy vs. build в софт-индустрии. Раньше build был дорогой и требовал полную команду. Теперь индивидуальный разработчик может за неделю создать приложение, которое раньше писало бы пять инженеров. Но это не значит, что всё нужно писать самостоятельно. Статья определяет новую зону равновесия: ПО остаётся ценным, если его цена не позволяет окупить build полностью. Это вызов для SaaS вендоров переосмыслить свою ценность и стратегию цены.

Ред. Любопытный разворот: LLM удешевили создание софта и этим же подняли ценность дешёвой подписки. Платить 400 долларов выгоднее ровно потому, что собственный аналог сожрёт больше человеко-часов, чем стоит.

Кому это важно

SaaS-основателям и разработчикам, которые хотят создать компанию вокруг небольшого продукта. CTO и финансовым директорам, решающим, писать ли внутренний инструмент или купить. Venture-капиталистам, оценивающим жизнеспособность SaaS в эпоху LLM. Корпоративным покупателям, которые хотят понять, когда build действительно выгодней. Разработчикам, которые хотят вывести свой open-source проект на коммерческий уровень.

Ред. SaaS-основателям, которым теперь надо доказывать, что их продукт не пересобрать за выходные. И финдиректорам, для которых «давайте напишем сами на Claude» из шутки превратилось в строчку бюджета, требующую расчёта.

Как это применить

Если вы основатель: убедитесь, что ваш SaaS решает проблему, достаточно сложную и специализированную, чтобы LLM-rebuild занял по меньшей мере несколько недель. Установите цену ниже 4 часов инженерного времени в месяц (примерно 400+ долларов для высокооплачиваемых рынков) или предложите уникальные функции, которые нельзя легко дублировать. Если вы покупатель: для дешёвых подписок (менее 500 долларов в месяц) рассчитайте, не будет ли build дешевле на горизонте 1-2 лет. Для дорогих (Salesforce, Oracle) build часто имеет экономический смысл только для очень больших организаций.

Ред. Совет вендору почти издевательский: сделайте продукт достаточно сложным, чтобы LLM возилась неделями. То есть стратегия выживания это быть неудобным для воспроизведения, а не просто полезным.

Можно ли доверять

Математика изложена честно: автор показал расчёты, не скрывая предположений. Пример с Jira базируется на реальной истории (пост в LinkedIn). Цифры консервативны: 96 долларов в час на инженере невысокая для рынка. Однако расчёт не учитывает время контекст-переключения, управления, баг-фиксов в production, которые могут быть значительными. Также не учтена стоимость привлечения нового инженера для поддержки custom приложения.

Ред. Автор честно показал формулы и не спрятал допущения, 96 долларов в час даже занижены. Но за скобками осталось всё дорогое: контекст-переключения, прод-баги, найм того, кто будет нянчить самописную Jira в три часа ночи.

Риски и подводные камни

Build-цена может быть недооценена, особенно для сложного ПО. Люди часто забывают про мониторинг, безопасность, обновления, compliance. Через год-два custom приложение может требовать 10+ часов в месяц. Для open-source вроде River надёжность и поддержка важнее цены, чем для enterprise SaaS. Если ваш SaaS совсем простой (форма, отправка уведомлений), это действительно может быть LLM-replaceable. Статья не решает, что делать, если вы маленький стартап и не можете предложить достаточно жёсткую уникальность.

Ред. Главная ловушка в том, что стоимость build почти всегда недооценивают: мониторинг, безопасность, compliance всплывают через год как 10 часов в месяц. И вывод неутешителен для малых: если ваш SaaS это форма с уведомлением, его и правда заменит промпт.

«Even with gratuitous use of LLMs, you'd expect to spend at a minimum a few weeks on the initial push. From there, its internal owner will switch to bug fixes and feature development.»

— Brandur Leach, «The minimum viable unit of saleable software»