How to build a dApp in 2026: the stack, step by step

To build a dApp, you write smart contracts for the logic that must be trustless, deploy them to a chain, and build a regular web frontend that talks to those contracts through a wallet. Around that core sit three supporting layers that most tutorials skip: an RPC provider to read and write chain data, an indexer to query history fast, and hosting for the frontend. In 2026 a typical EVM stack is Solidity with Foundry, a React frontend with viem and wagmi, an embedded or connected wallet, a paid RPC provider and an indexer such as Ponder or a subgraph.

Here is how we put those pieces together, and where the real choices are.

What a dApp actually is

A dApp is mostly a normal web app. The difference is where state and rules live.

• Smart contracts hold the state and rules that users must be able to trust without trusting you: balances, ownership, trades, votes.
• The frontend reads contract state, builds transactions and asks the user's wallet to sign them.
• The wallet holds the user's keys and signs. Your app never sees a private key.
• RPC nodes are how your frontend and backend talk to the chain.
• The indexer turns raw events into a database you can query, because reading history straight from RPC is slow and expensive.
• A backend, if you need one, handles anything that does not need to be on-chain: notifications, search, off-chain order books, keepers that trigger time-based actions.

A common early mistake is putting too much on-chain. If a piece of data doesn't need to be trustless, keep it off-chain. You will save gas, audit scope and time.

Step 1: pick the chain and the VM

The chain decides your language, tooling, wallet ecosystem and where your users and liquidity are. The short version:

• EVM chains (Ethereum, its L2s, HyperEVM and many others) use Solidity, with the largest pool of developers, libraries and auditors.
• Solana uses Rust programs, usually with the Anchor framework, and has its own wallet and tooling ecosystem.
• Others such as Move chains, Cosmos chains with CosmWasm, or Arbitrum Stylus for Rust on an EVM chain, make sense for specific needs.

We wrote a full decision framework in which blockchain to build on, and the language side in Rust vs Solidity. For the rest of this post we cover EVM in detail and note the Solana equivalents.

Step 2: write and test the contracts

On EVM, use Foundry or Hardhat. Foundry is now the default. In the Solidity Developer Survey 2025, 57% of respondents used it as their primary framework, against 33% for Hardhat. Foundry's tests are written in Solidity, it is fast, and it ships Anvil for a local node and Cast for command-line calls. Hardhat 3 closed much of the gap by adding Solidity tests compatible with Foundry conventions, and it is still a good choice if your team prefers a TypeScript-first plugin setup. Our pick for a new project is Foundry, with TypeScript scripts only where they make things easier.

On Solana, use Anchor. Anchor is a framework that gives you a Rust eDSL, an IDL and a TypeScript client, which removes a lot of the boilerplate of native Solana programs. It reached 1.0 and has had patch releases since, including a fix for a high-severity CVE in 1.0.0 affecting System Program ID checks, so pin a current version.

Whatever the chain:

• Start from audited libraries such as OpenZeppelin Contracts for tokens, access control and upgrades.
• Write unit, fuzz and invariant tests. Invariant tests are where you find the bugs that matter.
• Keep contracts small. Every line is audit scope, and audit scope is money.

Step 3: build the frontend

The frontend is a normal web app. Next.js or Vite with React is the usual choice, and nothing about Web3 forces you off it.

For chain access on EVM:

• viem is the low-level TypeScript library for reading contracts, encoding calls and sending transactions. We use it instead of ethers.js on new projects.
• wagmi wraps viem in React hooks for accounts, reads, writes and transaction status, with caching through TanStack Query.

Generate typed contract bindings from your ABIs, so a renamed function breaks the build instead of production.

On Solana, the current JavaScript SDK is Solana Kit, the renamed web3.js 2.0, with Anchor's generated client for your own programs.

Spend real time on transaction UX: pending states, failed transactions, wrong network, insufficient gas, and what the user sees while a transaction confirms. In our experience this is where dApps lose users, not in the contracts.

Step 4: choose how users get a wallet

This is the decision that most affects conversion. You have three options, and many apps combine them.

Embedded wallets are now mainstream infrastructure. Stripe acquired Privy in 2025, whose wallets are generated for each user at signup. Smart accounts got a boost when Ethereum's Pectra upgrade went live on May 7, 2025 with EIP-7702, which lets existing accounts delegate to smart contract code. Wallets that support EIP-5792 can take several calls as one atomic batch, so "approve, then swap" becomes one click.

Our recommendation for consumer products is an embedded wallet with gas sponsorship for the first actions, plus a "connect wallet" option for users who already have one. For DeFi aimed at existing crypto users, a good connector is enough to start. Our post on account abstraction goes deeper.

Step 5: set up RPC

Every read and write goes through an RPC node. Public endpoints are fine for development and bad for production. They rate-limit, they go down and they give no guarantees.

For production:

• Use at least one paid provider (Alchemy, QuickNode and Infura on EVM, Helius and others on Solana), and configure a fallback provider in viem so one outage doesn't take you down.
• Keep API keys for heavy or write operations on your backend, not in the browser bundle. Restrict browser keys by domain.
• Watch your request volume. A frontend that polls every block for every user gets expensive fast. Most of that polling should be served by your indexer instead.

Step 6: add an indexer

Your contracts emit events. An indexer listens to them and writes them into a database your app can query: a user's history, a leaderboard, a list of pools with their current stats. Without one, you end up making hundreds of RPC calls to render a single page.

Main options in 2026:

• The Graph subgraphs, hosted on its decentralized network or through providers like Goldsky.
• Ponder, a TypeScript indexing framework you run yourself, with type safety built on viem and reorg handling.
• Envio, Subsquid (SQD) and similar managed or hybrid options, worth comparing if you index many chains.
• Custom, when you need very low latency or unusual data. It is more work than it looks because of reorgs and backfills.

Our default for a new EVM product is Ponder or a subgraph, depending on whether the team wants to run infrastructure. We compare them properly in blockchain indexers: The Graph vs custom.

Step 7: decide on a backend

Many dApps need a small backend even if the core logic is on-chain. Typical jobs:

• Keepers or bots that trigger time-based or condition-based transactions
• Signing off-chain messages, such as allowlist signatures or EIP-712 orders
• Notifications, email and push
• Search, recommendations and anything else that would be absurd to put on-chain
• Relaying sponsored transactions, if your wallet provider doesn't do it for you

Keep anything that holds a key with privileges on-chain to a minimum, and treat those keys like production secrets.

Step 8: host the frontend

Two realistic choices:

• Standard web hosting (Vercel, Cloudflare, your own servers). Fast, simple, good for SEO. The risk is that the frontend is a central point an attacker can tamper with.
• IPFS or similar content-addressed hosting, often with an ENS name. Harder to tamper with silently and harder to take down. Slower to update, and you lose some server-side features.

Many teams do both: a normal deployment for most users and an IPFS build as a fallback. Either way, protect your DNS and hosting accounts with hardware keys. A hijacked frontend can drain users without anyone touching your contracts.

A reference stack

This is a starting point, not a rule. Every layer can change based on what your product needs.

From working prototype to mainnet

Getting a dApp working on a testnet takes days. Getting it safe for real money takes the rest: specs, invariant tests, an audit, a multisig, monitoring. We describe that path in our Web3 software development process.

FAQ

What programming language do I need to build a dApp?

Solidity for contracts on EVM chains, or Rust for Solana and some other chains. The frontend is TypeScript, usually React. Most dApp code by volume is TypeScript.

Is Foundry or Hardhat better in 2026?

Foundry is the more common primary framework and our default. Hardhat 3 supports Solidity tests too and suits teams that prefer TypeScript tooling. Both are fine for production.

How much does it cost to build a dApp?

It depends on the contracts' complexity and whether you need an audit. A simple contract set with a standard frontend is a small project. A DeFi protocol with custom math, an indexer and two audits is a large one.

Do I need a backend for a dApp?

Often a small one, for indexing, notifications, keepers or sponsored transactions. The trustless logic stays in contracts.

Can I build a dApp without users installing a wallet?

Yes. Embedded wallets create a wallet when the user signs up with email or a social account, and smart accounts let you pay gas for them.

How long does it take to build a dApp?

A testnet prototype can take a few weeks. In our planning estimates, an audited production dApp usually takes a few months, with testing and audits taking a large share of that time.

Build it with us

We build decentralized applications end to end, from contracts to frontend, wallets and indexers. If you want help choosing your stack or a team to ship it, get in touch.