— Мы решили написать сами.

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

С этим сложно спорить. Скорее всего, первую версию действительно можно.

Меня зовут Лидия, я основатель LBX — биллинга для SaaS-продуктов. За последние годы я видела десятки компаний, которые принимали именно такое решение. Эта статья не о том, можно ли сегодня написать биллинг самостоятельно. Можно. Она о том, почему стоимость собственного биллинга почти никогда не равна стоимости первой версии.

Почему разработчик прав

Разработчики не преувеличивают, когда говорят «быстро». AI-инструменты правда изменили скорость написания первой версии. Основа подписочной модели, таблица тарифов, вызов API платёжной системы — такой прототип сегодня реально собрать за пару дней, а ещё несколько лет назад это заняло бы месяцы.

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

Не всё, что можно написать самому, стоит писать самому

При этом не стоит делать вывод, что всё нужно покупать. Написать свою мини-CRM для отдела продаж нормально. Если она перестанет учитывать какой-то нетипичный случай, максимум что случится: менеджер вручную поправит запись или пересчитает воронку в Excel. Ошибка в такой системе стоит часа неудобства.

Собственный биллинг — система другого класса критичности. Она считает чужие деньги, формирует юридически значимые документы, определяет, у кого есть доступ к продукту прямо сейчас. Ошибка здесь не «неудобно поправить», а «списали не ту сумму с карты клиента», «выставили счёт без НДС там, где он обязателен», «заблокировали доступ действующему клиенту, потому что разошлось состояние подписки». Ошибка в финансовой системе редко остаётся локальной: за ней тянутся возврат средств, объяснение клиенту, иногда юридический разбор.

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

Что не попадает в оценку «пара спринтов»

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

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

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

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

Что происходит с кодом во времени

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

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

AI-инструменты здесь не спасают, а ускоряют накопление. Cursor допишет ещё одно условие рядом с уже существующими двадцатью и не откажется, не скажет, что архитектуру пора менять. Он решает локальную задачу, а не думает о системе целиком. Скорость написания исключений растёт, понятность кода падает.

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

Человеческий фактор

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

Систему, которая проводит платежи, в таком состоянии боятся менять все, включая иногда самого автора, если он ещё в компании. Любое изменение превращается в отдельный проект с проверкой на проде, потому что тестового покрытия для «исключения для клиента №47» просто не существует.

Бизнес не обязан ограничиваться первой моделью монетизации

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

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

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

Дешевле написать — не значит дешевле владеть

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

Разница между «написать биллинг» и «купить биллинг» не в стоимости первой версии. Она в том, кто несёт риск ошибки и риск негибкости через два года: вендор, для которого это основная задача, или единственный разработчик, который завтра может заняться чем-то другим.