The build vs. buy decision record: why the make-or-buy choice is the hardest to document honestly

The build vs. buy decision is the single make-or-buy choice that engineering teams most reliably document with the wrong reason. Not no reason — teams usually write something. But the reasons they write are the defensible-sounding reasons, the ones that hold up in a postmortem, the ones that don't make anyone look like they made a decision for reasons of budget constraint or personal familiarity or organizational politics. The authentic constraints — the vendor's enterprise tier pricing at projected scale, the engineering team's confidence in their own implementation, the product organization's preference to own the capability — get compressed into "vendor lock-in concerns" and "need for customization" in the ADR that survives three years of team turnover.

This matters because the build vs. buy decision has a specific re-evaluation structure. It is not a static decision. Vendor markets mature. The startup that didn't offer a multi-tenant tier in 2022 may have shipped it in 2024. The authentication service that required an enterprise contract at 50k MAU may have introduced a transparent usage-based tier. The team that was three engineers in 2022 is now twelve engineers in 2026 and is maintaining a custom authentication implementation that was designed for three engineers to understand. The question of whether to migrate to a vendor solution comes back, and when it does, the critical input is: what was the actual constraint that drove the build decision? If the record says "vendor lock-in concerns," the re-evaluation team cannot answer the question. If the record says "Auth0's multi-tenant isolation model required enterprise tier at $1,800/month given our projected 50k MAU; we evaluated the self-hosted option and found it operationally expensive for a three-person team," the re-evaluation team can check: what does Auth0 cost today at 50k MAU? Has the multi-tenant isolation model improved? Has the operational burden of self-hosting changed?

The honest record is harder to write. It requires acknowledging constraints that make the decision look like a budget call or a confidence call rather than a principled engineering position. But the dishonest record — the one that sounds better at the moment it's written — is the document that fails in year three when the switching cost calculation requires knowing what was actually true at the moment of the original decision.

Three categories of build vs. buy decisions worth documenting

Not every capability choice produces a build-vs-buy decision worth recording as a formal ADR. A team that chooses to use a console.log wrapper instead of a logging library hasn't made a strategic capability decision. What produces a record-worthy build-vs-buy decision is the choice of a capability that the team will maintain for years, that produces ongoing work, that has vendor alternatives the team will continue to encounter in job candidates' resumes and blog posts, and where a new engineer could reasonably conclude that the internal implementation was an oversight rather than a decision.

Feature-level build-vs-buy. The team decides to build authentication, search, email sending, payment processing, or PDF generation rather than integrating a vendor solution. These are the most common and the most reliably underdocumented. The decisions are made early in a product's life, often by a small team, often under timeline pressure, and the resulting implementation becomes load-bearing infrastructure that the team maintains indefinitely. The new CTO who inherits a custom authentication implementation and asks "why aren't we using Auth0?" has a legitimate question — and the only complete answer is in the AI chat session where the original team evaluated Auth0, found the pricing unworkable, and decided to build. That session no longer exists anywhere except in the AI chat export of an engineer who may have left the company.

Capability-level build-vs-buy. The team decides to build monitoring infrastructure, a data pipeline, a feature flag system, a metrics collection layer, or an internal deployment tool rather than adopting a vendor platform. These decisions are often made as explicit "not yet" choices — "we'll use Datadog when we're bigger" — which means the ADR is a temporary build decision with an implicit future buy decision baked in. The problem is that the "not yet" condition is never written down. The team said "we'll use Datadog when we're at $50k MRR" and what got recorded was "built internal metrics aggregation — vendor solutions not yet cost-justified." The current team doesn't know whether $50k MRR was the threshold, whether that threshold was reached two years ago, or whether the decision to not switch at that threshold was itself a deliberate decision or just inertia. The "not yet" is a decision that needs a record as much as the affirmative choice does.

Platform-level build-vs-buy. The team decides to build a CRM, ERP component, or internal tooling platform rather than adopting a vendor system. These are the highest-stakes build-vs-buy decisions and the ones where the vendor market moves fastest. A team that evaluated Salesforce in 2019 and found it too heavyweight for a thirty-person company may be re-evaluating the same question in 2026 with a hundred-person company and a fundamentally different set of vendor options in the mid-market CRM space. The record from 2019 that says "Salesforce too heavyweight, insufficient customizability" is not useful for the 2026 re-evaluation. The record from 2019 that says "Salesforce Enterprise was $150/seat/month, which at thirty sales reps is $54k/year; we also evaluated HubSpot Pro which was $90/seat/month; both required annual contracts; the internal CRM covers our core contact management and deal stage workflow needs and was estimated at six weeks of one engineer's time" is at least a starting point.

The vendor evaluation spreadsheet problem

Most serious build-vs-buy decisions are preceded by a vendor evaluation. The team identifies the candidates, builds a comparison matrix, evaluates each against their requirements, and produces a recommendation. This evaluation contains the most valuable content for the eventual ADR: which vendors were considered, what their actual pricing was, which capabilities each vendor was missing for this team's specific requirements, and what the switching cost would have been had they chosen a different vendor.

The vendor evaluation also almost never survives more than eighteen months. It lives in a Google Sheet. The engineer who built it left and took the context with them. The Sheet is in a folder that was archived when the team reorganized. The comparison criteria that were used to rank the vendors are known only to the people who were in the evaluation meeting. The pricing that was current in 2022 is visible in the Sheet but there is no way to know whether the evaluation result would have been different at the 2024 pricing.

The build-vs-buy ADR is the document that should replace the vendor evaluation spreadsheet. Not by including the full matrix — the ADR is not a spreadsheet — but by capturing the three to five constraints that actually drove the decision. Which vendor was the leading candidate and why was it eliminated? What was the actual pricing at the relevant scale? What capability gap did every vendor solution share? What would the team have had to build even if they had chosen a vendor solution (custom integrations, data transformation, workflow automation) — i.e., what was the vendor actually buying them relative to building from scratch?

The AI chat sessions that contain the vendor evaluation are the source material for these constraints. An engineering team that evaluated three authentication vendors across four AI chat sessions produced session transcripts that contain the actual pricing discovered, the actual capability gaps encountered, the actual integration concerns raised, and the actual switching cost estimates made at the time. That content is in the WhyChose extractor's highest-confidence extraction category: multi-session vendor comparison threads with a final build decision. The sessions are identifiable through the comparison pattern (vendor names evaluated against requirements), the capability gap language ("Auth0 would need the enterprise tier for this"), and the outcome marker ("we'll build it ourselves").

The build decision cascade

A build-vs-buy decision that concludes with "we'll build it" does not produce one architectural decision. It produces many. The authentication system that the team built instead of Auth0 accumulated a JWT token format decision, a refresh token rotation strategy decision, a session invalidation mechanism decision, a multi-tenant isolation model decision, a password hashing algorithm decision, a rate limiting policy decision, and a MFA implementation decision — none of which necessarily have their own ADRs, because they were made as part of the implementation rather than as explicit architecture choices.

The build decision is the trunk. The implementation decisions are branches. The trunk ADR should acknowledge that it opens a cascade: "This decision to build our own authentication layer commits us to owning the following downstream decisions: token format, refresh rotation strategy, session storage, multi-tenant isolation model. See decisions/auth-0043 through auth-0047 for the implementation ADRs that follow from this choice." Without this linkage, the implementation decisions look disconnected from their origin in the build-vs-buy choice, and the build ADR looks more complete than it is.

The cascade has a specific re-evaluation implication. When the team considers migrating from the internal authentication system to a vendor, they are not just re-evaluating the original build decision. They are also evaluating the migration cost across every implementation decision that has accumulated since the build. The refresh token rotation behavior that was custom-designed for their session model needs to be mapped to the vendor's session model. The multi-tenant isolation model that was specific to their data architecture needs to be replicated in the vendor's tenant configuration. The vendor may not support every behavior the internal implementation has. The migration is a re-evaluation of the build decision plus a cost estimation of migrating every downstream implementation decision that has been made since — and that estimation is only possible if the downstream decisions are documented.

A build ADR that is superseded by a buy ADR should link to the migration record. The migration record explains which downstream implementation decisions had to be addressed, which vendor capabilities replaced which internal behaviors, and which internal behaviors had to be dropped or approximated. The chain of custody from original build decision through implementation decisions through migration record is the most complete picture of why the current architecture looks the way it does — and it is only available if the build ADR was written honestly enough to acknowledge the cascade it was opening.

The lock-in rationalization in detail

"Vendor lock-in concerns" is the most commonly cited reason in build-vs-buy ADRs, and the one most frequently cited for reasons that have nothing to do with lock-in. Vendor lock-in is a real risk — building deep integrations with a vendor's proprietary API surface, storing data in proprietary formats, training the team on vendor-specific tooling — but it is not the dominant constraint in most build decisions at early-stage companies. The dominant constraints are pricing, capability fit, team familiarity, and current engineering capacity. "Vendor lock-in" gets written in the record because it sounds like an engineering principle rather than a budget decision.

The test for whether vendor lock-in was the actual constraint: if the vendor had offered a standard API (REST, OpenAPI-specified), had stored data in portable formats (JSON, CSV export), and had provided a data portability guarantee — would the team have chosen to buy? In most cases where "vendor lock-in" is cited in an early-stage build ADR, the honest answer is "probably not at the pricing they were offering" or "probably not given the capability gaps we found." The lock-in concern was real but secondary. The pricing was the decision.

This matters for re-evaluation because a decision made under a false constraint re-evaluates incorrectly. A team that revisits the buy option in year three and finds that the vendor now offers a standard API and data portability will conclude that the lock-in concern has been addressed and that the buy option is now viable. But if the original constraint was actually pricing, the correct check is whether the pricing has changed to make the vendor viable at current scale — not whether the API has become more standard. The team re-evaluates against the documented constraint, not the actual constraint. If the documented constraint is wrong, the re-evaluation reaches the wrong conclusion.

The constraints worth documenting honestly in a build-vs-buy ADR are the specific ones that drove the decision at the time, including the ones that sound like organizational or budget constraints rather than engineering principles:

• Pricing at scale. "Auth0 Essentials is $240/month at 10k MAU; our projected 50k MAU in year one puts us in the $900/month range based on their published calculator; the enterprise tier with multi-tenant support is $1,800/month minimum contract." A new engineer in year three can check: what does Auth0 cost today at 50k MAU?
• Capability gap. "Auth0's Actions system supports our MFA bypass logic for enterprise SSO users, but our per-tenant session duration configuration requires enterprise tier and a custom Action that is documented as experimental." A new engineer can check: has this capability been promoted to stable?
• Integration complexity for this stack. "We evaluated the Auth0 Next.js SDK; the integration with our custom session store required monkeypatching the session handler in a way that breaks on Auth0 SDK minor version updates; the Clerk integration for the same stack was documented and stable." This is a team-specific constraint that is legitimate to document and legitimate to re-evaluate when the SDK matures.
• Team familiarity. "Two engineers on the team have prior experience implementing JWT-based auth; no one has production experience with Auth0 or Clerk; the build path was estimated as two weeks; the Auth0 integration was estimated as three weeks including reading documentation and configuring the tenant model." This is a time-of-decision constraint that will become irrelevant as the team grows and accumulates Auth0/Clerk experience — the re-evaluation should note that it no longer applies.
• Current capacity. "We have two engineers and are focused on shipping the core product feature set; the build path absorbs two weeks of one engineer's time as planned work; the buy path absorbs three weeks including integration, which requires a second engineer for parts of the tenant configuration; we chose the path that was one engineer's work." This is a constraint that is obviously temporary and obviously relevant — a team that is now twelve engineers has a completely different capacity calculation.

These constraints are more vulnerable-sounding than "vendor lock-in." They are also more accurate, more useful for re-evaluation, and more respectful of the engineer who reads the ADR in three years and needs to understand what the original team was actually thinking. The founder or early-stage CTO who makes these decisions under real budget and capacity pressure made legitimate decisions — the record should say so accurately, not translate the constraints into engineering principle language that is harder to verify and harder to update.

Writing the build vs. buy ADR

The Nygard ADR format applies directly to build-vs-buy decisions with one important adjustment: the Alternatives Considered section must name the specific vendors evaluated, not vendor categories. "We evaluated SaaS authentication providers" is not useful. "We evaluated Auth0 (Essentials and B2B SaaS plans), Clerk (Pro plan), and AWS Cognito (User Pools)" is useful.

The decision-statement title convention for build-vs-buy decisions uses the build verb and names the capability and the rejected alternative class:

• "Built internal authentication layer over Auth0/Clerk — multi-tenant pricing and integration complexity" — the capability and the primary elimination criteria are visible at the title level
• "Built internal feature flag system over LaunchDarkly — pricing at current MAU and planned migration to open-source provider" — includes the intended future state
• "Built internal search over Algolia — data residency requirement and pricing at current query volume" — the constraint is visible without opening the file
• "Chose Stripe over building payment processing — PCI compliance scope and financial liability" — the buy direction is as documentable as the build direction; most build-vs-buy ADRs record builds; buy decisions are equally worth recording

Context. The capability being selected, why it is needed, and the scope of the evaluation. This section should name how seriously the vendor options were evaluated — not "we considered vendors" but "we ran a two-week evaluation of three authentication SaaS providers, built a proof-of-concept integration with Auth0 against our staging environment, and evaluated Clerk's multi-tenant documentation against our data isolation requirements." The reader needs to know that the build decision was made after genuine consideration, not because the team didn't know vendor solutions existed.

Alternatives Considered. Each vendor evaluated, with specific pricing at relevant scale, specific capability gaps found, and the result of any proof-of-concept integrations. This is where the vendor evaluation spreadsheet should be summarized: not the full matrix, but the three constraints per vendor that determined whether it was viable. "Auth0 (B2B SaaS plan at $1,800/month for the multi-tenant isolation model we need; the Enterprise Self-Hosted option evaluated at approximately 40 hours of DevOps setup time for a team without existing Kubernetes experience). Clerk (Pro plan at $100/month for our current MAU, but the organization-based multi-tenancy model requires that each of our tenant's users have a separate organization account, which creates a naming collision with our internal organization concept and would require a translation layer). AWS Cognito (User Pools with federated identity; evaluated and found to have significantly more configuration complexity than Auth0 or Clerk; the SDK integration for Next.js App Router was not documented for our version at evaluation time)."

Decision. What was decided and the specific constraints that drove the selection. This section should name the primary constraint explicitly rather than leading with the principle: "We chose to build our own JWT-based authentication layer. The primary constraint was Auth0's B2B SaaS pricing at our projected scale; the secondary constraint was that our multi-tenant isolation model required custom logic that exceeded the configurable scope of both Auth0 and Clerk's standard plans without an enterprise agreement. We estimated the build at two weeks for token issuance, session management, and the multi-tenant isolation model — this estimate proved accurate."

Consequences. What was accepted. For build decisions, this section is more important than usual because the consequences are not just trade-offs but ongoing commitments: "We own the security responsibility for the authentication implementation. We accepted that any security vulnerability in the JWT implementation is our liability, not a vendor's. We accepted that future protocol changes (token format updates, emerging authentication standards) require our own implementation work. We accepted that engineers joining from companies that use Auth0 or Clerk will need to learn our custom implementation. We accepted that the multi-tenant isolation model is our custom design and must be explicitly documented for new engineers rather than pointing to vendor documentation."

Revisitation condition. Named triggers, not general language about revisiting when needs change: "Re-evaluate this decision if: (1) Auth0 introduces a multi-tenant plan at pricing below $400/month at 50k MAU that covers our isolation model without custom configuration; (2) the team grows to where the security responsibility for the authentication layer exceeds the team's capacity to own well; (3) a security audit flags the custom JWT implementation as higher-risk than a vendor solution; (4) the implementation's behavior diverges from what any vendor solution would provide in ways that create re-integration risk if we migrate."

Finding build-vs-buy deliberations in AI chat

Build-vs-buy deliberations are among the most multi-session patterns in AI chat history. A team that made a major build-vs-buy decision rarely made it in a single session. The evaluation unfolds across sessions: an initial "what are the options for X?" discovery session, one or more capability evaluation sessions ("can Auth0 handle Y?"), a pricing exploration session ("what does Auth0 cost at Z MAU?"), a proof-of-concept session ("here's the error I'm hitting in the Auth0 Next.js integration"), and a final decision session ("given everything we found, I think we should build it ourselves"). The decision that appears in the ADR was made across a week or two of deliberation, and the content of that deliberation is distributed across sessions that look different at the session level but are clearly a connected thread when extracted together.

The WhyChose extractor identifies build-vs-buy threads through the vendor-comparison pattern (multiple named vendors evaluated for the same capability across sessions) combined with elimination markers ("Auth0 would require the enterprise tier for this," "Cognito's SDK isn't documented for our version") and a terminal build decision ("we'll build this ourselves," "let's implement our own X," "I think the internal implementation is the right call here"). The multi-session nature of these deliberations makes them harder to find than single-session decisions — the thread that produced the build-vs-buy outcome isn't a single session with a decision in it, but a cluster of sessions with a shared subject. The quarterly decision review is the mechanism for finding these clusters: a systematic extraction pass across 90 days of sessions surfaces them through pattern matching across the temporal cluster, even when no single session looks like a decision record.

The sessions that are most valuable to find are the capability-gap evaluation sessions — the ones where the team was working through whether a specific vendor could handle a specific requirement. "Can Auth0 Actions support our per-tenant MFA bypass logic?" is the session that contains the most specific constraint information, more specific than the final "we'll build it" session, because the final session often references conclusions that were reached in earlier sessions without repeating the detailed reasoning. The extractor's phrase matching for vendor-specific capability limitations ("doesn't support our X," "requires enterprise tier for Y," "the SDK doesn't handle Z in our version") is calibrated to find these mid-evaluation sessions as high-value extraction targets even when the final decision appears in a different session.

The re-evaluation asymmetry

The build-vs-buy decision has a re-evaluation structure that is fundamentally different from other architecture decisions. When the team made the original decision, the switching cost was approximately zero — they were evaluating a build path against a buy path starting from the same blank slate. When the team re-evaluates the decision in year three, the switching cost is real: data migration, integration replacement, behavior mapping, team retraining, and a potential downtime window. The original decision was made under one cost structure; the re-evaluation is under a different cost structure. A re-evaluation that compares the ongoing maintenance cost of the internal implementation against the vendor pricing without accounting for the switching cost will almost always reach the wrong conclusion about whether the migration is worthwhile.

This asymmetry is rarely named in build-vs-buy ADRs, which means the re-evaluation team has to discover it empirically. The team that built authentication in year one and is reconsidering Auth0 in year three has to figure out, from scratch, what the migration cost would be. If the build ADR had included a switching cost estimate ("migrating from this implementation to a vendor solution would require: mapping our session model to the vendor's session model, migrating existing user credentials, replacing the multi-tenant isolation logic with vendor configuration, and a phased rollout to avoid a session invalidation event — estimated at six to eight weeks of one engineer's time"), the re-evaluation team can check: has the implementation grown in ways that would increase that estimate? Has the vendor's migration documentation matured in ways that would reduce it?

The switching cost estimate also affects the original build decision in a useful way. An engineering team that forces itself to estimate the future switching cost before finalizing the build decision will sometimes discover that the build path is less attractive than it looked. A two-week build that would take six to eight weeks to migrate is a different calculation than a two-week build that could be replaced by a vendor integration weekend. The switching cost estimate in the ADR is not just for the future re-evaluation — it is a discipline that improves the quality of the original decision by making the long-term cost of the build path explicit.

Writing the ADR before finalizing the build decision surfaces the switching cost question earlier. An engineer who opens the ADR template and tries to fill in the Consequences section before committing to the build path will encounter the question: "what would it take to migrate from this implementation to a vendor solution later?" Answering that question is uncomfortable when the build decision is being driven primarily by current-period cost. It is also the correct question, and answering it converts the two-week build decision into a full lifecycle cost assessment that the team can make with open eyes rather than discovering in year three that the build was cheap and the migration is expensive.

The buy decision is worth documenting too

Most build-vs-buy guidance focuses on the build decision — the choice to implement internally rather than adopt a vendor solution. The buy decision is equally worth documenting, and it is the one less likely to have an ADR because the buy path feels like the obvious and uncontroversial choice. Choosing Stripe for payment processing looks like a non-decision: everyone uses Stripe. But the choice to use Stripe rather than build payment processing was made under specific constraints (PCI compliance scope, financial liability for card data handling, the team's risk assessment of implementing payment processing correctly), and those constraints are exactly what a new engineer needs to understand when they ask "what would it take to support a different payment processor?"

Buy decisions are also the ones most likely to accumulate vendor-specific technical debt without a record. A team that chose Stripe in 2020 and has since built webhook handlers, dispute management workflows, invoice generation logic, and subscription management tooling on Stripe's API surface has a codebase that is deeply integrated with Stripe's specific API behavior. The case for documenting architecture decisions is clearest when the decision is the most difficult to reverse — and a buy decision that has accumulated three years of vendor-specific integration work is among the hardest to reverse. The ADR that was written at the moment of the original buy decision, naming the constraints that made Stripe the right choice and the conditions under which the evaluation should be revisited, is the document that gives the team a framework for that re-evaluation rather than forcing them to reconstruct the original reasoning from a codebase that has been shaped by the vendor's API conventions for three years.

The rejected dependency record applies at the vendor level too. A team that evaluated Stripe, PayPal, and Braintree and chose Stripe for specific reasons has a record of what PayPal and Braintree were evaluated against and why they were not selected. That record is valuable when the team considers adding PayPal support for a customer segment that prefers it — the evaluation of PayPal during the original platform selection is the starting point for the capability assessment, not a blank slate. Without the rejection record for the vendors not chosen, the team re-evaluates from scratch, spending time re-discovering what was already known at the time of the original decision.

What the honest build vs. buy record enables

The honest build vs. buy record — the one that names pricing rather than "vendor lock-in," that names team familiarity rather than "customizability," that names current capacity rather than "maintainability" — enables four things that the rationalized record does not.

It enables an accurate re-evaluation. The team in year three can check the specific constraints against the current state of the market. Auth0's current pricing at 50k MAU. The current state of the multi-tenant configuration options. The team's current capacity to own the maintenance burden. The comparison is between the current state of these constraints and the constraints that drove the original decision — which is the correct comparison, not a comparison between a fresh build and a fresh buy that ignores the switching cost accumulated over three years.

It enables honest accounting of the build path's long-term cost. A build decision that was made at a two-week estimate can be evaluated against the actual maintenance investment: how many engineering weeks have been spent maintaining the implementation, how many incidents were related to it, how many onboarding sessions have been needed for new engineers? This accounting is only possible if the original decision is documented honestly enough to establish what the team was committing to at the time they made the decision.

It enables the team to learn from the decision's outcome. A build decision that was made primarily for pricing reasons can be evaluated against the actual pricing trajectory: was the pricing estimate accurate? Did the vendor pricing change in the direction that would have made the buy option viable at scale? Did the team's own implementation costs stay within the original estimate? This feedback loop between prediction and outcome is only possible when the original prediction is documented accurately.

And it enables the engineering culture that values accuracy over appearance. An engineering team where the ADRs say what actually happened — where the constraints are named specifically, where the trade-offs are acknowledged honestly, where the organizational and budget constraints are documented alongside the technical ones — is a team where new engineers can trust the decision record as a source of truth rather than treating it as a self-justifying narrative that needs to be decoded. The build vs. buy decision is the test case. If the team can write honestly about why they built instead of buying — naming the pricing, the capacity, the familiarity, the organizational preference — they can write honestly about any decision. If the record says "vendor lock-in concerns" when it means "we couldn't afford the enterprise tier," the record is optimized for the moment of writing rather than for the engineer who reads it in three years under the switching cost calculation the team avoided documenting when they had the chance.

Further reading

• Decisions that never get written down — the "not yet" build-vs-buy decision (we'll use Datadog when we're bigger) is the most common variant of the undocumented "not doing this" record; the "not yet" condition disappears from the ADR even when it was the entire decision
• The wrong constraint ADR — vendor lock-in as the documented reason for a pricing decision is the canonical false constraint in build-vs-buy records; the record documents a principle when the real driver was a number
• The new-CTO onboarding problem — inherited custom implementations of authentication, search, and payment processing are the most common source of "why didn't you just use X?" questions from new technical leaders; the build-vs-buy ADR is the document that answers the question before it has to be asked
• The rejected dependency decision record — the parallel record at the library level; the rejected vendor is the same pattern at a higher scale; both require documenting the specific constraint that drove rejection with enough specificity to allow re-evaluation when the constraint changes
• The ADR title convention — build-vs-buy titles should name the capability and the primary elimination constraint, not just the direction; "Built internal authentication over vendor solutions" is less useful than "Built internal authentication over Auth0 — multi-tenant pricing and integration complexity"
• Nygard ADR template — the standard format works for build-vs-buy decisions with the critical adjustment that Alternatives Considered must name specific vendors with specific pricing and specific capability gaps, not vendor categories
• ADR lifecycle: supersede and deprecate — a build ADR superseded by a buy ADR (the team migrated to a vendor) should chain to the migration record; the migration record names which downstream implementation decisions had to be addressed and which internal behaviors had to be dropped or approximated in the vendor configuration
• WhyChose extractor — build-vs-buy deliberations are multi-session patterns in AI chat history: vendor comparison sessions, capability-gap evaluation sessions, pricing exploration sessions, and a terminal build decision; the extractor identifies these cross-session threads through the vendor-name comparison pattern and elimination markers
• The ADR as a forcing function — filling in the Consequences section of a build-vs-buy ADR before the decision is finalized surfaces the switching cost question that most build decisions skip; an engineer who must estimate the future migration cost before committing to the build path makes the decision with full lifecycle visibility
• The quarterly decision review — build-vs-buy deliberations span multiple sessions and are harder to find than single-session decisions; the quarterly extraction pass surfaces them through cross-session pattern matching rather than single-session decision detection
• The startup founder ADR starter pack — the earliest build-vs-buy decisions are made by founders and first engineers who are moving fast under budget and capacity pressure; these decisions accumulate the most switching cost by the time the company is large enough to reconsider them, making the honest record especially important
• How to document architecture decisions — the case for ADRs applies with particular force to build-vs-buy decisions because they are the highest-commitment architecture choices with the longest maintenance horizon and the most common source of "why did we build this instead of using X?" questions