AI сделал разработку биллинга дешёвой. Стоимость никуда не исчезла

[Olegun]

Иногда вендоров уходят. И тогда …

[lidia_zakharova]

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

[ED-209]

Автор этого кода через какое-то время уходит из проекта или переключается на другие задачи.

Автор этого кода через какое-то время вовремя уходит из проекта или переключается на другие задачи.

[lidia_zakharova]

Автору хорошо ) а тем, кто остался предстоит увлекательное приключение...

[trublast]

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

Я бы тут подискутировал. Разобраться в продукте, который "может всё" чаще даже сложнее, чем писать код на "всем понятном питоне или го".

Потому что питон и го - условно одинаковые, и широко распространены. А какой-то вендорский продукт работает "как-то так, как задумал вендор". Может быть так, как вам надо, а может быть и нет. То есть помимо того, что нужно как-то понять логику его работы (а "учебника по биллингу" скорее всего нет, и уж точно нет "другого учебника, если этот непонятный", в отличие от учебников по питону), так ещё и внести изменения скорее всего будет не очень просто.

Так что если посмотреть с этой стороны, то выглядеть всё может ровно наоборот - с вендорский решением легко начать работать, а вот потом могу возникнуть сложности (но, конечно же, не обязательно они возникнут)

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

В общем всё не так однозначно. И да и нет.

[ED-209]

Вендорские решения - они все обкатанные на сотнях внедренных проектах, годами и десятилетиями наработанная обширная практика. Меньше всего подводных камней будет. Шанс завернуть легкомысленным пируэтом в тупиковую ситуацию гораздо меньше. А вот с точки зрения соло разработчика, особенно, если еще не опытного (кодить могу, есть ассистенс ИИ, готов запилить любой проект!), который с шашкой наголо "заряжай спринты, погнали!" - концовка, чаще всего, предсказуема. О чем и речь в статье, собственно.

[lidia_zakharova]

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

[eHotNK]

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

[lidia_zakharova]

Поддержу дискуссию. Есть несколько классов продуктов:

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

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

• Массовые продукты. Можно самому разобраться, настроить и начать работу
  

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

А какой-то вендорский продукт работает "как-то так, как задумал вендор". Может быть так, как вам надо, а может быть и нет. 

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

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

[catherinei]

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

[lidia_zakharova]

а затраты на интеграцию биллинга в SaaS? велики ли? 

Если биллинг предоставляет API и webhooks, то интеграция обычно занимает 1–4 недели. Срок зависит от сложности бизнес-процессов и объема интеграции: какие сценарии нужно автоматизировать и можно ли внедрять их поэтапно. Также многое зависит от того, готовы ли вы использовать готовый self-service виджет или личный кабинет биллинга, либо планируете разрабатывать собственный интерфейс поверх API.

 Я пишу свой SaaS и свой биллинг, но это хрупкое место, возможно лучше приобрести лицензию. Что порекомендуете?

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

Если есть различные тарифы, дополнительные опции, usage-based/pay as you go, нужны разные периоды, апгрейды, перерасчеты в середине периода, работа с юрлицами, то стоит посмотреть в сторону готовых решений.