Как я веду разработку своего SaaS в 2к26

Мой подход простой — обвесить метриками всё до чего могу дотянуться, и каждый день на их основе что-то улучшать.
Ошибки, скорость API, запросы к базе, очереди, загрузку серверов, работу фоновых задач, стоимость токенов разных моделек. И рядом — продуктовые метрики. Откуда пришёл пользователь, где застрял, дошёл ли до первого полезного результата, заплатил ли, вернулся ли потом.
Весь путь от клика до результата. В том числе сколько времени, ресурсов и денег этот результат стоил.

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

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

С архитектурой тот же принцип: понимать, что происходит.
В JobTurbo компоненты распределены между несколькими серверами — веб и API, Telegram-бот, фоновые воркеры, мониторинг. Тяжёлые задачи уходят через очередь к воркерам, их мощности можно наращивать отдельно.
У такой махины есть своя ежедневная работа. Следить за очередями, зависшими задачами, связью между сервисами и внешними зависимостями. Поэтому метрики и логи собираются в общую картину. Нужно видеть, где именно задача остановилась и что в этот момент происходит с остальной системой.
Мне нравится этот цикл, увидел проблему - разобрался - сделал небольшой коммит - проверил эффект. Когда повторяешь его каждый день, продукт постепенно становится удобнее и надёжнее.

А как вы разрабатываете свои петы сейчас?

В комментах приложил скрины внутрянки