Swap Assistant| Decision | Provider widget | Custom API integration | Licensed application |
|---|---|---|---|
| Starting point | Provider-maintained swap surface | Routes and transaction-building interfaces | Existing screens, backend and operating workflow |
| Interface control | Within the widget's supported options | Your team builds and maintains it | Brand the existing flow; scope deeper changes |
| Wallet and failure states | Check the widget's actual connector behavior | Implement account changes, rejection, expiry and recovery | Reuse demonstrated states; verify your wallet compatibility |
| History and operations | Check included services and data access | Build persistence, notifications and evidence | Existing modules, configured for the agreed deployment |
| Ongoing work | Vendor updates plus integration testing | Your code, dependencies and provider changes | Release ownership and maintenance agreed in writing |
| Best fit to evaluate | A limited embed with acceptable vendor UX | A distinctive workflow with a funded engineering team | A product or agency reusing an established workflow |
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
Compare a real brief, not a headline price
Consider an illustrative wallet team that needs a web swap journey for two named networks, one existing wallet connector, saved activity and Telegram alerts. A widget might cover quote and execution screens but still require separate activity and notification integration. A custom build gives control over all of it, with corresponding testing and maintenance work. Licensed software is useful only if its demonstrated behavior fits those requirements.
Ask each supplier to classify every requirement as included, configuration, custom work or unavailable. Add infrastructure, provider fees or subscriptions, support, upgrades and acceptance testing to the comparison. Do not treat a lower initial license price as a lower total cost, or assume a supplier's public price covers your brief.
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
Is licensing always cheaper?
No. Custom requirements, operating obligations and license terms can change the comparison. Build a fit matrix and estimate the remaining work before deciding.
What should we request first?
A working demo, explicit exclusions, architecture boundaries and acceptance criteria for your actual routes and wallets.
Further technical reading
Official references for integration responsibilities. These links are not endorsements, and do not imply that every referenced provider is enabled in Swap Assistant.