Build vs license a crypto swap experience

Compare deliverables, not feature counts

A widget can suit a team that needs a prebuilt surface and accepts the provider's UX and constraints. A routing API gives engineers more control but leaves the wallet, review, transaction states and support workflow to implement. A licensed application can provide those surrounding flows while introducing its own integration and maintenance obligations.

Ask for a demonstration of the actual approval and failure paths. Two offers that both say 'cross-chain swaps' may differ substantially in recipient validation, pending-delivery handling and the evidence used to report completion.

Write down the work that stays with your team

For each option, record who owns the interface, wallet integration, provider credentials, deployment, monitoring, incident response and upgrades. Do not count an included API as an included operated product.

In a Swap Assistant branded deployment, the reusable application includes quote review, saved activity, alerts and release controls. The customer supplies approved provider accounts and infrastructure. Bespoke connectors, new protocols, operating permission and ongoing service levels are not assumed.

Use a fit matrix before an estimate

Choose a small set of routes and wallet/device combinations representative of your users. For each one, classify the behavior as demonstrated, configurable, custom work or unsupported. Price the remaining work only after that distinction is visible.

• Wallet connection, account switch, rejection and return-to-app behavior
• Allowance and swap approval boundaries
• Fee, network cost and minimum-received presentation
• Quote expiry and unavailable route handling
• Destination delivery and support investigation
• Deployment ownership, backup restore and release rollback

Check rights and operating costs separately

A license should state deployment count, source access, allowed modifications, redistribution rights and the support window. Dependency and provider terms are separate from the application license. A fee configuration does not prove a provider account is approved or a payout has settled.

Hosting, RPC, providers, notifications and market-data licensing can introduce ongoing costs even when the software uses free tiers initially. Ask for the current dependency map and limits, not a claim that operation will always be free.

Make a paid pilot test a decision

A useful pilot ends with agreed acceptance evidence and a handover, not just a new logo. Set a bounded route scope, define pass/fail cases and identify the operator. If the requirements do not fit the existing implementation, custom development or a provider widget may be the better choice.

There is no evidence-backed universal number of weeks saved. The honest saving is the implementation work your team can verify it does not need to repeat. Use the synthetic demo as the starting point, then request a scoped fit review.

Questions before a pilot