Стоимость разработки FinTech-приложения может начинаться примерно от 60 000 долларов США и превышать 500 000 долларов США, в зависимости от того, что именно вы создаете. Причина в том, что приложение для личных финансов, цифровой кошелек, решение для мобильного банкинга и торговая платформа требуют совершенно разной финансовой логики, интеграций, средств контроля безопасности и инфраструктуры.
FinTech — это гораздо более широкая категория, чем мобильный банкинг или платежи. Здесь мы сосредоточимся на шести распространенных типах приложений: личные финансы, цифровые кошельки и платежи, кредитование, страхование, мобильный банкинг, инвестиционные и торговые приложения.
В этой статье мы разбиваем стоимость разработки FinTech-приложения по типу продукта и функциональности, показываем, что может увеличить первоначальную оценку, и рассматриваем расходы, которые часто возникают после начала разработки.
Стоимость разработки FinTech-приложения по типу приложения
Тип приложения — лучшая отправная точка для планирования бюджета. Например, приложение для ведения бюджета может в основном обрабатывать и визуализировать финансовые данные. В то же время продукты для мобильного банкинга и трейдинга часто требуют инфраструктуры транзакций, операционных инструментов, данных в реальном времени и внешних финансовых интеграций.
Эти диапазоны предполагают заказную разработку. Окончательная оценка стоимости разработки FinTech-приложения меняется в зависимости от уже существующей финансовой инфраструктуры, количества сторонних сервисов, поддерживаемых платформ и применимых нормативных требований.
Приложения для личных финансов (45 000–150 000 долларов США)
Приложение для личных финансов может начинаться с агрегации счетов, категоризации расходов, бюджетирования, целей сбережений и базовой аналитики. Поскольку этот тип продукта в основном считывает, систематизирует и отображает финансовые данные, первоначальный объем работ может оставаться относительно ограниченным.
Сложность возрастает, когда приложению требуются интеграции с несколькими банками или провайдерами открытого банкинга, синхронизация в реальном времени, отслеживание инвестиций, прогнозирование или персонализированные инсайты на основе ИИ, что добавляет больше задач по обработке данных и серверной части (бэкенду).
Приложения для цифровых кошельков и платежей (80 000–200 000 долларов США)
Платежные приложения должны обрабатывать проверку пользователей, балансы, статусы транзакций, возвраты средств, лимиты, уведомления и неудачные транзакции. При наличии одного провайдера и простого платежного потока большая часть этой логики остается в относительно предсказуемых рамках.
Оценка растет, когда один и тот же продукт должен поддерживать несколько платежных систем, валют, международных переводов, выпуск карт или более сложные средства контроля мошенничества, поскольку каждое дополнение создает больше сценариев транзакций для реализации и тестирования.
Приложения для кредитования (90 000–220 000 долларов США)
Приложение для кредитования обычно сочетает в себе онбординг клиентов с заявками на кредит, проверку личности, логику принятия решений, погашение, уведомления и операционный интерфейс. Сложность этого рабочего процесса сильно зависит от того, как именно принимается решение о выдаче кредита.
Стандартизированные правила делают объем работ более предсказуемым, в то время как пользовательский скоринг, несколько провайдеров кредитных данных, несколько кредитных продуктов и сложные графики погашения добавляют логику на бэкенде и требуют более обширного тестирования по всем сценариям кредитования.
Страховые приложения (100 000–250 000 долларов США)
Страховые приложения могут поддерживать котировки, полисы, претензии, платежи, документы и общение между клиентами и страховщиками. Объем разработки страхового программного обеспечения сильно зависит от того, насколько сложны рабочие процессы по полисам и претензиям.
Продукт с простыми процессами оформления полисов и претензий может оставаться ближе к нижней границе ценового диапазона. Напротив, пользовательская логика андеррайтинга, несколько страховых продуктов, автоматизированная обработка претензий и интеграция с устаревшими системами добавляют бизнес-правила и работу по интеграции.
Приложения для мобильного банкинга (150 000–450 000 долларов США)
Стоимость разработки приложения для мобильного банкинга сильно зависит от того, что уже существует за пределами приложения.
Если у банка уже есть базовая инфраструктура, разработка может быть сосредоточена на мобильной функциональности и интеграциях. Новое решение для цифрового банкинга также может потребовать инфраструктуры счетов, обработки транзакций, рабочих процессов KYC, карт, платежных сервисов, контроля мошенничества и бэк-офиса. В SoftTeco мы в настоящее время оцениваем нативное приложение для мобильного банкинга или управления финансами в 150 000–450 000 долларов США.
Мобильный интерфейс, построенный на существующей банковской инфраструктуре, имеет совершенно иной объем работ, чем продукт, который также требует пользовательских систем счетов, транзакций и бэкенда. Банковский интерфейс может стоить от 20 000 до 60 000 долларов США, в то время как пользовательская платформа с проприетарной бэкенд-инфраструктурой может достигать 800 000–2 000 000+ долларов США.
При сравнении стоимости разработки банковского приложения проверяйте, что именно включено в смету.
Инвестиционные и торговые приложения (150 000–500 000 долларов США)
Инвестиционные приложения могут сочетать в себе онбординг, портфели, депозиты, историю транзакций, рыночные данные, исполнение ордеров, аналитику и интеграции с брокерами.
Цены в реальном времени, несколько классов активов, пользовательская инвестиционная логика, сложные графики и несколько внешних источников данных могут быстро приблизить проект к верхней границе диапазона.
Большая часть усилий по разработке уходит на надежную синхронизацию финансовых данных, ордеров, балансов и внешних систем.
Сколько стоят функции FinTech-приложения?
Хотя тип приложения дает вам отправную точку, набор функций определяет, где именно в этом диапазоне окажется окончательная оценка. Некоторые функции относительно автономны. Другие одновременно влияют на бэкенд, интеграции, инфраструктуру, безопасность и тестирование.
Аутентификация и онбординг (10 000–25 000 долларов США)
Аутентификация и онбординг обычно включают регистрацию, вход в систему, восстановление пароля, настройку учетной записи и базовую проверку пользователя.
Расходы возрастают, когда приложению требуется многофакторная аутентификация, биометрия, проверка устройства, несколько ролей пользователей или дополнительные потоки онбординга. Каждый дополнительный метод аутентификации также должен стабильно работать на всех поддерживаемых платформах и в сценариях сбоев.
KYC и проверка личности (15 000–40 000 долларов США)
Функциональность KYC обычно включает провайдера проверки личности, подачу документов, статусы проверки, уведомления пользователей и обработку исключений. При наличии одного провайдера и стандартного потока проверки большая часть работы сосредоточена на интеграции и пользовательском пути.
Объем работ расширяется, когда проверка проходит по нескольким путям, таким как использование нескольких провайдеров, ручная проверка, различные типы документов или специфические требования рынка. Каждый дополнительный путь должен быть отражен в логике бэкенда и протестирован отдельно.
Платежи и переводы (20 000–50 000 долларов США)
Платежная функциональность может включать инициирование транзакции, интеграцию с платежным провайдером, лимиты, статусы транзакций, возвраты, отмены и обработку сбоев.
Один платежный метод с одним провайдером реализовать проще, чем продукт, поддерживающий несколько платежных систем, валют, международных переводов или сложных правил транзакций. Сверка и надежная обработка неудачных или прерванных транзакций еще больше расширяют объем работ.
Интеграции с финансовыми API (20 000–60 000 долларов США за интеграцию)
Финансовые API связывают продукт с банками, платформами открытого банкинга, брокерскими компаниями, кредитными бюро, поставщиками рыночных данных и другими финансовыми сервисами. Интеграция банковских API — распространенный пример, однако объем инженерных работ может существенно различаться даже между интеграциями, которые служат одной и той же бизнес-цели.
Методы аутентификации, требования к синхронизации, лимиты запросов, сопоставление данных, обработка ошибок и качество API — все это влияет на реализацию. Плохая документация или устаревшие интерфейсы добавляют неопределенности, так как требуется больше времени на тестирование реального поведения провайдера и обработку исключительных ситуаций.
Управление счетами и картами ($15 000–$40 000)
Этот функционал может включать балансы счетов, историю транзакций, данные карт, лимиты, настройки счетов и такие действия, как блокировка или разблокировка карты.
Объем работ увеличивается, когда продукт управляет несколькими типами счетов или карт, требует обновления баланса в режиме реального времени, поддерживает сложные права доступа или подключается к внешним системам выпуска карт и банковским системам.
Аналитика и отчетность ($10 000–$30 000)
Базовая аналитика может включать категории расходов, сводки транзакций, стандартные дашборды и предопределенные отчеты. На этом уровне основная работа сосредоточена на представлении данных, которые продукт уже собирает.
Объем работ меняется, когда отчеты требуют пользовательских финансовых расчетов, обновлений в реальном времени или данных из нескольких систем. В этом случае команде приходится создавать дополнительную логику агрегации, синхронизации и обработки, прежде чем эта информация сможет появиться на дашборде.
Безопасность и контроль мошенничества ($15 000–$50 000+)
Функционал безопасности может включать шифрование, контроль доступа, журналы аудита, мониторинг транзакций, правила оценки рисков и проверки на мошенничество. Некоторые из этих элементов являются частью базовой архитектуры продукта, в то время как другие требуют внедрения собственных рабочих процессов и логики мониторинга.
Пользовательские правила борьбы с мошенничеством, несколько уровней аутентификации, подробные журналы аудита или дополнительное тестирование безопасности влияют более чем на одну изолированную функцию: они могут изменить логику бэкенда, инфраструктуру и объем работ по обеспечению качества (QA). Продуктам со сложными сценариями мошенничества также может потребоваться консультация специалистов по антифрод-системам для определения соответствующих мер контроля и того, как предотвращение мошенничества должно вписываться в рабочие процессы транзакций.
Уведомления ($5 000–$15 000)
Базовая настройка уведомлений обычно охватывает push-сообщения, электронную почту или SMS-оповещения, инициируемые предопределенными событиями.
Затраты возрастают при использовании нескольких каналов связи, настроек предпочтений пользователя, локализации, отслеживания доставки, сложных триггеров на основе транзакций или нескольких сервисов рассылки. Финансовые уведомления также требуют надежной обработки событий, чтобы предотвратить появление некорректных, задержанных или дублирующихся сообщений о транзакциях.
Функционал ИИ ($25 000–$80 000+)
Функционал ИИ может поддерживать обнаружение мошенничества, обработку документов, финансовые помощники, рекомендации, прогнозирование и персонализированную аналитику. Использование существующего сервиса ИИ может сократить усилия по разработке моделей, но использование в продакшене все равно требует оценки, защитных механизмов, мониторинга и логики резервного копирования.
Для финансовых сценариев большая часть инженерной работы уходит на обеспечение надежности модели в продакшене, особенно когда результаты влияют на рекомендации клиентам, оценку рисков или автоматизированные решения. Пользовательские модели требуют дополнительных усилий по созданию конвейеров данных, обучению или дообучению, валидации и переобучению, при этом низкое качество данных может увеличить объем работ для любого из подходов.
Почему нельзя просто сложить эти затраты?
Оценки функций — это не отдельные ценники. Аутентификация, инфраструктура, безопасность и логика бэкенда часто являются общими для нескольких функций.
В то же время одна сложная функция может расширить объем связанных работ. Поэтому затраты на уровне функций полезны для предварительного планирования, тогда как итоговая оценка должна основываться на полной архитектуре и финансовых рабочих процессах.
Снижает ли ИИ стоимость разработки FinTech-продуктов?
Разработка с помощью ИИ может сократить усилия при написании рутинного кода, генерации тестов, документации и рефакторинге, поскольку эти задачи легче стандартизировать и автоматизировать. Экономия менее предсказуема в областях, зависящих от внешних систем, финансовых правил или специфических для продукта крайних случаев.
Это особенно актуально для интеграций и рабочих процессов с большим количеством транзакций. Интеграции все равно должны быть проверены на соответствие реальному поведению провайдера, а потоки транзакций, меры безопасности и бэк-офисные процессы требуют тщательного анализа. Таким образом, более быстрая генерация кода может снизить трудозатраты в некоторых направлениях, не уменьшая общую стоимость проекта в той же пропорции.
Для планирования бюджета ИИ лучше рассматривать как фактор производительности в отдельных задачах, а не как фиксированную скидку на весь FinTech-проект.
Что влияет на стоимость FinTech-приложения?
Два FinTech-продукта с похожим функционалом могут требовать совершенно разных бюджетов, если учесть архитектуру, интеграции, масштаб, безопасность и инфраструктуру.
Архитектура бэкенда
Бэкенд становится основным фактором затрат, когда приложению необходимо управлять финансовым состоянием, транзакциями, правами доступа, сверкой, лимитами, отчетностью или данными в реальном времени. Чем больше этой логики принадлежит продукту, тем больше инженерных работ переносится с видимого интерфейса на базовую систему.
Это типично для разработки финансового ПО, особенно в банковских продуктах, которые также требуют инфраструктуры счетов, обработки транзакций, логики реестров, рабочих процессов KYC, интеграций, бэк-офисного функционала и мер безопасности.
Сторонние интеграции
FinTech-продукты обычно зависят от банков, платежных процессоров, провайдеров KYC, бухгалтерских систем, кредитных бюро, брокеров и других внешних сервисов.
Каждый провайдер имеет свою модель аутентификации, структуры данных, лимиты API, правила синхронизации и сценарии сбоев. Это делает интеграцию чем-то большим, чем просто API-соединение: она также включает тестирование, мониторинг и обработку ошибок.
Требования к безопасности и комплаенсу
Безопасность и комплаенс часто увеличивают стоимость разработки FinTech-продуктов, поскольку они влияют на архитектуру, логику бэкенда, инфраструктуру, тестирование и документацию.
Приложение для личных финансов обычно имеет более узкую область безопасности, сосредоточенную на аутентификации, шифровании и контроле доступа. Платежные или банковские продукты обычно требуют подробных журналов аудита, контроля мошенничества, тестирования на проникновение, мониторинга транзакций и регуляторной отчетности.
Чем раньше вы определите эти требования, тем точнее сможете включить их в первоначальную оценку. Если вы добавите их позже, вам придется менять архитектуру, рабочие процессы или инфраструктуру, которые уже были реализованы.
Для платежных продуктов планирование также зависит от того, как обрабатываются данные платежных счетов и какие требования PCI DSS применяются.
Обработка в реальном времени и масштабируемость
Балансы в реальном времени, платежи, торговые ленты, решения по мошенничеству и оповещения о транзакциях требуют инфраструктуры, способной обрабатывать обновления непрерывно, а не посредством периодической синхронизации. По мере роста объемов транзакций те же требования распространяются на проектирование баз данных, параллелизм, мониторинг, восстановление и отказоустойчивость.
Определите ожидаемые объемы транзакций и время отклика до оценки архитектуры, так как они могут повлиять на технический подход, а не только на объем необходимой инфраструктуры в будущем.
Функциональность бэк-офиса
Клиентское приложение — это лишь одна из многих частей FinTech-продуктов. Те же финансовые рабочие процессы часто требуют операционной стороны, где внутренние команды могут проверять транзакции, управлять клиентами и лимитами, разрешать споры, обрабатывать кредиты или претензии, а также выполнять задачи по соблюдению нормативных требований или поддержке.
Эта функциональность может никогда не появиться в мобильном интерфейсе, но она может составлять значительную часть объема разработки.
Разработка для iOS, Android или кроссплатформенная разработка
Поддержка как iOS, так и Android увеличивает объем работ, когда продукт требует двух отдельных нативных приложений.
Кроссплатформенная разработка может сократить дублирование работы над фронтендом, когда обе платформы разделяют большинство рабочих процессов и пользовательского интерфейса. Нативная разработка имеет смысл, когда продукт зависит от специфических функций платформы, производительности или доступа к оборудованию.
Объем задач по ИИ и готовность данных
Стоимость функции ИИ зависит от уровня кастомизации и данных, лежащих в ее основе. Готовая модель, подключенная к структурированным данным продукта, требует меньше инженерных усилий, чем кастомная модель, для которой нужны проприетарные конвейеры данных, оценка, переобучение, мониторинг и логика обработки сбоев.
Оценивайте готовность данных параллельно с моделью, так как дополнительный сбор, очистка или преобразование могут существенно расширить объем работ.
Самый большой разрыв обычно возникает из-за работы, которую трудно точно оценить на этапе планирования. Внешние сервисы на практике могут вести себя иначе, чем предполагает их документация, что добавляет усилий по интеграции, в то время как требования по соблюдению нормативных актов также могут потребовать больше работы, чем ожидалось. Миграция устаревших данных — еще один распространенный источник дополнительных расходов, особенно когда качество или структура существующих данных становятся понятными только во время реализации.
Что должна включать оценка разработки FinTech-приложения?
Реалистичная оценка охватывает весь процесс поставки, а не только написание кода фронтенда.
Как только эти области определены, команда может оценить объем проекта и стоимость вокруг полных финансовых рабочих процессов, а не отдельных экранов. Это особенно важно для интеграций, где одно, казалось бы, простое действие пользователя может затрагивать несколько бэкенд-систем и внешних провайдеров.
Оценка также должна разделять расходы на разработку и периодические сторонние расходы. В противном случае продукт может уложиться в инженерный бюджет, но все равно стать дорогим в эксплуатации из-за комиссий провайдеров, инфраструктуры, объемов транзакций и текущей поддержки.
Практическое правило оценки FinTech
Одно из практических правил — оценивать финансовый рабочий процесс до интерфейса. Например, «совершить перевод» может выглядеть как один простой экран. Тем не менее, это действие может включать аутентификацию, проверку получателя, лимиты транзакций, связь с провайдером, отслеживание статуса, сверку, уведомления, восстановление после ошибок, логирование и инструменты поддержки.
Чем больше таких рабочих процессов продукт должен обрабатывать самостоятельно, тем больше инженерной работы стоит за этим единственным экраном. Вот почему приложения с похожими интерфейсами могут требовать совершенно разных бюджетов.
Оцените стоимость вашей команды разработки FinTech
Используйте наш калькулятор, чтобы оценить стоимость команды разработчиков на основе необходимого опыта и продолжительности проекта.
Первоначальная оценка охватывает работу, необходимую для создания и выпуска продукта, но она не отражает полную стоимость владения. Как только приложение переходит в стадию эксплуатации, комиссии провайдеров, инфраструктура, работа по безопасности, обслуживание и изменения в интеграциях также начинают влиять на бюджет.
Сторонние сервисы
Сторонние интеграции влияют на бюджет дважды: сначала во время разработки, а затем во время эксплуатации. Платежные шлюзы, KYC-сервисы, банковские API, провайдеры рыночных данных, сервисы обнаружения мошенничества, платформы обмена сообщениями и инструменты аналитики могут использовать плату за настройку, подписки или ценообразование на основе использования, транзакций и объемов.
При выборе сторонних сервисов оценивайте эти периодические расходы в сравнении с ожидаемыми объемами транзакций и пользователей.
Оценки безопасности и устранение уязвимостей
Средства контроля безопасности обычно являются частью первоначального объема разработки, но некоторые расходы на безопасность появляются ближе к выпуску или после того, как продукт уже запущен.
Тестирование на проникновение, внешние аудиты, устранение уязвимостей, дополнительный мониторинг или изменения, требуемые после проверки безопасности, могут создать дополнительный объем работы. Определение ожидаемого объема безопасности и нормативных требований на раннем этапе упрощает включение этих расходов в бюджет, вместо того чтобы рассматривать их как неожиданные расходы после разработки.
Облачная инфраструктура
Производственная инфраструктура включает вычислительные ресурсы, базы данных, хранилище, сеть, логирование, мониторинг, резервное копирование, аварийное восстановление и отдельные среды разработки или тестирования.
При небольших объемах эти расходы могут оставаться относительно ограниченными. Однако по мере роста продукта неэффективное использование ресурсов и более сложная настройка облачной инфраструктуры могут сделать расходы на облако гораздо большей частью операционного бюджета.
Расходы на облако могут стать скрытыми расходами после запуска. Подробнее о расходах на облачную инфраструктуру
Обслуживание и внешние изменения
FinTech-продукты продолжают зависеть от систем, которые меняются после запуска, включая мобильные платформы, финансовые API, требования к платежам и сторонние библиотеки. По мере развития этих внешних компонентов продукту могут потребоваться обновления совместимости, корректировки провайдеров, дополнительное тестирование, мониторинг или исправление ошибок.
Поэтому обслуживание следует планировать как периодические инженерные расходы, а не как работу, которая начинается только тогда, когда что-то ломается.
Переработка интеграций
Внешние интеграции могут оставаться источником неопределенности даже после начала реализации. API может вести себя иначе в продакшене, чем в песочнице, крайние случаи могут проявиться только при реальных транзакционных нагрузках, или сторонний поставщик услуг может изменить свои требования к API или интеграции во время разработки.
По этой причине бюджет на интеграцию должен включать время на тестирование и исправление, а не предполагать, что каждый внешний сервис будет вести себя в точности так, как предполагает его документация.
Оценка чаще всего пересматривается, когда новые требования появляются уже после начала разработки. Дополнительные журналы аудита, специфические для комплаенса правила борьбы с мошенничеством или потребности в отчетности могут всплыть, если они не были полностью изучены во время этапа Discovery. Как только эти требования влияют на существующие рабочие процессы или архитектуру, они добавляют работу по реализации и могут вывести бюджет за рамки первоначальной оценки.
От MVP до производственного FinTech-продукта: Melio
SoftTeco работала вместе с командой разработчиков Melio по мере расширения их B2B-платежной платформы за пределы первоначального MVP. Наша работа включала многофакторную аутентификацию, интеграции с QuickBooks Online и Xero, улучшения существующей интеграции с QuickBooks Desktop и дополнительную функциональность аналитики.
По мере развития продукта эти области требовали различных видов инженерных работ, а не формирования одной «платежной функции». Для бюджетного планирования проект показывает, почему функциональность платежей, бухгалтерские интеграции, безопасность, аналитика и работа с существующей кодовой базой могут стать отдельными потоками разработки по мере роста FinTech-продукта.
Как этапы разработки влияют на бюджет
Этапы разработки важны для составления бюджета, поскольку ранние решения определяют объем последующей переработки, интеграционных усилий и тестирования.
1. Исследование и определение объема работ
Этап исследования определяет границы первого релиза: целевых пользователей, основные финансовые рабочие процессы, платформы, интеграции и рынки.
Это также самый недорогой этап для удаления малоценного функционала. Как только другие рабочие процессы или системы начинают зависеть от функции, ее изменение или удаление может потребовать дополнительного редизайна и разработки.
2. Архитектура и проектирование продукта
Как только объем работ ясен, его необходимо перевести в структуру системы, потоки данных, правила доступа, инфраструктуру, внешние зависимости и пользовательские интерфейсы.
Архитектурные решения, принятые на этом этапе, определяют большую часть последующей работы над бэкендом, интеграциями, безопасностью и инфраструктурой. Более сложная техническая база обычно означает больший объем реализации.
3. Разработка и интеграции
Во время разработки запланированные рабочие процессы превращаются в функциональность фронтенда и бэкенда, API, финансовую логику и административные инструменты.
Объем работы зависит не только от количества функций, но и от того, сколько провайдеров, ролей пользователей, путей транзакций и исключительных сценариев включает в себя каждый рабочий процесс. Интеграции с внешними финансовыми сервисами могут добавить дополнительную работу по реализации и тестированию.
4. QA и тестирование безопасности
Тестирование охватывает не только проверку того, работают ли отдельные функции должным образом. Финансовые рабочие процессы также должны корректно функционировать при интеграциях, на поддерживаемых платформах, в граничных случаях, при различных условиях производительности и сценариях сбоев.
Чем больше в продукте путей транзакций, внешних сервисов и операций, чувствительных к безопасности, тем шире становится объем тестирования перед релизом.
5. Запуск и пост-релизная разработка
Запуск не завершает бюджет на разработку. Мониторинг продакшена, инфраструктура, исправление ошибок, обновления зависимостей, смена провайдеров и новый функционал продолжаются после релиза и становятся регулярными расходами. Вот почему бюджет, который заканчивается в день запуска, занижает фактическую стоимость поддержки финансового продукта.
6 практических шагов по снижению стоимости FinTech-приложения
Оптимизация затрат позволяет сократить ненужный объем работ без ущерба для безопасности или инженерных практик, которые поддерживают продукт в рабочем состоянии.
1. Начните с одного полноценного финансового рабочего процесса
Хороший MVP доказывает основную бизнес-гипотезу, а не воспроизводит конечную платформу.
Вы можете запустить онбординг и один платежный рабочий процесс, прежде чем добавлять несколько способов оплаты, расширенную аналитику, инвестиционный функционал или выходить на несколько географических рынков.
2. Ограничьте начальные интеграции
Начните с интеграций, необходимых для основного рабочего процесса, и добавляйте банковские, KYC, платежные, аналитические сервисы или сервисы рыночных данных только тогда, когда продукт действительно в них нуждается.
Это сокращает как первоначальный объем работ по реализации, так и количество внешних зависимостей, которые команда должна поддерживать.
