Пешком, на автобусе или пилить своё: транспортная модель выбора софта

У меня регулярно случается один и тот же разговор.

Кто-то из бизнеса, менеджмента или просто знакомых спрашивает что-то в духе:

А почему вы не можете просто взять готовый сервис?
А почему это так дорого?
А зачем платить за SaaS, если можно написать своё?
А зачем писать своё, если есть Jira/CRM/Notion/Excel/что-нибудь-ещё?

И каждый раз я ловлю себя на том, что начинаю объяснять через слова, которые для людей из мира IT привычны, а для людей со стороны звучат сложно: стоимость владения, интеграции, vendor lock-in, зрелость рынка, поддержка, кастомизация, инфраструктура, критичность процесса.

Человеку, далёкому от разработки, часто сложно понять, почему один и тот же вопрос может иметь разные ответы. Почему в одном случае «берём готовое и не выдумываем», в другом «пишем сами», в третьем «сначала собираем прототип на коленке», а в четвёртом «покупаем дорогую enterprise-систему и ещё полгода её внедряем».

В какой-то момент мне пришла в голову более приземлённая аналогия.

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

Есть точка А = текущая проблема.
Есть точка Б = состояние, в которое хочется попасть.

Например,
-сейчас заявки ведутся в Telegram и Excel, а хочется CRM
— сейчас задачи живут в чатах, а хочется нормальный task tracker
— сейчас отчёты собираются руками, а хочется автоматический дашборд
— сейчас релизы выкатываются вручную, а хочется CI/CD.

И дальше начинается самое интересное.

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

С софтом очень похоже.

Не существует лучшего транспорта

Когда мы выбираем техническое решение, часто хочется найти универсальный ответ.

Готовое лучше самописного?
SaaS лучше open source?
Своя команда лучше подрядчика?
No-code нормально или несерьёзно?
AI-прототип можно сразу нести в production или лучше не надо?

Но вопрос «что лучше?» сам по себе почти бесполезен.

-Метро лучше велосипеда?
-Зависит от маршрута.

-Такси лучше автобуса?
-Зависит от времени, бюджета и багажа.

-Своя машина лучше каршеринга?
-Зависит от того, как часто вы ездите и куда.

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

Зрелость рынка решает больше, чем кажется

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

Формально общественный транспорт есть. Автобусы ходят, маршруты существуют. Можно открыть приложение, посмотреть расписание и построить путь.

Но в реальной жизни всё сложнее. Автобус может часто опаздывает или отменяется. Маршрутов мало, и они не все для меня удобные. Пересадка может занимать слишком много времени, ждать 30 минут под палящим солнцем не самое приятное занятие. В какой-то момент понимаешь, что без машины многие простые бытовые задачи превращаются в маленький проект.

А теперь сравним это с большим мегаполисом.

Метро, автобусы, трамваи, МЦК, МЦД, такси, каршеринг, самокаты. В большинстве случаев тебе не нужно изобретать способ перемещения. Инфраструктура уже есть. Ты просто строишь маршрут.

До Кипра я жил в Москве и у меня никогда не было своей машины, такси, метро, трамвай автобус решали все мои вопросы.

В разработке есть ровно такая же разница между зрелыми и незрелыми рынками.

Возьмём task tracker. Это зрелый рынок. Jira, YouTrack, Linear, Asana, Trello, ClickUp, GitHub Issues, GitLab Issues, Kaiten… вариантов много. У них уже есть задачи, статусы, доски, роли, права, комментарии, уведомления, интеграции, API, история изменений, отчёты и мобильные приложения.

Поэтому идея «давайте напишем свой task tracker» в большинстве компаний должна вызывать не технический энтузиазм, а вопрос: зачем?

Это как стоять в городе с метро, автобусами, такси и каршерингом и говорить: «А давайте построим собственный автомобиль, чтобы доехать до соседнего района».

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

Но если аргумент звучит как «нам просто не нравится Jira», возможно, проблема не в отсутствии собственного task tracker. Возможно, надо сначала разобраться с процессом.

Неразвитый рынок меняет логику

Теперь обратная ситуация.

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

Это уже не похоже на московское метро. Это похоже на автобус на Кипре: формально транспорт есть, но строить вокруг него нормальную жизнь трудно.

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

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

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

Пешком: ручной процесс

Самый простой транспорт — ноги.

В разработке это ручной процесс: Excel, Google Sheets, Telegram, копипасты, письма, чек-листы, ручные сверки.

У такого подхода плохая репутация, но сам по себе он не плохой. Пешком нормально идти, если расстояние маленькое.

Если нужно один раз собрать список из 30 клиентов, не обязательно внедрять CRM. Если нужно разово обработать CSV, не обязательно строить data platform. Если нужно проверить гипотезу, иногда таблица лучше, чем полноценная система.

Проблемы начинаются, когда пеший маршрут становится ежедневным.

Сначала человек «просто раз в день обновляет табличку», потом это занимает час -> два -> появляется второй человек -> кто-то ошибается-> оказывается, что актуальных версий файла три -> бизнес приходит с фразой: «Нам срочно нужна автоматизация».

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

Самокат: скрипты, no-code и vibe coding

Самокат хорош для коротких дистанций.

Быстро, дёшево, почти без подготовки. Встал и поехал.

В разработке это небольшие скрипты, no-code-автоматизации, внутренние боты, Airtable, Retool, n8n, Make, Zapier, а теперь ещё и vibe coding, когда с помощью AI можно быстро собрать рабочий прототип.

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

Но у самоката есть понятные ограничения.

На нём неудобно ехать далеко, нельзя перевезти шкаф, неприятно ехать в дождь, опасно выезжать на трассу.

С быстрыми AI/no-code-решениями то же самое. Они прекрасны для проверки гипотез, прототипов и внутренних утилит. Но если такой прототип внезапно становится системой, через которую идут деньги, персональные данные, юридически значимые документы или критичные бизнес-процессы, стоит притормозить.

Самокат не станет грузовиком только потому, что к нему прикрутили корзинку.

Автобус: готовый SaaS

Автобус — это готовое решение.

Он уже ездит. У него есть маршрут, расписание, водитель и понятная цена. Вам не нужно покупать автобус, ремонтировать двигатель, нанимать механика и получать лицензию перевозчика.

В мире разработки это SaaS: task tracker, CRM, helpdesk, почта, аналитика, сервис рассылок, мониторинг, видеозвонки, платёжный провайдер, хранилище документов.

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

Но автобус едет по своему маршруту.

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

У SaaS похожая логика. Пока ваш процесс похож на процесс тысяч других компаний, готовое решение почти всегда выигрывает, но чем больше у вас специфики, тем больше компромиссов:

• такой интеграции нет,

• это только на enterprise-тарифе,

• API есть, но с ограничениями,

• экспорт есть, но не всех данных,

• логику поменять нельзя,

• вендор изменил цены,

• поддержка ответила через неделю.

Автобус хорош, когда маршрут совпадает с задачей. Когда не совпадает, он всё ещё может быть полезен, но уже не решает проблему целиком.

Метро и единый билет: платформы и экосистемы

Метро — это не просто транспорт. Это инфраструктура.

Оно предсказуемо, ходит часто, перевозит много людей и связывает ключевые точки города. В разработке на это похожи зрелые платформы и экосистемы: облака, GitHub, GitLab, PostgreSQL, Kubernetes, Microsoft 365, Google Workspace, Atlassian, Salesforce, Stripe, AWS, GCP, Azure.

Когда рынок зрелый, такие платформы дают огромный выигрыш. Вы покупаете не отдельный инструмент, а подключение к большой транспортной системе: документация, специалисты, best practices, интеграции, подрядчики, готовые ответы на типовые проблемы.

Отдельный интересный случай — единый билет, поехал на автобусе до метро, на метро до нужной станции, а там пару остановок на трамвае, но заплатил один раз.

Например, компания покупает Microsoft 365 и получает сразу почту, календарь, Teams, Office, OneDrive, SharePoint, администрирование пользователей и базовую безопасность. Или Google Workspace: почта, документы, таблицы, Meet, Drive, календарь и админка.

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

Но есть обратная сторона: вы начинаете жить по правилам этой транспортной системы.

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

Такси: подрядчики и интеграторы

Такси дороже автобуса, но гибче.

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

В разработке это подрядчики, агентства, интеграторы и внешние команды.

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

Но у такси есть особенность: водитель не живёт вашей жизнью.

Он довёз вас до точки, получил оплату и уехал. А вам потом жить с результатом.

В разработке это проявляется так: подрядчик сделал MVP, но код сложно поддерживать. Документация неполная. Архитектурные решения принимались под дедлайн. Команда ушла, знаний внутри не осталось. Любая доработка превращается в новый счёт.

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

Своя машина: собственная разработка

Своя машина — это свобода.

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

В разработке это собственный продукт или внутренняя система.

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

Но машина это не только покупка. Это страховка, ремонт, обслуживание, бензин, парковка, шины, налоги, мойка, амортизация и внезапные поломки.

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

Многие компании считают собственное решение как покупку машины: «разработать стоит X».

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

Иногда своё действительно дешевле и правильнее, но не потому, что «не надо платить SaaS». А потому, что готовые варианты плохо подходят под задачу, а у компании есть ресурсы не только написать, но и владеть этим решением.

Грузовик и спецтехника

Иногда обычная машина не подходит.

Нужно перевезти мебель, проехать по бездорожью, доставить бетон или работать в карьере. Тогда нужны грузовики, внедорожники, краны и спецтехника.

В разработке это сложные кастомные системы: логистическая маршрутизация, промышленный софт, антифрод, real-time аналитика, медицинские платформы, биллинг, embedded-разработка, внутренние ERP для нестандартных процессов.

В таких случаях вопрос «а почему бы просто не взять SaaS?» может быть наивным. Потому что SaaS — это автобус, а вам нужно перевезти экскаватор.

Но спецтехника дорогая. Её сложно обслуживать, для неё нужны специалисты, а ошибки стоят дорого.

Поэтому перед тем как строить свой уникальный комбайн, полезно честно спросить: у нас действительно поле, которое нельзя обработать обычным трактором, или нам просто нравится идея собственного комбайна?

Как выбирать

Мне кажется, хороший выбор начинается не с вопроса «писать или покупать».

Лучше начать с других вопросов.

• Насколько типовая задача?

• Насколько зрелый рынок?

• Что будет, если решение сломается?

• Это разовый маршрут или ежедневная поездка?

• Есть ли у нас груз, который нельзя везти обычным транспортом?

• Кто будет обслуживать решение через год?

• Сколько стоит не первая версия, а владение?

• Можно ли начать проще и пересесть позже?

• Насколько больно будет уйти с выбранного решения?

Ответы на эти вопросы часто быстро отрезвляют.

Для зрелого рынка и типовой задачи чаще всего лучше взять готовое. Писать свой task tracker, корпоративную почту или видеозвонки обычно нет смысла, если только у вас нет очень специфических ограничений.

Для гипотезы лучше начать пешком или на самокате: таблица, no-code, скрипт, AI-прототип.

Для временной задачи может подойти подрядчик.

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

Для инфраструктуры часто хороши managed services: не полностью SaaS, но и не самостоятельное обслуживание всего зоопарка.

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

Нормальная стратегия — это пересадки

В реальной жизни мы редко пользуемся только одним транспортом.

До метро можно дойти пешком. Потом проехать несколько станций. Потом взять самокат. А если ночью в аэропорт с чемоданами вызвать такси.

В разработке так же.

Можно начать с Google Sheets. Потом собрать no-code-прототип. Потом перейти на SaaS. Потом написать свой модуль там, где появилась уникальная логика. Потом часть инфраструктуры отдать managed-сервисам. Потом оставить готовый task tracker, но построить собственную аналитику поверх него.

Это нормально. Более того, часто это и есть здоровый путь.

Проблемы начинаются, когда временное решение притворяется постоянным, прототип — production-системой, SaaS — кастомной платформой, а самопис — дешёвой альтернативой, хотя на самом деле его просто никто не считает полностью.

Вместо вывода

Разработка это не всегда про «написать код».

Часто это про выбор способа добраться из точки А в точку Б с нужной скоростью, стоимостью, комфортом и уровнем риска.

• Иногда нужно идти пешком.

• Иногда лучше сесть на автобус.

• Иногда достаточно самоката.

• Иногда выгоднее такси.

• Иногда нужна своя машина.

• Иногда без грузовика никак.

• А иногда проблема не в транспорте, а в том, что дороги ещё нет.

Поэтому плохой вопрос звучит так:

Что лучше: купить готовое или написать самим?

Хороший вопрос звучит иначе:

Какая у нас задача, насколько развит рынок вокруг неё, что мы везём, насколько это критично, сколько стоит дорога и кто будет обслуживать транспорт после первой поездки?

И когда этот вопрос задан, и мы отвечаем на него честно, выбор обычно становится заметно проще.

p.s. еще пишу в tg-канале inspired_pm , приходите.