A company should not begin its Web3 strategy by choosing a blockchain, commissioning a smart contract, or shopping for a wallet provider.
It should begin with a business problem.
Only after the organization has identified a credible use case—such as payments, tokenization, digital identity, contract automation, asset management, loyalty, or customer access—does the first major delivery decision arise:
Should we build the capability ourselves, buy an existing platform, or develop it with a strategic partner?
That choice shapes almost everything that follows. It affects time to market, implementation cost, operational control, vendor dependence, security responsibilities, regulatory exposure, and the capabilities the company must maintain after launch.
The wrong decision can turn a promising use case into a long and expensive infrastructure project. The right decision allows the organization to concentrate its resources where they create strategic value while relying on proven systems for the parts that do not differentiate the business.
For most enterprises, the answer will not be exclusively build, buy, or partner.
It will be a carefully designed combination of all three.
The decision comes after use-case selection
Build, buy, or partner is sometimes described as the first decision in Web3.
More precisely, it is the first major implementation decision.
Before reaching it, leadership should already understand:
- What business problem the initiative addresses
- Why Web3 infrastructure may be relevant
- Who will use the system
- What value the initiative is expected to create
- What evidence would justify further investment
- What legal, operational, financial, and customer risks may be involved
Without that foundation, the company is not selecting an implementation model. It is choosing technology without knowing what it is meant to accomplish.
This is how vendor-driven strategy begins. A company becomes interested in a platform, token, blockchain, or wallet product and then searches for a use case that justifies it.
Responsible adoption works in the opposite direction:
Define the problem first. Then determine which capabilities the company should own, source, or share.
What does it mean to build?
Building means the organization takes primary responsibility for creating and operating the Web3 capability.
That may include some combination of:
- Smart-contract development
- Wallet architecture
- Key-management systems
- Blockchain integration
- Token issuance and administration
- Identity and credential systems
- Transaction monitoring
- Security controls
- Customer interfaces
- Data integration
- Governance workflows
- Reporting and reconciliation
Building does not necessarily mean inventing a blockchain from scratch. A company can build proprietary applications on public networks or existing protocols. The defining feature is that the organization owns the architecture, engineering decisions, operating processes, and ongoing maintenance.
When building makes sense
Building is most defensible when the capability is central to the company’s strategic differentiation.
That may be true when:
- The product or business model cannot be delivered through existing platforms.
- Proprietary workflows or intellectual property create a material advantage.
- The company requires unusually high control over data, permissions, custody, or execution.
- The use case will support several products over a long period.
- Existing vendors cannot meet the organization’s technical, regulatory, or geographic requirements.
- The company already possesses strong engineering, cybersecurity, legal, and operational capabilities.
- The business can justify the time and long-term cost of maintaining the system.
J.P. Morgan’s Kinexys platform illustrates what a true build commitment looks like at institutional scale. J.P. Morgan says it has spent more than a decade developing its blockchain infrastructure, which now supports programmable payments, tokenization, on-chain foreign exchange, digital financing, and integration with legacy financial systems. The platform has processed more than $3 trillion in transaction volume since its inception. That is not a limited technology experiment; it is a long-term infrastructure and organizational commitment.
The lesson is not that every company should imitate J.P. Morgan. It is that serious internal infrastructure requires far more than writing code.
It requires sustained investment in security, compliance, governance, integration, operations, talent, and product development.
The hidden obligations of building
Building provides control, but control carries responsibility.
The company must determine:
- How private keys or signing authority will be secured
- How transactions will be approved and monitored
- How smart contracts will be tested, audited, upgraded, and paused
- How the system will interact with legacy software
- How regulatory requirements will be incorporated
- How incidents and disputed transactions will be handled
- How new blockchains, tokens, or standards will be supported
- How the system will remain available outside normal business hours
- Who will maintain the infrastructure after the original development team moves on
A prototype may be relatively easy to create. A secure, compliant, observable, recoverable, and production-ready system is much harder.
The strategic question is therefore not: Can our developers build this?
It is: Can our organization operate and govern this reliably for as long as the business depends on it?
What does it mean to buy?
Buying usually means licensing or integrating an established platform rather than developing the underlying infrastructure internally.
The company might purchase access to:
- Wallet-as-a-service infrastructure
- Custody technology
- Blockchain nodes and APIs
- Tokenization platforms
- Stablecoin payment systems
- Identity or credential tools
- Smart-contract management systems
- Compliance and transaction-monitoring services
- Analytics and reporting infrastructure
- Cross-chain or settlement services
The company still builds its product, workflow, or customer experience, but it does so on top of infrastructure provided and maintained by someone else.
When buying makes sense
Buying is often appropriate when the required capability is important but not strategically differentiating.
A retailer may want embedded wallets for a loyalty program, but wallet-key infrastructure is unlikely to be the retailer’s core competitive advantage. A payment company may want stablecoin settlement without building support for every blockchain and asset internally. A financial institution may want to test tokenized deposits using an established platform before committing to its own production infrastructure.
Platforms such as Coinbase Developer Platform and Fireblocks demonstrate how much enterprise infrastructure can now be accessed through managed products. Coinbase offers embedded and server-controlled wallets with API access, transaction policies, key protection, multi-chain support, and compliance controls. Fireblocks offers wallet infrastructure, policy controls, treasury tools, and embedded-wallet systems intended for institutions and companies managing digital assets or customer funds.
These services do not remove every risk or responsibility. They allow the company to avoid rebuilding certain underlying capabilities that specialized providers already operate at scale.
What the company gains by buying
Buying can provide:
- Faster deployment
- Access to established security architecture
- Reduced initial engineering requirements
- Support for multiple chains and assets
- Existing administrative and policy controls
- More predictable implementation paths
- Vendor documentation and technical support
- Easier testing before a larger commitment
It may also allow the company to focus its internal team on the differentiating elements of the initiative: customer experience, product design, proprietary workflows, market strategy, data, or integration with the broader business.
What the company gives up
Buying introduces a different set of dependencies.
The organization must evaluate:
- Vendor lock-in
- Pricing changes
- Product-roadmap dependence
- Availability and service levels
- Data access and portability
- Key ownership and custody structure
- Supported blockchains and jurisdictions
- The vendor’s security and incident history
- Integration limitations
- Contract termination and migration procedures
- What happens if the provider is acquired, restructures, or discontinues the service
A platform may accelerate entry while also narrowing future options.
The company should therefore understand its exit before it signs the contract.
That includes whether assets, data, identities, keys, smart contracts, and customer relationships can be moved to another system without rebuilding the product from the beginning.
What does it mean to partner?
Partnering is different from purchasing software.
A strategic partner contributes expertise, regulated access, distribution, infrastructure, implementation capacity, or market relationships that the company cannot easily obtain through a standard vendor agreement.
Partners might include:
- Banks and payment providers
- Licensed custodians
- Tokenization specialists
- Blockchain infrastructure companies
- Compliance and identity providers
- Technology integrators
- Legal and regulatory advisers
- Industry consortia
- Web3-native protocols or networks
- Strategy and implementation firms
The relationship may involve joint product design, a shared pilot, integration support, regulatory coordination, or access to a partner’s network and operating capabilities.
When partnering makes sense
Partnership is especially valuable when the initiative depends on capabilities outside the company’s core competence or legal authority.
A company may need:
- A regulated entity to custody assets
- A bank to connect tokenized money to existing accounts
- A payment network to reach merchants or counterparties
- A technology partner to operate secure wallet infrastructure
- A compliance provider to screen transactions
- A tokenization provider to connect assets with legal and administrative systems
- A consulting partner to coordinate strategy, governance, and vendor selection
Visa’s work with BBVA on the Visa Tokenized Asset Platform provides a useful example. Visa created an API-based platform through which participating financial institutions can test the issuance, transfer, and redemption of fiat-backed tokens. BBVA worked with Visa in the platform’s sandbox to explore a bank-issued token and smart-contract interactions rather than attempting to create every component independently.
The value of the partnership is not merely access to software. It is the combination of the bank’s financial role, Visa’s payments and tokenization infrastructure, and the joint work required to move from experimentation toward a regulated service.
Partnership does not transfer accountability
A company can outsource infrastructure, development, custody, or compliance functions.
It cannot outsource ultimate responsibility for the initiative.
Leadership must still understand:
- What the partner controls
- What the company controls
- Who bears each category of risk
- Who owns customer relationships and data
- Who responds to incidents
- Who makes changes to the system
- How regulatory obligations are divided
- How the relationship can be terminated
- What happens to users and assets if the partnership ends
A strong partner closes a capability gap.
A weak partnership obscures responsibilities that no one has clearly accepted.
Most enterprises need a hybrid model
The build-buy-partner decision should not be treated as a vote in which only one option can win.
A practical Web3 system may involve all three.
A company might:
- Build its proprietary customer experience and business rules
- Buy wallet, blockchain, monitoring, and analytics infrastructure
- Partner with a bank, custodian, payment provider, or compliance specialist
Another company might:
- Build its core tokenization engine
- Buy cloud, node, and security services
- Partner with asset administrators and regulated distributors
A loyalty initiative might:
- Build the program logic, brand experience, and rewards structure
- Buy embedded-wallet infrastructure
- Partner with merchants or entertainment properties that provide benefits
This reflects how enterprise Web3 generally works. The blockchain component sits within a larger system of legal agreements, customer support, data controls, financial operations, identity systems, and existing software.
The objective is not to maximize the amount built internally.
It is to place each capability under the operating model best suited to it.
The central principle: own what differentiates you
The strongest general rule is:
Build what creates your competitive advantage. Buy what has become reliable infrastructure. Partner where execution depends on specialized expertise, regulated access, or a broader network.
This does not produce an automatic answer, but it creates a useful starting point.
Build when:
- The capability is strategically distinctive.
- Control is essential.
- The organization has the necessary talent and operating capacity.
- The investment supports a long-term roadmap.
- Existing products cannot meet the need.
Buy when:
- The capability is necessary but largely standardized.
- Speed and reliability are more important than full customization.
- A credible provider can offer the service at lower total cost.
- The organization wants to test the use case before making a larger commitment.
Partner when:
- The initiative crosses institutional or regulatory boundaries.
- The organization lacks specialized knowledge.
- Market access or distribution is required.
- The project needs coordinated legal, technical, financial, and operational execution.
Wait when:
- The use case remains unclear.
- The technology does not improve on the existing system.
- The organization is not ready to govern the initiative.
- Regulatory or infrastructure uncertainty makes the experiment premature.
- The company cannot identify a contained pilot or meaningful success metric.
Waiting is not the same as ignoring Web3.
It may involve education, market monitoring, internal capability-building, vendor assessment, or designing the conditions under which a future pilot would become worthwhile.
The table is not a scoring shortcut. One factor may outweigh several others.
A regulated financial product may require partnership even if the company could technically build it. A proprietary trading or settlement capability may justify internal development despite a longer timeline. A limited pilot may be better served by a managed platform even if the company eventually intends to build.
Seven questions to answer before deciding
1. Which part of the system creates the advantage?
Separate the differentiating capability from the supporting infrastructure.
The company may need wallets, but the wallet itself may not be its advantage. It may need tokenization, but the advantage may lie in the assets, distribution, underwriting, customer experience, or legal structure rather than the token contract.
2. How much control is genuinely necessary?
Organizations often say they require complete control when what they actually need is control over specific policies, data, approvals, customer relationships, or product rules.
Define the required form of control rather than treating it as an abstract principle.
3. What capabilities must exist after launch?
The decision should account for production operations, not only development.
Who will monitor transactions, manage permissions, respond to incidents, upgrade contracts, review vendors, and maintain integrations?
4. What is the complete cost?
Compare total cost of ownership, including:
- Development
- Recruiting
- Security audits
- Compliance
- Cloud and blockchain infrastructure
- Monitoring
- Maintenance
- Upgrades
- Vendor fees
- Integration
- Migration
- Incident response
- The opportunity cost of delayed entry
The cheapest prototype may become the most expensive operating model.
5. What risk remains with the company?
A vendor or partner may perform a function, but the company may still retain the legal, reputational, customer, and regulatory consequences if that function fails.
6. How reversible is the decision?
A good early-stage decision preserves options.
The company should know whether it can change providers, move assets, export data, alter custody arrangements, or replace infrastructure without disrupting customers.
7. What evidence would change the decision?
A pilot may begin on a purchased platform and later justify an internal build. A company may initially partner with a regulated provider and eventually develop more capability itself.
The implementation model should be revisited as evidence and organizational capacity develop.
Common mistakes
Building to demonstrate sophistication
Building infrastructure is not proof of strategic seriousness. It may simply mean the company is spending resources on capabilities that an outside provider already performs better.
Buying before defining requirements
A polished vendor demonstration can make the platform seem like the strategy. The company should establish its use case, controls, data needs, user experience, regulatory exposure, and exit requirements first.
Allowing the vendor to design the operating model
Vendors naturally frame problems around what their products can solve. Leadership must retain responsibility for system architecture and business outcomes.
Treating partnership as informal cooperation
A partnership requires clear decision rights, responsibilities, service expectations, data rules, intellectual-property terms, incident procedures, and exit provisions.
Ignoring migration
The company should consider portability before the system accumulates users, assets, integrations, and operational dependence.
Building the pilot as though it were the final system
The first pilot should test a business assumption. It should not require the company to make every permanent architecture decision before it has evidence that the use case deserves to continue.
A practical first-step process
A disciplined build-buy-partner decision can be made through six steps:
- Define the use case. Identify the problem, user, expected value, and success criteria.
- Map the capability stack. List every technical, financial, legal, operational, security, and customer-facing component.
- Classify each component. Determine whether it differentiates the company, resembles standardized infrastructure, or requires a specialist relationship.
- Evaluate alternatives. Compare internal development, platforms, vendors, and partners using the same requirements.
- Design a reversible pilot. Test the model without committing the entire organization to the architecture.
- Set a decision gate. Determine what evidence would support stopping, refining, expanding, changing providers, partnering differently, or moving capability in-house.
This turns build, buy, or partner from a procurement discussion into a strategic design process.
The objective is strategic control—not total ownership
A company does not need to own every layer of its Web3 system to control its strategy.
It needs to understand the architecture, retain authority over the business outcome, protect its customers and assets, and preserve the ability to change course.
In some cases, that will justify a substantial internal build.
In others, the better decision will be to use existing infrastructure and focus the company’s resources on product, market, data, relationships, or customer experience.
Often, the strongest model will combine internal ownership with external platforms and specialized partners.
The question is not: How much Web3 infrastructure can we build?
It is: Which capabilities must we own to create value—and which should we source so that we can create that value faster, more safely, and more effectively?
That is the first implementation decision a serious Web3 strategy must answer.
Build, buy, partner—or wait?
Argot’s 2026 Web3 Adoption Report provides a practical framework for identifying viable use cases, assessing readiness, choosing infrastructure, designing controlled pilots, and moving toward integration only when the evidence supports it.
[Internal link: Download the 2026 Web3 Adoption Report]
