Build vs buy, price the switching cost

A vendor that saves six months at launch can add eighteen months to a migration when identities, audit logs, configuration, and deployment workflows sit behind proprietary controls. The first invoice does not show that cost. It appears later through blocked roadmap changes, forced rewrites, and commercial terms that no longer fit the business. A platform that looks inexpensive during procurement becomes expensive when each product change needs vendor approval, paid services, or schema workarounds, and the purchase price becomes a small part of the operating cost.

Build versus buy software decisions are often scored on feature coverage, delivery speed, and first-year engineering cost. Those inputs matter for peripheral tools, but they are incomplete for core systems, AI platforms, and customer-facing infrastructure. A serious framework prices four factors before contract signature, exit path, modularity, runtime ownership, and upgrade discipline. These factors determine whether the system stays operable after launch and whether the company can replace it when business needs change.

The decision must be treated as an architecture decision, a financial decision, and an operating decision at once. Procurement alone cannot judge the long-term cost of a system that touches identity, revenue, customer data, or production workflow. Our work in technical due diligence starts here, since engineering, security, finance, and legal each own part of the answer.

The durable cost is switching cost

The conventional build vs buy decision starts with license fees compared against internal build cost. That frame works for commodity tools, but it fails for systems that become part of product architecture. A CRM used by twelve sales representatives has one risk profile. An identity provider, payment workflow, AI inference platform, or customer analytics layer used in every product journey has another, since the second category changes how the product is built, deployed, secured, and monitored.

How a cheap first invoice turns into long-term switching cost and operating burden — A low upfront vendor price compounds into slower roadmaps, costly migration, and rising operating cost over time.

The board-level question is whether the organization can leave the vendor without suspending product development for two quarters. Custom builds carry their own failure rate. Standish Group CHAOS data has shown that only about a third of software projects arrive on time, on budget, and with the agreed scope, and that small projects succeed far more often than large ones. Build and buy both create waste when the decision model is shallow. A weak build decision creates long-running engineering projects with unclear ownership, and a weak buy decision creates vendor dependence that grows with every product release.

The highest-cost cases occur when vendor economics and product architecture become inseparable. At that point, renewal negotiations turn into architecture meetings, finance asks about price, and engineering answers with migration risk, data ownership, and rewrite timelines. Switching cost becomes durable because it compounds across teams. Product managers adjust roadmaps around vendor limits, engineers add adapters to compensate for missing features, security teams accept audit gaps because replacement work would consume a quarter, and finance teams lose price control when product traffic grows faster than contracted usage bands.

These costs do not appear as one line item. They surface as delayed launches, longer incident response, duplicate data pipelines, and extra headcount for vendor administration. A four hundred thousand dollar annual license can create over a million in labor cost when six engineers spend half their year maintaining workarounds. The right decision treats switching cost as an operating expense, while the wrong decision treats it as a future project, and in production systems future projects become roadblocks when growth, regulation, or product strategy changes.

Switching cost also changes managerial behavior. Teams stop asking which architecture best serves the product and start asking which change the vendor supports this quarter. A checkout team delays a pricing experiment because the billing provider cannot support the required entitlement model, and a data team builds a second reporting pipeline because the vendor export excludes deleted records. The cost compounds again during renewal, since a vendor with deep runtime and data control negotiates from a strong position while the customer enters the meeting with migration risk, incomplete export tests, and a calendar constraint.

The executive team needs this risk stated in numbers. The decision record should include a forced migration scenario, a staffing estimate, and a downtime assumption, and it should state which product releases would pause during replacement.

Four variables belong in every decision framework

Exit path

An exit path is the documented process for moving away from a vendor without rebuilding the product from first principles. It covers data export, identity migration, configuration transfer, operational continuity, and customer impact, and it defines the work sequence during a planned migration. The contract should specify bulk export formats for users, roles, keys, audit logs, metadata, permissions, and configuration. CSV exports are inadequate for complex systems because relationships, event histories, and access policies carry business meaning, so JSON, Parquet, SQL dumps, OpenAPI specifications, and documented webhook replay procedures are stronger signals.

Free tiers deserve the same review as enterprise contracts. A plan that supports a million monthly active users can be a rational launch choice, yet it becomes a material risk when the organization lacks a tested migration path for identities, secrets, audit history, and access control policies. A serious exit path includes a staging test before production adoption. The team should export production-shaped data, load it into a replacement environment, and verify record counts, permissions, timestamps, and event ordering, because a vendor promise without a tested export is a sales statement, not an operating control.

The test should include failure handling. If export jobs time out at ten million rows, the team needs pagination rules, retry behavior, and support escalation terms, and if audit logs expire after thirty days, the architecture needs a separate retention path before customer or regulator requirements create exposure. Exit planning should also cover sequencing, since identity migrations often require parallel login, user mapping, token invalidation, and customer communication, and payment migrations require reconciliation, duplicate-charge controls, and a rollback process for failed authorizations.

The exit plan should name the data owner, the technical owner, and the executive owner. It should define which systems run in parallel, which customer segments move first, and the maximum acceptable outage window, even when the target is zero downtime. For a Tier 1 system the dry run should use at least one full production-like tenant, and the team should measure export time, import time, validation failures, and manual correction effort. That dry run should produce a migration ledger recording source counts, target counts, skipped records, transformed fields, and unresolved exceptions, an artifact that becomes evidence for security, finance, and customer-facing teams.

Exit planning must include secrets and credentials. API keys, OAuth clients, signing certificates, webhooks, and service accounts often live outside the main data model, and missing credentials during cutover create outages that do not appear in data migration estimates. Teams should also test audit continuity, because a regulator, enterprise customer, or incident investigator often needs records across the old and new platforms, so the migration plan should preserve timestamps, actor identifiers, IP addresses, and administrative actions.

Modularity

Modularity measures whether a vendor can be isolated behind a stable internal interface. A payment provider behind a PaymentService boundary is easier to replace than a platform that owns checkout, subscription state, invoices, entitlements, and customer communications in one proprietary workflow, since the boundary determines how much product code changes during replacement. Engineering leaders should prefer composable libraries and narrowly scoped services when the product domain will change. Libraries such as React Hook Form, LangChain components, or dbt packages can be removed with bounded work, while opinionated platforms that own the data model, workflow engine, deployment path, and UI layer create larger switching costs.

A useful test is direct, can the team replace the vendor component without changing the customer-facing contract or the internal domain model. If the answer is no, the decision is a long-term product architecture bet, and that bet belongs in the architecture record, not only in the procurement file. The boundary should be visible in code, since a vendor SDK imported across forty services creates a distributed dependency that is difficult to remove, while a single internal service that wraps the SDK gives the team a controlled replacement point. The same rule applies to data, because if the vendor stores the canonical customer, subscription, or entitlement record, the organization has ceded part of its domain model, and a nightly export to the warehouse does not restore control when operational systems still read from the vendor source.

Modularity also affects testing. A clean boundary lets teams create contract tests, replay production events, and run a second provider in shadow mode, while a weak boundary forces teams to test vendor behavior through end-to-end flows, which slows releases and increases regression risk. Architecture reviews should inspect import graphs, data lineage, and workflow ownership, counting direct SDK imports, vendor-specific database fields, and UI components tied to the provider so executives get a measurable view of lock-in before signature. The same review should define approved dependency patterns, where direct SDK calls from product services are exceptions with named owners and shared libraries expose domain methods, not vendor nouns.

Product code should call createSubscription() against an internal service, not stripe.subscriptions.create() from five applications, because that distinction cuts migration scope when the replacement sits behind one domain contract. Modularity also requires ownership of identifiers, so customer IDs, account IDs, subscription IDs, and entitlement IDs should exist in the company’s domain model with vendor identifiers stored as external references. Teams should track vendor-specific objects in schema review, since a field named vendor_plan_id in a mapping table is expected while a field named stripe_plan_id spread through entitlement, invoice, and analytics tables signals deeper coupling.

Runtime ownership

Runtime ownership defines who operates the production system. It includes deployment, storage, observability, incident response, backup, recovery, security patching, and capacity planning, and it defines who carries customer risk during an outage. Some vendors own the full runtime, and others sell a development interface and leave the customer to assemble Kubernetes, Postgres, Redis, CI/CD, secrets, logging, and alerting, a model that is valid only when the operating cost is priced. The vendor demonstration should show a full lifecycle, schema creation, service deployment, production URL, rollback, log inspection, metric alert, backup restore, and version upgrade, because a demo limited to local development does not prove production readiness.

An architecture review that tests runtime ownership turns those claims into contract-level specificity. The agreement should state who wakes up at 02:00 UTC, who owns recovery time, and who signs off on post-incident remediation. Runtime ownership also determines staffing, since a vendor-managed service with clear SLOs can reduce internal on-call load, while a self-hosted platform on Amazon EKS or Google Kubernetes Engine requires engineers who understand cluster upgrades, ingress, persistent volumes, secrets, and network policy. Finance should price those skills directly, because a senior platform engineer in a North American market often costs well over two hundred thousand dollars a year fully loaded, and a tool that appears cheaper than a managed service can exceed it once on-call coverage, incident reviews, and patch windows are included.

Runtime ownership needs a runbook, not a slide. The runbook should cover alert thresholds, escalation paths, customer communication, restore steps, and authority for emergency changes, and it should define who reviews incidents and who funds remediation work. Observability should use the company’s standard tools, since Datadog, Grafana, CloudWatch, OpenTelemetry, and Splunk all support production operations when teams set them up with clear labels and ownership, while a vendor dashboard alone is insufficient when incidents cross application, network, database, and identity boundaries. The runbook should include failure classes, because authentication outage, regional degradation, delayed webhook delivery, data corruption, and failed backup restore require different responses, and a single contact-support entry does not meet production standards.

Runtime ownership also includes access control, so the company needs named administrators, break-glass accounts, approval paths, and audit records, since shared vendor logins create security gaps and block incident reconstruction. Backup ownership needs the same detail, and the decision record should specify backup frequency, retention length, encryption model, restore testing, and recovery point objective, because a backup policy without a restore test is an assumption. Capacity planning belongs here too, since if usage triples in six months the team needs clear limits for throughput, storage, API rate, queue depth, and connection count, and the vendor should state how upgrades occur and how much notice is required.

Upgrade discipline

Upgrade discipline measures how the vendor handles version changes, deprecations, migrations, and backward compatibility. This matters most for AI platforms, workflow engines, data infrastructure, and developer platforms, since these systems sit close to product delivery and release operations. The review should include API versioning policy, deprecation windows, semantic versioning practices, database migration rules, and support timelines. Kubernetes, for example, moved to a release cadence of roughly three minor versions per year, and managed cloud providers enforce upgrade windows, so a vendor built on Kubernetes without a documented upgrade path transfers that burden to the customer.

Upgrade risk is concrete. A vendor that changes an embedding model, prompt orchestration API, authentication flow, or billing event schema can force product teams to pause roadmap work for remediation, and the impact increases when the vendor sits on the transaction path. The vendor should provide release notes with schema changes, breaking-change labels, test environments, and rollback procedures, because a ninety-day deprecation window gives teams time to plan while a fourteen-day notice for an authentication or billing change creates operational risk for any production system. Internal teams need upgrade discipline as well, since building in-house does not eliminate version risk, it moves that risk to the organization’s release process, dependency management, test coverage, and runbook quality.

Upgrade discipline should be audited during vendor review. Ask for the last three breaking changes, the customer notice provided, and the migration guide shipped with each change, because a vendor with disciplined releases can produce that evidence in a single review session. The company should also test upgrades before launch by creating a staging environment, applying a version change, running contract tests, and executing rollback, work that exposes brittle assumptions before customers depend on the system. The review should include dependency support, since vendors often depend on Node.js, Python, Java, Postgres, Redis, Elasticsearch, or Kubernetes versions, and when those dependencies reach end of support the customer inherits security and operating risk.

Upgrade discipline also affects release calendars, because a vendor-mandated migration during a peak sales period can interrupt revenue work, so the contract should define blackout periods and emergency exception handling. Teams should document compatibility layers, since an internal API that normalizes vendor changes can reduce product breakage, though the layer still needs tests, owners, and a deprecation policy. A disciplined upgrade process leaves evidence such as migration scripts, rollback logs, test failures, customer notices, and support response records, and vendor confidence without artifacts does not support a Tier 1 purchase.

A decision matrix for exit-safe architecture

A build vs buy decision should pass through gates before procurement approval. The following matrix is designed for core systems, AI platforms, customer-facing infrastructure, and any tool that holds customer or operational data, and each gate should have evidence attached to the decision record.

Gate	Evidence required	Buy signal	Build signal	Hybrid signal
Exit path	Documented export of data, identities, logs, config, and secrets	Strong export APIs and contract rights	Data model is unique or regulated	Buy interface, own canonical data
Modularity	Internal boundary, adapter design, replaceable component	Narrow vendor scope	Vendor owns domain model	Vendor behind service boundary
Runtime ownership	Named owner for deploy, storage, monitoring, backup, incident response	Vendor owns production SLOs	Internal team has 24/7 operations skill	Managed runtime with internal observability
Upgrade discipline	Version policy, deprecation windows, migration tooling	Backward compatibility and long support windows	Change rate must be controlled	Vendor platform with internal compatibility layer
Economics at scale	Three-year total cost, migration cost, renewal risk	Predictable unit economics	Usage economics exceed build cost	Buy commodity layer, build differentiator

This matrix prevents a common error, scoring a vendor highly because it satisfies most current features while ignoring the small share that controls future change. The most dangerous features are often administrative, and customers rarely see them until migrations, incidents, audits, or renewals expose the weakness. A vendor can pass feature review and fail architecture review, and that failure should stop the purchase for any Tier 1 system, meaning identity, payments, order management, customer data, authorization, and revenue reporting.

Gate flow deciding whether a vendor is safe for a Tier 1 core system — Each gate, from planned exit to predictable upgrades, must pass before a vendor earns approval for core systems.

The matrix works best when each cell requires evidence. A procurement answer that says export is supported is incomplete, since the review needs file formats, rate limits, retention periods, contractual rights, and a successful test export. The result should be a written architecture decision record naming the selected path, rejected paths, boundary design, data ownership model, runtime owner, and exit sequence, so future teams have the context they need when renewal, migration, or incident response begins. The record should also include a date for re-review, because vendor risk changes as usage grows, products expand, and regulations change, and a tool approved for a pilot can become inappropriate when it becomes a system of record for three regions.

For executive review the matrix should fit on one page, with supporting evidence in an appendix, and the board discussion should focus on reversibility, operating cost, and product control. The matrix should also use decision thresholds, so a Tier 1 system requires a tested export, a named runtime owner, and a ninety-day deprecation commitment, while a Tier 3 workflow tool can pass with lighter evidence. Tiering makes the process faster, since identity, payments, authorization, billing, customer data, and revenue reporting belong in the highest tier, and internal survey tools, design utilities, and low-risk collaboration tools belong in lower tiers.

The matrix should be reviewed by the architecture council or an equivalent technical governance group. A thirty-minute review before signature is cheaper than a six-month migration after renewal pressure, and it should produce a written approve, reject, or approve-with-controls decision. A strong matrix also separates launch risk from lifetime risk, where launch risk covers integration effort, training, and early adoption, and lifetime risk covers exit cost, upgrade burden, data ownership, and renewal exposure.

AI platforms require a stricter exit model

AI systems add three forms of lock-in, model behavior, data artifacts, and evaluation history. A model provider can be changed through an API adapter, but a production AI system is harder to move when prompts, retrieval pipelines, embeddings, feedback labels, safety rules, and evaluation datasets are tied to one platform. Market signals point to heavier buying in AI while the payoff stays uneven. MIT’s Project NANDA reported that about 95 percent of enterprise AI pilots delivered no measurable profit-and-loss impact, which supports buying commodity infrastructure with strict controls around product-specific data and logic.

Model hosting, inference endpoints, and baseline orchestration can be purchased when the exit path is clear, while prompts, evaluation data, routing policy, and customer-specific logic should stay under company control. The build vs buy discussion is also changing because agentic systems can generate and modify workflow logic. The academic paper The Buy-or-Build Decision, Revisited examines how agentic AI reshapes cost, asset specificity, and vendor lock-in in enterprise software, and the engineering implication is direct, since generated code still needs ownership, review, deployment, monitoring, and rollback.

Cross-functional review where engineering, finance, and legal gate an AI platform purchase — Engineering, finance, and legal each attach evidence to the architecture council before an AI platform earns contractual approval.

For an AI platform the exit checklist should include prompt templates, conversation transcripts, evaluation datasets, retrieval documents, vector indexes, embedding model metadata, feedback labels, guardrail rules, and model routing policies. If embeddings move from 1,536 to 3,072 dimensions, reindexing cost must be priced before adoption, including compute, storage, validation, and regression testing. A defensible architecture keeps product logic outside the vendor console, so store prompts in version control and keep evaluation datasets in the company’s data platform. Route model calls through an internal service that records inputs, outputs, latency, token cost, and model version, since that service becomes the control point for model replacement, cost reporting, safety review, and a consistent audit trail across vendors.

Vector stores require special attention. A retrieval system built on Pinecone, Weaviate, OpenSearch, or pgvector should have a documented export path for source documents, chunking rules, embeddings, metadata, and index configuration, and rebuilding an index from source is acceptable only when source data, model versions, and chunk IDs remain available. Evaluation history is part of the product record, so if a support agent, underwriting assistant, or clinical documentation tool changes models, the team needs before-and-after results on the same test set, because without that record leaders cannot distinguish improvement from regression. AI vendors also change behavior without changing customer code, since a model update can alter tone, refusal behavior, citation style, extraction accuracy, and latency, so production AI systems need canary tests and fixed evaluation suites before provider changes reach customers.

The company should store model outputs tied to version, prompt, retrieval context, and user segment, a record that supports audits, incident investigations, and vendor comparison during renewal. AI systems also create data-retention questions that standard SaaS reviews miss, since prompt logs can contain customer data, employee data, source code, or regulated records, so the vendor contract should state retention length, training use, deletion process, and access controls. Retrieval pipelines need ownership rules, where the company owns source documents, chunking method, metadata schema, and access filters, because a vendor-owned retrieval configuration can make a later provider change expensive and hard to validate. Guardrails require the same treatment, so safety rules, refusal policies, allow lists, block lists, and escalation paths should live in company-controlled repositories and be exported and reviewed like code.

AI cost control also depends on architecture. Token usage, cache hit rate, embedding refresh frequency, and routing policy affect gross margin, so the internal model gateway should report those numbers by product, tenant, and feature. Vendor replacement should be tested with real evaluation cases before launch, running the same prompts through two providers to compare latency, cost, accuracy, refusal behavior, and citation quality, with the result stored in the architecture decision record. Agentic systems raise another operating question, since an agent that can modify tickets, approve refunds, create records, or call internal APIs needs deterministic controls, so tool permissions, approval thresholds, audit logs, and rollback steps must be owned internally, and generated workflows require code review that matches the production risk of the action. Our AI vendor lock-in piece works through the model gateway and evaluation corpus in more depth.

Operability changes the CFO model

First-year license cost is a weak proxy for total cost. CFOs need a three-year model that includes switching cost, operating cost, and commercial concentration risk, and the model should use the same usage assumptions as the revenue forecast. A useful model has seven lines.

Initial license or build cost
Internal engineering cost for integration
Runtime operations cost
Vendor administration cost
Upgrade and migration cost
Exit cost under a forced migration scenario
Renewal exposure at 2x, 3x, and 5x usage growth

Integration and maintenance costs routinely run well above the headline license fee, so treat any published benchmark as directional and replace it with company-specific numbers during vendor diligence.

How operating cost expands software spend from license fee to three-year CFO model — A three-year CFO model adds integration, runtime, administration, upgrade, and exit cost on top of the license fee.

Migration timelines should be explicit. A Tier 2 workflow system should have a credible ninety to one hundred eighty day exit plan, while a system of record, identity platform, or payments architecture can require six to twelve months, including parallel run, reconciliation, customer communication, and audit review. The useful addition for CFOs is scenario pricing, so model the cost of staying, scaling, and leaving. The staying scenario should include annual license increases, professional services, premium support, and extra administrator seats. The scaling scenario should include transaction growth, storage growth, API call volume, and data retention. The leaving scenario should include duplicate run cost, migration engineering, customer support, legal review, and vendor termination assistance.

This model changes vendor negotiation. A company with a tested exit plan negotiates from a stronger position because renewal is not the only viable path, while a company with no exit plan turns a commercial discussion into a forced extension. CFOs should also price concentration risk, since if one vendor controls identity, authorization, billing triggers, and customer communications, the company has a single commercial choke point, and renewal exposure then affects gross margin, product delivery, and customer commitments.

The finance model should include named internal roles, because engineering time, security review, data work, and legal support all carry cost, and a migration that uses four engineers, one data engineer, one security architect, and outside counsel for six months is a capital allocation decision. The model should also include opportunity cost, since if eight engineers spend a quarter on migration, those engineers are not shipping product work, and the roadmap delay has financial value that should be visible in the decision. Usage assumptions need the same rigor as revenue forecasts, because a per-transaction vendor can look inexpensive at launch and expensive at product-market fit, so the model should include unit economics at current volume and at planned volume.

Support tiers also need pricing, since many vendors reserve 24/7 response, named support engineers, and shorter response times for higher plans, and a production system that lacks production-grade support creates hidden risk. Finance should require a renewal stress test asking what happens if the vendor raises price by thirty percent, changes metric definitions, or removes discounts, with an answer that includes contractual protections and a migration alternative. Contract length also changes risk, since a three-year discount can be rational when exit rights, unit economics, and data control are strong, while a long contract without tested reversibility transfers too much control to the vendor.

The contract should encode the architecture

Procurement terms often trail the architecture decision, and that order creates risk. The contract should reflect how the system will run in production and how the company will leave. For core systems the contract should include five technical clauses.

Data export rights, including format, frequency, and support for bulk extraction
Audit log retention and export, including administrator actions and security events
Configuration export, including roles, workflows, policy rules, and environment settings
Termination assistance, including named support levels and time windows
Version and deprecation commitments, including minimum notice periods

How the architecture decision record drives the contract clauses needed for production approval — Export, retention, termination, and version clauses flow from the architecture record into the terms that gate production.

Engineering should attach an architecture decision record to the vendor approval, stating the boundary, data ownership model, runtime owner, failure modes, and exit plan, and identifying assumptions that require contract language. For production-ready software this is standard discipline, since a vendor decision without an architecture decision record is incomplete for systems that touch revenue, customer data, security, or product workflows, and the approval package should show both commercial fit and production fit. Legal teams should review the same technical assumptions, because a contract that grants data export rights after termination has limited value if the vendor can charge uncapped service fees, so a termination clause should define response times, named roles, data delivery windows, and dispute handling.

Security teams should review audit and retention terms before signature. If an incident occurs, the organization needs administrator actions, authentication events, IP addresses, role changes, and API activity, and a vendor that retains these records for thirty days cannot support a ninety-day forensic requirement. Architecture and contract language should match, so if the architecture assumes dual-run migration the contract must allow parallel operation during termination, and if the architecture assumes daily exports the agreement must define export frequency, format, and support obligations. The contract should also address subcontractors and data residency, since a vendor can pass the first review while relying on another provider for storage, support, analytics, or AI inference, and those dependencies affect breach response, data transfer, and service continuity.

Procurement should require evidence for each clause, including sample exports, API documentation, support runbooks, retention tables, and version policy documents, because a verbal assurance from an account team does not support production risk. The contract should define service credits with care, since credits rarely compensate for customer churn, missed billing, or broken workflows during an outage, so more important terms include response time, escalation path, remediation duty, and termination rights. Data use clauses need specific language, stating whether customer data, prompts, logs, or derived artifacts can train vendor models, and defining deletion, retention, and backup purge timelines.

The contract should cover administrative access, so vendor support personnel access customer environments through named accounts, approved roles, and audited sessions, because shared support access creates forensic and compliance risk. Change control belongs in the agreement for Tier 1 systems, where the vendor gives notice for material API, schema, authentication, billing, or security changes on a period that aligns with the company’s release process. The contract should also state cooperation duties during incident response, so the vendor provides logs, timelines, named responders, and remediation plans within defined windows, terms that security and engineering teams need before a live incident.

A practical checklist for the next vendor review

Use this checklist before signing a contract or adopting a free tier. It applies to commercial vendors, managed open-source services, and infrastructure components that hold customer or operational data, and it should be completed by engineering, security, finance, and legal together.