Build vs buy: фреймворк решения для продуктовых команд

Короткий ответ

Покупайте software, когда workflow является commodity, надёжный vendor уже решает задачу, выход остаётся возможным, а владение отвлечёт команду от дифференциации. Стройте, когда workflow формирует преимущество продукта, рынок не поддерживает нужные data или operating boundaries либо vendor constraints создают неприемлемый стратегический риск. Комбинируйте подходы, когда тонкий custom layer защищает differentiated decisions, а проверенные сервисы выполняют commodity-функции.

Сравнивать нужно не licence fee и development estimate, а весь lifecycle: discovery, implementation, integration, migration, security, compliance, support, change, vendor risk, staffing и exit. Зафиксируйте assumptions до vendor demo или архитектурного спора, оцените evidence и назначьте условия пересмотра.

Считайте build vs buy операционным решением

Feature comparison делает решение статичным. Software — это работающая система людей, data, vendors, controls и постоянных изменений.

Buy может означать:

• принять SaaS с configuration;
• лицензировать platform и интегрировать;
• использовать managed cloud capability;
• приобрести white-label product;
• передать полный business process.

Build может означать:

• создать proprietary product;
• расширить существующее application;
• построить internal workflow;
• собрать managed components за custom experience;
• создать integration и policy layer вокруг vendors.

Большинство сильных систем — портфели. Они покупают email delivery, payments, commodity observability и identity primitives, но строят rules, data models и experience, отличающие продукт. Главный вопрос — каким layer организация должна владеть.

Начните с outcome:

Если команда не может сформулировать outcome, она не готова выбирать solution.

Отделите commodity от дифференциации

Commodity capability не означает неважную. Authentication, payroll, email, storage и monitoring критичны. Они commodity, когда надёжные реализации широко доступны, а уникальная версия не усиливает продукт.

Differentiated capability влияет на то, почему клиент выбирает, остаётся, платит или получает лучший outcome:

• proprietary workflow или decision model;
• необычный latency, offline или device behaviour;
• уникальный data model или feedback loop;
• integration, которую сложно повторить;
• trust, privacy или compliance property в основе offer;
• operator experience, меняющий unit economics.

Не называйте differentiation любую внутреннюю preference. Custom dashboard не становится стратегическим из-за любимого layout. Спросите, создаёт ли ownership преимущество, которое переживёт maintenance cost.

Разложите систему:

Карта предотвращает дорогую середину: слабое копирование market product при сохранении зависимости от infrastructure vendors.

UK Technology Code of Practice акцентирует user needs, reuse, open standards, security и весь service. Документ создан для государственного контекста, но дисциплина шире: понять пользователя, не дублировать без необходимости, проектировать portability и оценивать service целиком.

Зафиксируйте non-negotiable constraints

Некоторые constraints исключают варианты до scoring.

Data и jurisdiction

Определите data classes, legal roles, storage regions, subprocessors, retention, deletion, export и breach obligations. Не принимайте «GDPR compliant» как полный ответ. Проверяйте реальный data flow и contract с квалифицированным counsel.

Security и authority

Нанесите authentication, authorization, tenant isolation, admin access, audit events, encryption, secrets, dependency management и vulnerability response. OWASP Application Security Verification Standard даёт структуру application control requirements. NIST Secure Software Development Framework — outcome-based practices для software, которое вы строите и поддерживаете.

Reliability и recovery

Определите uptime needs, recovery point/time, offline behaviour, dependency failures, backups и incident ownership. Vendor SLA не заменяет recovery design. Организации всё равно нужно понимать user experience и продолжение operations.

Integration

Проверьте APIs, webhooks, rate limits, idempotency, event ordering, sandboxes, version policy, bulk export и support escalation. Demo может выглядеть завершённым, оставаясь небезопасным для интеграции.

Platform и distribution

Mobile stores, browser constraints, enterprise device management, accessibility, payment policy и regional distribution влияют на допустимые решения. Проверяйте до договора или build.

Запишите constraints как pass/fail gates. Weighted score не должен скрывать critical violation.

Рассчитайте total cost of ownership

Видимая цена — один компонент.

Buy TCO

Включите:

• subscription/licence fees при реалистичном usage;
• implementation и configuration;
• integration и middleware;
• data migration и cleanup;
• identity, security и compliance review;
• vendor management и procurement;
• user training и change management;
• premium support;
• usage overages и currency exposure;
• price или packaging changes;
• exit migration и parallel operation.

Build TCO

Включите:

• product discovery и design;
• engineering, QA, security и accessibility;
• infrastructure и third-party services;
• data migration;
• deployment и release operations;
• monitoring, incident response и support;
• backups и disaster recovery;
• dependency/platform updates;
• будущие product changes;
• documentation и staff continuity;
• opportunity cost команды.

Используйте ranges и scenarios:

Review horizon должен охватывать несколько лет, а не один procurement cycle. Не обнуляйте затраты после горизонта: покажите residual obligations и exit cost.

Development quote без operation — не build TCO. SaaS price без implementation, integration и change — не buy TCO.

Сравните time-to-value и time-to-control

Buy часто даёт более быстрый доступ, но не обязательно value. Configuration, procurement, security review, migration, training и integration могут занять большую часть календаря.

Build начинается медленнее, но может ускорить изменения при частом развитии workflow и контроле приоритетов. Он останется медленным без product ownership и operational engineering.

Разделите время:

1. Time to first useful outcome: реальный user завершает core job.
2. Time to safe operation: готовы monitoring, permissions, recovery, support и ownership.
3. Time to meaningful change: срок нового requirement после launch.
4. Time to exit: срок replacement или shutdown.

Vendor demo оптимизирует восприятие первого числа. Хорошее решение оценивает все четыре.

Proof должен проверять самый трудный constraint, а не happy path. Для vendor протестируйте representative data, permissions, integration failures, export и support. Для custom software создайте vertical slice через risky workflow и production boundary.

Не сравнивайте mature SaaS demo с custom prototype. Сравнивайте ожидаемые production states на одной временной точке.

Оцените strategic и vendor risk

Vendor risk не повод строить всё. Internal teams тоже меняются, теряют knowledge, пропускают incidents и накапливают dependencies.

Buy risks:

• financial и operational viability;
• roadmap alignment;
• deprecation или acquisition;
• pricing/packaging control;
• data portability;
• API stability;
• subprocessor changes;
• security и incident transparency;
• support quality;
• contractual exit.

Build risks:

• product ownership capacity;
• technical leadership;
• hiring и continuity;
• scope expansion;
• security/operational maturity;
• dependency и cloud concentration;
• documentation и bus factor;
• maintenance budget.

Используйте evidence. Vendor security page не равна contractual controls или audit materials. Уверенность internal team не равна demonstrated production operation.

Создайте risk register:

Цифры не обещают математическую точность. Они помогают сравнивать и назначать ownership.

Спроектируйте hybrid architecture

Hybrid часто лучший ответ и часто плохо реализован. Тонкий custom layer сохраняет differentiation, vendors дают commodity capability.

Здоровые boundaries:

• domain model принадлежит продукту, а не копируется из vendor;
• adapter вокруг важного provider;
• стабильные internal events и identifiers;
• idempotent processing и explicit retries;
• export и reconciliation path;
• authorization enforced вашей системой;
• observability через vendor boundary;
• documented fallback или degraded mode.

Не абстрагируйте каждого provider до появления второго. Создавайте seams там, где strategic risk оправдывает стоимость. Adapter не устраняет dependence, но не даёт vendor concepts распространиться по application.

Twelve-Factor App остаётся полезным baseline для configuration, backing services, stateless processes, logs и environment parity. Применяйте принципы прагматично для portability и operability.

Configuration и integration купленного продукта остаются software assets. Версионируйте их, тестируйте, проверяйте permissions и назначайте owners. No-code не означает отсутствие engineering risk.

В custom product используйте managed commodity components, если они проходят constraints. Владение differentiated layer не требует собственного database engine, mail server или observability platform.

Используйте weighted decision matrix

Сначала gates, затем score:

Оценивайте от одного до пяти с evidence и confidence. Failed constraint нельзя спрятать в average. Data residency violation не компенсируется хорошим interface.

Рассмотрите минимум четыре варианта:

1. buy и configure;
2. buy плюс custom integration layer;
3. build differentiated workflow на managed components;
4. defer, simplify или remove capability.

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

Проведите sensitivity analysis. Если небольшое изменение weight меняет решение, evidence слабые или варианты близки. Выберите reversible experiment.

Зафиксируйте dissent. Minority concern о security, adoption или vendor exit может стать главным позже.

Определите contracts и exit заранее

Для vendor purchase проверьте:

• service description и availability commitments;
• support/escalation;
• data processing agreement и subprocessors;
• security obligations и incident notice;
• audit evidence;
• pricing protections и usage measurement;
• API/feature-change notice;
• export format и assistance;
• termination, deletion и transition;
• ownership configurations и derived data.

Для custom build:

• outcome и acceptance boundaries;
• intellectual-property treatment;
• repositories, cloud, domains, stores и analytics;
• open-source и pre-existing components;
• documentation и handover;
• security/privacy responsibilities;
• warranty и support;
• change control;
• termination и usable artifacts.

Legal advice зависит от jurisdiction и entities. Product team делает operating assumptions видимыми, чтобы counsel работал с реальной системой, а не generic template.

Проверьте exit, пока leverage высок. Попросите vendor показать export, а build partner — объяснить deploy другой командой. Credentials и production accounts должны быть под organizational control.

Примите решение через staged experiment

Этап 1: frame

Определите outcome, constraints, differentiation, users, owner, review horizon и non-goals.

Этап 2: market scan

Найдите credible vendor и managed-service options. Отказывайте по documented gates. Фиксируйте missing evidence.

Этап 3: comparable proof

Дайте shortlist одинаковые workflow, data, permission model, failure scenario и success criteria.

Этап 4: lifecycle model

Оцените TCO ranges, staffing, time-to-value, risks и exit. Включите hybrid и defer.

Этап 5: decision record

Запишите option, evidence, rejected alternatives, assumptions, dissent, owner и review triggers.

Этап 6: controlled commitment

Используйте pilot, milestone, limited contract term, feature flag или bounded release. Сохраняйте возможность остановиться без потери data и operational control.

Этап 7: review

Пересматривайте решение при изменении pricing, scale, regulation, product differentiation, team capacity или vendor behaviour. Build versus buy не навсегда.

Профессиональный ответ редко идеологичен. Покупайте то, что рынок безопасно предоставляет. Стройте то, что создаёт defensible value. В любом случае владейте boundaries, evidence и exit.