Build or buy? Start with what you have
The biggest mistake isn’t choosing build over buy, or vice versa. It’s failing to fully evaluate reuse first.
The traditional build-versus-buy framework begins with an assumption: the organization needs something new. Teams define requirements, research the market, estimate development effort, and compare the cost and risk of building or purchasing.
That process may seem thorough, but it can still begin from an incomplete premise.
Large enterprises already operate complex portfolios of commercial software, in-house applications, open-source technology, freeware, and services. Different teams may use different solutions to support the same capability. Existing solutions may have added relevant capabilities that your organization has not yet activated or widely adopted.
The required capability may already exist. But if teams cannot find and evaluate it, reuse never becomes a serious option. The impact is far reaching: duplicate spend, slower decision-making, and greater portfolio complexity.
Before investing time and money into something new, teams should determine whether the required capability already exists within the organization.
Reuse will not always be the right answer. But it should always be considered before the organization invests in something new.
A better technology decision sequence
- Define the capability required.
- Identify all existing solutions that provide it.
- Determine whether an existing solution can be reused or expanded.
- If no suitable option exists, evaluate whether to build or buy.
Why reuse opportunities are difficult to find
Most organizations have technology inventories. Fewer have a complete, current understanding of what every technology in the portfolio actually does.
Information is often fragmented across CMDBs, application inventories, architecture repositories, procurement systems, spreadsheets, and regional records. The same commercial product may be named differently across systems. In-house and open-source solutions may be inconsistently documented or omitted from vendor-oriented catalogs.
Systems of record can confirm that an application exists but they often contain incorrect or outdated information. These systems were not designed to continuously classify and enrich the information required to evaluate it.
Even when teams find a relevant solution, they may not know:
- Which core capabilities it provides
- Which business functions it supports
- Where and how widely it is deployed
- Whether it is approved, preferred, restricted, or under evaluation
- Who owns and supports it
- Whether it can scale beyond its current use
- How it compares with internal and market alternatives
This creates a discovery problem before it creates a decision problem. Teams cannot evaluate reuse if they cannot see comparable solutions across the enterprise.
A reliable inventory is an important foundation, but it is not enough. Reuse requires current technology intelligence and consistent classification across commercial, in-house, open-source, and other technology types.
Build a reuse-first decision framework
A reuse-first framework begins with the business capability, not a product name or a predetermined sourcing preference.
1. Define the capability
Start by establishing the outcome the business needs and the capabilities required to support it.
This prevents the request from becoming anchored to a specific vendor, product, or proposed internal build too early. It also gives architecture teams a consistent basis for finding relevant solutions, even when they have different names or were introduced for different use cases.
Requirements should distinguish between essential capabilities and optional features. Without that separation, teams may dismiss reusable technology because it does not match an unnecessarily broad wish list.
2. Search the complete portfolio
The next step is to identify every relevant solution already available to the organization.
That search should extend beyond the applications a requestor or architecture team already knows. It should include:
- Approved and preferred commercial products
- In-house applications and shared services
- Open-source and freeware technology
- Solutions used by other regions or business units
- Existing platforms with relevant capabilities
- Technology already purchased but not broadly deployed
The goal is not simply to find an exact match. It is to determine whether an existing solution can meet the requirement as configured, through broader adoption, or with reasonable expansion.
3. Validate whether reuse is viable
Availability alone does not make a solution reusable.
An existing application may provide the right functionality but lack the scale, security, support model, or architectural fit required for a broader deployment. An in-house solution may appear less expensive because its ongoing maintenance costs are not fully understood. A preferred platform may require extensive customization to meet the actual need.
Teams should test each reuse candidate against practical enterprise requirements, including:
- Capability and strategic fit
- Enterprise adoption and user experience
- Integration with the target architecture
- Security, compliance, and data requirements
- Scalability, resilience, and lifecycle position
- Ownership and support capacity
- Cost and time required to extend or deploy it
- Long-term maintenance and technical debt
This step keeps “reuse first” from becoming “reuse at any cost.” The objective is to identify a viable existing option, not force every requirement into the current portfolio.
4. Move to build versus buy when needed
If no existing solution can meet the requirement, the organization now has a clearly defined capability gap.
Only then should the traditional build-versus-buy evaluation begin.
The decision should consider more than functional fit. Building may provide greater control, customization, and strategic differentiation, but it also creates an ongoing obligation to operate, secure, maintain, and evolve the solution. Buying may accelerate implementation and reduce internal development demands, but it can introduce vendor dependency, licensing costs, integration constraints, and limited roadmap control.
The evaluation should account for:
- Strategic importance and differentiation
- Time to value
- Total cost of ownership
- Internal skills and delivery capacity
- Integration and architectural alignment
- Security, compliance, and data control
- Scalability and resilience
- Vendor viability and dependency
- Roadmap control and adaptability
- Long-term maintenance and opportunity cost
Because reuse was evaluated first, teams can approach this decision with greater confidence. They know they are addressing a genuine gap rather than recreating a capability that already exists.
Connect reuse to research and intake
A reuse-first framework only works when it is built into the processes for adding new technology to the organization.
Technology research often begins outside the enterprise. Teams search the market, compare vendors, and develop a shortlist before the internal portfolio has been fully evaluated. By the time architects or procurement teams become involved, the request may already be framed around a particular product.
Software intake can create the same problem. If requests are reviewed as isolated purchases, architecture teams may check basic standards and risks without recognizing a comparable internal solution.
Portfolio evaluation should occur before market research narrows the options and before a software request advances toward approval.
At these points in the workflow, teams should be able to:
- Search by required capability
- Surface approved and preferred technologies
- Identify comparable in-house solutions
- See adoption across regions and business units
- Compare internal and external options consistently
- Direct requestors toward viable reusable solutions
- Confirm when a new build or purchase is justified
This changes portfolio intelligence from a reference source into an active part of technology decision-making.
It also makes governance more constructive. Instead of simply rejecting a request because a similar product exists, architecture teams can show which available solutions meet the need and why they should be considered.
Make reuse a decision discipline
Reuse should not be an informal check based on who happens to know the portfolio. It should be a defined step supported by complete data, consistent classification, current intelligence, and clear ownership.
Every new technology requirement should begin with three questions:
- What capability is actually required?
- Where does that capability already exist?
- Can an existing solution meet the need at enterprise scale?
If the answer to the third question is no, the organization can move forward with a well-informed build-versus-buy evaluation. If the answer is yes, it can avoid unnecessary research, development, procurement, and ongoing support.
The goal is not to discourage new technology investment. It is to ensure that investment addresses a real gap.
Entrio connects internal portfolio data with a live market catalog, structured taxonomy, and continuously updated technology intelligence. This gives enterprise architects a consistent way to find what already exists, assess whether it can be reused, and determine when a new build or purchase is genuinely needed.
Before deciding whether to build or buy, start with what you have.
