«Сами напишем, там простая логика» — знакомая фраза? Через полгода выясняется, что один разработчик держит в голове всю схему пересчётов, а каждый третий клиент требует ручных правок счетов. Видел эту историю в четырёх компаниях. Команда закладывает неделю на MVP биллинга, а через два года сидит на легаси-спагетти, которую страшно трогать. Потому что «простая логика» оказывается льготными периодами, пересчётами при смене тарифа и кастомными скидками для крупных клиентов. Типичные грабли, на которые наступают все: 1. Недооценка edge cases. Клиент переходит с месячного тарифа на годовой посередине периода — как считать? А если у него был промокод? А если он приостанавливал подписку на две недели? 2. Хардкод вместо конфига. Бизнес-логика зашита в код. Каждое изменение тарифа = релиз. Маркетинг хочет акцию на неделю — ждите спринт. 3. Отсутствие аудита операций. Когда клиент спрашивает «почему с меня списали 1247₽ вместо 990₽» — нечего показать. Разработчик лезет в логи и пытается восстановить цепочку начислений. 4. Игнорирование идемпотентности. Дважды отправили запрос на списание — дважды списали. Сеть упала посередине транзакции — деньги зависли в воздухе. Что закладывать ДО первого клиента: слой абстракции для тарифов (таблица конфигов, а не if/else в коде), журнал всех операций с ID запросов для дедупликации, механизм пересчёта при изменениях (не руками каждый раз), интерфейс для саппорта — чтобы видели историю начислений без SQL-запросов к проду. Итог: биллинг только кажется простым. Если в вашей модели больше одного тарифа и есть хоть какая-то гибкость — закладывайте архитектуру сразу. Переписывать на горячую, когда клиентов уже сотни, — удовольствие сомнительное. Вы разрабатывали свой биллинг или брали готовое решение? Какие грабли оказались самыми болезненными?