Most successful DeFi applications are not new protocols. They are interfaces, strategies and services built on top of existing, audited liquidity. Deciding early whether you are building an application on DeFi or a protocol of DeFi changes your budget, timeline and risk by an order of magnitude.
This guide is for founders and product owners planning a DeFi app and evaluating teams to build it. For the protocol layer itself, read the DeFi development overview.
Application or protocol
| Application on DeFi | New protocol | |
|---|---|---|
| Examples | Swap front end, portfolio dashboard, savings app routing to lending markets, vault strategy, payments using stablecoins | New AMM, lending market, stablecoin, derivatives exchange |
| Liquidity | Borrowed from existing protocols on day one | Must be attracted from zero |
| Contracts you write | None, or thin adapters and routers | Core financial logic |
| Audit scope | Small, or none if no contracts | Large, often multiple audits |
| Main risks | Upstream protocol failures, front-end security, UX | Exploits, insolvency, economic design |
| Reasoned time to first release | Weeks to a few months | Many months |
An application can still be a strong business: wallets and aggregators earn integrator fees, savings apps earn spreads or subscriptions, and strategy vaults earn performance fees. The white-label swap comparison shows how much of a swap product you can assemble from existing services.
Common kinds of DeFi applications
DeFi is often described as "money legos" because applications assemble existing protocols. Typical categories, and what each one actually requires:
- Savings and earn apps. Route stablecoin deposits into lending markets or vaults and show a simple balance. The work is integration, risk monitoring and clear disclosure that the yield is variable and not insured.
- Swap and bridge interfaces. Aggregator-backed trading, often inside a wallet or a larger app.
- Position managers and dashboards. Track LP ranges, health factors and staking across protocols, sometimes with automated actions such as rebalancing or deleveraging. These need serious indexing.
- Leverage and strategy tools. One-click looping or delta-neutral strategies built from flash loans and lending markets. Powerful, and the place where users lose money fastest if risks are hidden; contracts here need audits.
- Payments and treasury tools. Stablecoin invoicing, payroll or DAO treasury management. Accounting exports and permissions matter more than yield.
- Prediction markets and betting. Usually involve their own contracts and oracles for outcomes, and gambling or derivatives rules in many places; see the sports betting dApp guide.
- Wrapped and tokenized assets. Bringing BTC or real-world assets into DeFi involves custody and legal structures far beyond app development.
Architecture of a DeFi application
Wallet layer
Users connect self-custody wallets through standards like EIP-1193 (the provider interface) and EIP-6963 (discovering multiple installed wallets), or WalletConnect for mobile wallets. Libraries such as wagmi and viem handle most of this in TypeScript. If your audience is not crypto-native, embedded wallets and smart accounts (ERC-4337, or EIP-7702 delegation for existing accounts) let users sign in with email or passkeys and have gas sponsored. The DeFi wallet guide explains those trade-offs.
Data and indexing
Reading balances and positions directly from contracts on every page load is slow and rate-limited. Most apps run an indexer: a subgraph, a hosted indexing service or a custom pipeline that consumes events and writes to a database. It powers histories, PnL, APY charts and notifications. Plan for chain reorganizations and for re-indexing when contracts change.
Transaction building and safety
- Simulation. Simulate every transaction before the user signs and show the expected balance changes in plain language.
- Approvals. Request exact amounts or use expiring permit signatures rather than unlimited approvals, and show what spender is being approved.
- Slippage and MEV. Set sensible slippage per asset type and offer private transaction submission where available.
- Typed signatures. Use EIP-712 so users see structured data, and never ask users to sign opaque messages.
Back end
Many DeFi apps still need servers: RPC providers with fallbacks, quote APIs, keepers that harvest or rebalance, notification services, and analytics. Keep private keys for keepers in hardware-backed or managed key services with minimal permissions, and never let a back-end key control user funds.
Front-end security
Front ends are a frequent attack path. DNS hijacks and compromised dependencies have redirected users to malicious contracts. Lock domain registrars with strong account security, pin and audit dependencies, use content security policies, and consider publishing a verifiable build hosted on IPFS as a fallback.
Integration risk
When your app routes deposits into someone else's protocol, your users carry that protocol's risk. Build an integration policy:
- Integrate only audited protocols with a track record, and record which version and addresses you use.
- Read their admin powers. A protocol that can be upgraded by a single key is a risk to your users.
- Monitor for pauses, oracle anomalies and large outflows; have a way to stop routing new funds quickly.
- Show users which protocols their funds touch.
Maintenance is part of the product
A DeFi app is never finished. Protocols you integrate release new versions and deprecate old ones, tokens migrate (as Polygon's MATIC did to POL), chains upgrade, RPC providers change limits, and wallet libraries ship breaking changes. Budget an ongoing engineering allocation, commonly a meaningful fraction of the original team, for upgrades, dependency patches and monitoring. Apps that launch and then go unmaintained become dangerous: stale integrations can route users into deprecated or paused contracts, and unpatched front-end dependencies are an open door.
The build process
- Discovery. Define the user, the job to be done and the revenue model. Decide which protocols to integrate and on which chains.
- Technical design. Wallet strategy, indexing approach, any contracts needed, and a threat model covering front end, back end and integrations.
- Prototype against testnets or mainnet forks with real protocol state, so you see true gas costs and edge cases.
- Build and test. End-to-end tests that execute real transactions on a fork, plus unit tests for any contracts.
- Review. Audit any contracts; have the front end and infrastructure reviewed for supply-chain and key-management risks.
- Launch and operate. Monitoring, incident runbooks, support and regular dependency updates.
Cost drivers
As a reasoned estimate, an integration-first app with a polished web front end, an indexer and no custom contracts might take a product designer, two front-end or full-stack engineers and a part-time blockchain engineer around 10 to 16 weeks. At blended rates of $80 to $160 per hour, that is roughly 1,400 to 2,250 hours (three and a half people at 40 hours a week), or about $110,000 to $360,000. Adding custom contracts, mobile apps or multiple chains raises it.
| Driver | Effect |
|---|---|
| Custom smart contracts | Adds contract engineering and audit cost, plus longer timelines |
| Number of chains | Each chain adds RPC, indexing, testing and token-list work |
| Embedded wallets and gas sponsorship | Smoother onboarding; adds provider fees and paymaster funding |
| Native mobile apps | Separate builds, app-store review policies on crypto features |
| Compliance features | Address screening, geo-restrictions, KYC for fiat ramps |
| Analytics depth | Accurate PnL and APY across protocols takes significant indexing work |
How to evaluate a development team
- Look at shipped products you can use today. Connect a wallet and try them; notice whether transactions are simulated and approvals are sane.
- Ask about their integration process: how they evaluate a protocol's risk and how they monitor it after launch.
- Ask who owns what. You should own the repositories, domains, deployer keys and cloud accounts from day one.
- Check security habits: dependency pinning, CI, secrets management, how they handle keeper keys.
- Insist on independent audits for any contract, by a firm not affiliated with the developers. See the guide to DeFi contract work for what to expect there.
- Be wary of guarantees. Promised TVL, users or token prices are not something a development team can honestly offer.
Frequently asked questions
Do I need my own smart contracts to build a DeFi app?
Often not. Many apps simply construct transactions against existing protocols. You need contracts when you want to bundle several steps atomically, charge fees on-chain, or hold pooled positions such as a vault.
Which chains should a DeFi app support first?
The ones where your target protocols and users already are. For many consumer apps that is one or two Ethereum rollups plus mainnet; expand once the first deployment is stable.
How do DeFi apps make money?
Integrator fees on swaps, performance or management fees on vaults, spreads on fiat ramps, subscriptions for analytics, or referral arrangements with protocols. Disclose all fees to users.
Can a DeFi app be non-custodial and still have email login?
Yes. Embedded wallet providers and smart accounts can tie a self-custody key to email or passkeys using MPC or secure enclaves. Understand each provider's recovery model and what happens if it shuts down.
What are the main risks for an integration-first app?
Upstream protocol exploits, compromised front ends or dependencies, and misleading displays of yield or risk. Monitoring and honest UI address most of them.
How is a DeFi app different from a general dApp?
It moves money, so transaction safety, simulation, approvals and integration risk matter far more. The Web3 dApp guide covers general dApp architecture.