A decentralized application (dApp) is a product whose core rules run in smart contracts on a blockchain, with a conventional frontend and some off-chain services around it. Hiring a team to build one means buying three different skills: contract engineering, backend data infrastructure and Web3-aware frontend work. Most problems come from underestimating the first and the second.
This page is about scoping and evaluating a dApp build. For the step-by-step technical stack, see Web3 dApp development; for chain-specific builds, see Polkadot and Tron dApp guides.
What a dApp is made of
| Layer | What it does | Typical tools |
|---|---|---|
| Smart contracts | Hold assets and enforce rules; immutable or upgradeable through proxies | Solidity with Foundry or Hardhat; Rust/Anchor on Solana; Move on Sui and Aptos |
| Indexer | Turns contract events into queryable data (balances, histories, leaderboards) | The Graph subgraphs, Ponder, Envio, or a custom indexer on Postgres |
| RPC access | Reads chain state and submits transactions | Managed node providers, ideally two for failover |
| Frontend | Connects wallets, builds and simulates transactions, shows state | React or Next.js with viem and wagmi; wallet connection kits supporting WalletConnect |
| Off-chain services | Notifications, price feeds for display, signatures for allowlists, KYC where required | Normal backend stack plus oracles such as Chainlink for on-chain data |
| Hosting | Serves the app | Conventional CDN, and optionally an IPFS-pinned build for censorship resistance |
"Decentralized" is a spectrum. Most dApps have a centralized frontend, indexer and admin keys. That is acceptable if you are honest about it and minimize what those components can do to user funds.
Scoping questions to answer first
- What must be trustless? Custody of user funds and settlement usually belong on-chain. Search, profiles and analytics usually do not.
- Which chain and why? Users, liquidity and wallets you need to reach should drive the choice, not grant programs.
- Upgradeable or immutable? Upgradeability lets you fix bugs; it also lets whoever holds the admin key change the rules. Decide who holds it (multisig, timelock, governance).
- Who pays gas? Sponsoring gas with ERC-4337 paymasters improves onboarding but becomes a cost line and an abuse vector.
- Regulatory exposure? Anything that touches custody, trading, lending or token sales may need licensing in some jurisdictions.
Realistic cost and timeline
Estimates are only useful with assumptions attached. For a moderately complex EVM dApp, such as a staking or escrow product with a custom frontend:
- One senior contract engineer for 6–10 weeks, including tests.
- One backend engineer for 4–8 weeks on indexing and services.
- One frontend engineer for 6–10 weeks.
- Design, QA and project management part-time throughout.
- An external smart contract audit, usually scheduled weeks in advance, plus time to fix findings.
That puts a typical first version at roughly three to five months of calendar time. Multiply the person-weeks by your region's rates to get a budget, then add the audit. DeFi protocols with novel economic mechanisms take longer and need more review.
How to evaluate a dApp development team
- Read their contracts. Ask for public repositories or verified contracts they wrote. Look for tests, especially fuzz and invariant tests, and use of audited libraries instead of hand-rolled token logic.
- Read their audit reports. Every serious team has been audited. Look at what was found and how quickly and well it was fixed.
- Ask about key management. Who will hold deployer and admin keys during and after the project? The answer should involve a multisig such as Safe that you control.
- Ask how they handle indexing and reorgs. A team that has shipped production dApps will have opinions about finality, reorg handling and RPC failover.
- Check that you own everything. Repositories, deployer accounts, domains, RPC accounts and the indexer should be in your name.
- Be wary of "white-label in two weeks". Cloned contracts with renamed variables are a known source of exploits. Ask what was changed and whether the changes were audited.
Common failure modes
- A single externally owned account holding admin rights, then getting phished.
- Frontend showing indexer data that lags the chain, leading users to act on stale balances.
- No transaction simulation, so users sign transactions that revert and still pay gas.
- Price inputs taken from a single DEX pool, open to flash-loan manipulation.
- No plan for monitoring after launch, so an exploit is noticed on social media first.
Before committing to a full build, a short proof of concept can validate the riskiest assumption, and the smart contract development guide covers contract tooling and testing in depth.
Frequently asked questions
What is the difference between a dApp and a normal web app?
In a dApp, the critical state and rules, such as who owns what and how funds move, live in smart contracts that the developer cannot quietly change. The interface can look identical to a normal web app.
Can a dApp be fully decentralized?
Contracts can be immutable and the frontend can be served from IPFS, but most products still rely on RPC providers, indexers and domain names. Aim to make sure no single off-chain component can take user funds.
Do I need a token for my dApp?
Usually not at launch. Many dApps work entirely with existing assets like ETH or stablecoins. Add a token only if it has a clear function, and get legal advice first.
Which chain is cheapest for a dApp?
Ethereum rollups and high-throughput chains like Solana generally have low per-transaction fees. Total cost of ownership also includes tooling, auditor availability and where your users already hold assets.