Build vs Buy for Tech Leaders: 5 Questions That Survive Finance

Buy or partner by default for capabilities that do not set your product apart, provided the solution meets your operating requirements. Build when a workflow, customer benefit or need for control justifies long-term ownership and your team can sustain it. Compare the resulting capability and operating commitment before comparing prices.

In the hypothetical document-processing model below, buying costs $138,000 and building costs $180,000 at an average of 100,000 documents per month, covering upfront delivery plus 36 operating months. Those illustrative USD totals depend on the stated scope, volume and rates. Workflow fit, delivery timing and excluded costs can change the decision.

How do you decide between build, buy and partner?

Start with a classification, then test it against the actual requirement. Sort each capability into one bucket:

• Core: a capability that creates a meaningful advantage for your business or customers.
• Context: important to operations, but not itself the reason customers choose you.
• Commodity: a standard capability that many companies in your space need.

The 10-second filter is useful: if a competitor ran the same capability on an off-the-shelf tool, would you lose customers? If not, question whether it belongs in Core.

But do not stop there. Customers may never notice your internal approval system, while its permissions, audit trail or integration requirements still make a particular vendor unsuitable. The classification helps set priorities; it does not establish product fit.

Then ask the five questions:

• Is this a source of customer-paid differentiation?
• Does a market solution fit our workflow?
• What is the true total cost of ownership?
• What time-to-value do we need?
• Who will own operations long-term?

Before comparing the options, separate mandatory requirements from preferences. Give each requirement an owner, an acceptance check and a status: pass, fail or unresolved. For example, ask the security owner to verify permissions using representative user roles, rather than accepting “supports access control.” A failed mandatory requirement rules out the proposed scope unless the requirement changes; an unresolved one needs evidence before approval. Compare preferences only among options that meet the requirements.

Combine the answers. Core plus a team that can sustain it points toward build. Context with a good vendor fit points toward buy. Commodity is a strong candidate for an existing product or managed service. Check whether you can extend something you already operate before introducing another system; the Thoughtworks evaluation guide includes that option in the decision.

Make the capability small enough to compare. “Build our customer platform” bundles authentication, permissions, billing, reporting and your proprietary workflow into one decision. Those components need not share the same answer. You might buy authentication and billing while building the workflow that makes the product valuable.

Write the requirement as something a user or operator must accomplish. That gives both your engineers and prospective vendors the same problem to respond to.

What does building really cost compared with buying?

Comparing a first-release development estimate with a license fee leaves out integration, support and ongoing operations. A defensible model counts everything on both sides.

For building, include:

• Developer salaries and hiring costs
• Infrastructure and tooling
• Integration work with your existing systems
• Ongoing maintenance and support

For buying, include:

• License or subscription fees
• Implementation and onboarding
• Vendor support tiers
• Your own integration work, which the vendor may price separately or leave to your team

Treat internal estimates as uncertain, but make the uncertainty visible. A blanket 2× multiplier cannot explain whether the risk comes from unclear scope, unfamiliar technology, migration or missing support capacity. Give those items their own estimates and assumptions. Do the same for the vendor implementation plan.

Build a one-page TCO worksheet and write down every assumption so peers can challenge it. Keep the opportunity cost of features you will not ship alongside the cash estimate. Gregor Hohpe’s AWS analysis explains why engineering capacity has an alternative use even when the team is already employed. Avoid counting the same salaries twice or treating speculative lost revenue as a confirmed expense.

Public OCR prices: compare the component

A public API price can help you estimate one part of a workflow. Consider text recognition: both of these services publish a paid rate equivalent to $1.50 per 1,000 pages at the quantities shown.

OCR service	Published paid rate	One million pages at that rate
Google Document AI Enterprise Document OCR	$1.50 per 1,000 pages in the initial paid tier	$1,500 before applicable allowances
AWS Textract Detect Document Text, US West (Oregon)	$0.0015 per page for the first million monthly pages	$1,500 outside free allowances

Google’s detailed table displays a 1,000-page free band, while its product overview starts the $1.50 tier at page one. Verify the applicable allowance and its reset conditions before budgeting. AWS describes a separate, temporary new-customer allowance. The figures above exclude those allowances, additional extraction features, storage, other services and taxes.

A custom build can purchase either API and still require permissions, integration, exception handling, evaluation and operations. That is the useful boundary: buying recognition does not resolve who owns the surrounding workflow. The matching normalized rates also establish no equivalence in accuracy, latency or residency. Google supports a US multi-region deployment; the AWS example specifies Oregon. Check the actual deployment region against your data requirements.

Keep these page rates separate from the document-based model below. A document can contain multiple pages, and that model assumes a different scope. Use a component quote to fill a defined line in your estimate, then price the remaining responsibilities.

A worked 36-month comparison

Consider a hypothetical document-processing capability. These are illustrative USD inputs, not market quotes or costs observed in a client project.

The cash model treats implementation and operating amounts, including internal administration, as additional spending; existing payroll allocations and displaced capacity remain separate. It covers upfront delivery plus 36 operating months.

Those 36 operating months make the cost assumptions comparable, but they are not necessarily the same calendar period. For the actual finance review, place both options on one monthly timeline, starting with the decision date. Include implementation spending, any overlap with the existing system, phased rollout and the operating costs incurred within that horizon. Keep displaced roadmap work visible alongside the calculation; do not turn an unproven revenue opportunity into a cash expense.

The build requires $90,000 initially, $2,000 a month for fixed operations and $0.005 per document. The buy option requires $12,000 for integration, a $1,000 monthly platform fee, $500 a month of internal administration and $0.02 per document.

Let q be the average number of documents processed per month:

• Build: $90,000 + 36 × $2,000 + 36 × $0.005 × q = $162,000 + $0.18 × q
• Buy: $12,000 + 36 × $1,500 + 36 × $0.02 × q = $66,000 + $0.72 × q

Average monthly documents	Build: 36-month cash TCO	Buy: 36-month cash TCO
10,000	$163,800	$73,200
100,000	$180,000	$138,000
200,000	$198,000	$210,000

Under these assumptions, the cash totals cross at about 177,778 documents per month. That is a result of this model, not a general threshold for building software.

At 100,000 documents a month, buying leaves a $42,000 cash advantage over 36 months. That difference gives finance a useful question: could the unpriced implementation or exit work consume the advantage? At 200,000 documents, the build is $12,000 lower, but a maintenance overrun could reverse that result.

If volume is expected to grow sharply, calculate each month rather than treating the ending volume as though it applied for all three years. Model renewal pricing, minimum commitments and overages where the contract specifies them. Leave genuinely unknown costs unresolved until you have enough evidence to decide.

How fast do you need value, and when does a long build rule itself out?

Separate “fast to functional” from “fast to reliable production.” A prototype that works in a demo is not a system that survives real traffic, audits and edge cases. Both timelines matter.

Use the actual business deadline as the breakpoint. If a necessary capability must be operating before a customer rollout or renewal, compare the credible production dates for each option against that event. Buying or partnering may be the practical route when a build cannot meet it. A vendor whose onboarding and integration cannot meet the deadline does not solve the problem either.

If neither option meets the deadline, revisit the scope or commitment. A smaller release, temporary manual processing or a renegotiated rollout may be viable. Give any temporary arrangement an operating owner and a clear condition for replacing or ending it.

When you compare plans, put the full cycle on the table:

• Integration with existing systems and data
• Testing, security review and compliance sign-off
• Customer feedback loops and the iteration they trigger
• Rollout and training time for your own teams

Treat vendor implementation estimates cautiously, and ask references how long onboarding actually took.

Define production acceptance before comparing dates. For example, a document workflow might require the right users to access the right files, failed jobs to be retried safely, results to reach the existing system, and support staff to recover an interrupted job. Put those checks into both plans.

This makes the timeline discussion more useful. You can see whether one option is faster because it solves the required problem sooner, or because its estimate quietly omits work.

What does maintenance look like after launch?

Building means accepting ongoing responsibility for the software. Launch ends one phase of the investment; it does not establish what the next phase will cost.

Plan for these recurring activities:

• Security patching and dependency upgrades
• Monitoring, on-call and site reliability work
• Compliance updates and audit evidence
• Incident response and post-incident fixes
• Documentation and handovers

Staffing is the quieter risk. When the developers who built a system leave, support gaps can open and knowledge can disappear. You also need product management and QA, not just engineers.

Before approving a build, define service levels, assign a named roadmap owner, and fund the capacity and skills needed by the team that will carry it.

Buying changes that responsibility rather than removing it. Use a matrix like this to expose the work retained inside your company:

Responsibility	Internal build	Bought service
Product behavior and roadmap	Your team prioritizes and implements changes	Vendor controls its roadmap; your team owns fit and workarounds
Service incidents	Your team investigates and restores the system	Vendor restores its service; your team handles integration failures and customer communication
Access and data configuration	Your team owns application controls and configuration	Your team still owns its tenant configuration, permissions and data use
Integration and upgrades	Your team maintains the full implementation	Your team maintains connectors and responds to API or product changes
Exit and continuity	Maintain documentation, skills and replacement options	Verify export, deletion, transition support and contractual exit terms

Pro Tip: Ask who gets paged when something goes wrong after launch. If nobody has a name, the operating plan is incomplete.

When does building custom software make sense?

Build when these conditions hold:

1. The capability supports differentiation or a business requirement the available products cannot adequately meet.
2. You can build something demonstrably better suited to that requirement, not merely different.
3. You can maintain it over the long term without starving other priorities.

Generic examples that may qualify include proprietary recommendation logic and deeply embedded domain workflows that no packaged product models well.

Before committing, confirm internal readiness: engineers with the right skills, a product manager who owns the roadmap, and funding that can absorb the identified risks. If any one is missing, revisit a partner or hybrid model.

A reported example makes the classification less abstract. In Hohpe’s AWS account, McDonald’s moved toward its own integrated point-of-sale system after off-the-shelf procurement attempts. The system connected restaurant operations and customer channels, extending beyond order entry.

The useful lesson is the changed scope. A standard cash register looks like a commodity; an integrated operating workflow may support a different business requirement. Your build proposal should make that relationship equally clear.

Specify what the custom system will let the business do, why available alternatives fall short, and how the proposed scope addresses the gap. Owning source code alone does not answer those questions.

When is buying the better strategic choice?

Buy when a market solution matches your core requirements, when speed matters, or when your team lacks the capacity to maintain software over time. You also benefit from the vendor’s continuing product development, provided its direction supports your needs.

Evaluate vendors against a consistent checklist:

• Product roadmap and direction
• Service level agreements and uptime history
• Security and compliance posture
• Integration surface, including APIs and data export
• Long-term viability and ability to support a lasting partnership

A Thoughtworks evaluation guide recommends involving cross-functional stakeholders, defining technical must-haves and evaluating candidate solutions before committing.

Turn the most consequential checklist items into evidence requests. Ask a vendor to demonstrate your permission model, process a representative data sample, explain an API limit and show an export you could actually use. A polished demo of a neighboring workflow does not settle whether yours fits.

Follow the export through a possible exit. Use representative records and files, including relationships and history, then check whether the output can be imported into a plausible replacement. Record missing fields, manual cleanup, staff time and any export or transition charges in the decision memo. A downloadable file proves that data can leave the system; it does not establish that your team can resume the workflow elsewhere.

Document the trade-offs you accept, such as less customization or dependence on a vendor roadmap, and keep an integration risk register so surprises have an owner.

Buying is a strong choice when it provides the required capability while preserving engineering capacity for work only your team can do. It becomes less attractive when permanent workarounds absorb the capacity you expected to save.

When should you partner or mix buy and build?

Partnering is a practical middle path when you need expertise, delivery capacity or an operating service that your team cannot efficiently provide alone. Define the arrangement before comparing its price.

Hiring an agency to develop software you will own is an outsourced build. Engaging a provider to operate a service is a different responsibility model. A technology partnership may combine a licensed platform, implementation services and a shared development plan.

A low-code build also depends on its platform’s pricing, runtime, permissions and export capabilities; include those dependencies in the comparison.

Plan for the costs people forget:

• Licensing that scales with your usage
• A named relationship owner with real time to spend
• A renegotiation cadence, so terms track your growth
• Ongoing maintenance of the integration itself

The cleanest hybrid is often to build your differentiators and buy or partner for the surrounding capabilities. Your engineers stay focused on the work that matters most, while standard components remain replaceable where practical.

The boundary needs an owner. If a partner builds an integration, establish who maintains it after an API changes, where the code and documentation live, and whether your team can deploy a fix without buying another project.

Assign an owner to the integration before approving the hybrid.

How does AI change the build vs buy math?

AI can change implementation speed and introduce model-related uncertainty, but integration, data quality and governance were operating concerns before AI. The question is which responsibilities a particular AI option adds, transfers or leaves with your team.

• A vendor may deliver useful capabilities sooner, while your team still needs to verify them against its workflow.
• A build may require continuing work on evaluation, data pipelines and model behavior, even when it uses a hosted model.
• A modular architecture can make replacement easier, but adapters, evaluation and migration still require effort.
• Re-evaluate when model quality, availability, pricing or your requirements materially change.

Compare the same task and acceptable result. For document extraction, that could mean representative files, an agreed error-handling route and a review process for uncertain results. A lower model price is not a lower operating cost if more results need manual correction.

Put evaluation and human review into both proposals. Ask what happens when a model changes, how regressions will be detected, which data reaches the provider, and who pays for retries or additional review. These are questions to resolve with the actual architecture and contract, not reasons to assume either build or buy must win.

How do you run the decision process itself?

Put the decision in a short memo that product, engineering and finance can review. Follow this sequence:

1. Assemble the group: product, engineering, security and compliance, finance, operations, and whoever owns partnerships.
2. Classify each capability as Core, Context or Commodity.
3. Produce the artifacts: a TCO model with explicit assumptions, an integration risk register, a vendor assessment and a short decision memo.
4. Set decision gates with a timeline and the approvals required.
5. Agree on review points and the changes that would reopen the decision.

The memo should preserve the reasoning someone will need after the meeting. Here is a shortened example using the hypothetical document-processing calculation:

Decision field	Example entry
Required capability	Process documents into the existing workflow, with access controls, recoverable failures and usable data export
Options	Extend the current system; build internally; integrate a bought service; use an implementation partner
Cost assumption	100,000 documents per month on average for 36 months: $180,000 build versus $138,000 buy under the stated inputs
Open evidence	Production workflow fit, migration and exit effort, actual implementation schedule, and contract pricing
Displaced work	Name the roadmap items and capacity a build would consume before approval
Operating ownership	Product lead owns requirements; engineering lead owns the integration; finance owns volume and spend review
Conditional recommendation	Prefer buy if it meets the production requirements and unresolved costs preserve its advantage; otherwise reassess the viable options
Reversal trigger	A material change in volume, unit prices, workflow fit or operating cost; rerun the model rather than switching automatically

Pro Tip: Write the decision memo for the skeptic in finance. Explain what each figure covers, what remains uncertain and which assumption could change the recommendation.

An editor’s view: make the filter a habit, not a project

It is easy to treat build vs buy as a one-time event, then live with the result for years. The better habit is smaller and more frequent. Fold the Core / Context / Commodity filter into planning, so each significant capability is considered before it is staffed. Run a short TCO sanity check whenever scope grows.

The unglamorous practices matter: keep a named person responsible for each partner relationship, compare actual operating costs with the decision memo, and review important commitments before renewal.

Set the cadence to match the decision. A renewal date creates one review point. Repeated service failures, a new requirement, a pricing change or the departure of a key maintainer can create another. An arbitrary calendar interval should not delay a review when the underlying assumptions have already changed.

The purpose is to recognize when a sensible decision needs updating, while retaining the parts that still work.

Before approval

Record the proposed scope, the operating owner and any estimate still waiting for evidence in the decision memo.

For your next build or buy review, start with the five questions above. Take the cost assumptions, responsibility matrix and decision memo into the same discussion. Each exposes a different part of the commitment; together they make the choice easier to explain and revisit.

Sources

• Thoughtworks: Build versus buy — a strategic framework for evaluating third-party solutions
• Gregor Hohpe / AWS: Buy vs. Build Revisited — 3 Traps to Avoid
• Gregor Hohpe / AWS: Buy vs. Build Revisited, Part 2 — Drawing the Line

• Google Document AI pricing — Enterprise Document OCR paid tiers and displayed free band.
• Google Document AI — product overview; initial-tier wording differs from the detailed pricing table.
• Document AI locations — deployment regions for processors.
• AWS Textract pricing — Detect Document Text example for US West (Oregon) and temporary new-customer allowance.

The 36-month cost model, responsibility comparison and decision memo are illustrative editorial tools. Replace their assumptions with your requirements, estimates and contractual commitments. The separately identified public OCR rates were checked October 16, 2026; they price components rather than a completed workflow.

Frequently asked questions

A few practical answers before you put this guide to work.

Is it more expensive to buy or build software?

Neither option is always cheaper. Compare implementation, integration, recurring operation, usage, support and exit over the same period and scope. In the illustrative model above, buying costs less at 100,000 documents a month, while building costs less at 200,000; different inputs can reverse either result. A license price and a first-release development estimate are not comparable totals.

What is the buy and build strategy?

It is a hybrid approach: buy or subscribe for suitable standard capabilities and build the parts that need distinct behavior or control. For example, a product might use existing authentication and billing services while its team builds a proprietary workflow. Define who owns the integrations and their ongoing maintenance before treating the combination as a lower-cost option.

What is build vs buy?

Build vs buy is the decision between developing software for your needs and adopting an existing product. The practical comparison may also include extending an existing system, outsourcing development or engaging a managed-service partner. Those options transfer different responsibilities, so compare the resulting capability and operating commitment rather than the labels alone.

How often should we revisit a build or buy decision?

Set review points around contract renewals, planning and material changes to the assumptions behind the choice. Reopen it sooner if volume, prices, service quality, workflow requirements or team capacity change enough to affect the recommendation. AI-related capabilities may introduce additional model or provider changes, but no single review interval fits every system.