How to Use Foundry to Build Ethereum Apps

Ethereum development used to feel heavier than it should have been. You’d spin up a project, install a JavaScript-based toolchain, juggle plugins, wrestle with configuration, and lose time on everything except the smart contract logic that actually matters. For founders and builders trying to move fast, that friction adds up. It slows prototyping, increases testing mistakes, and makes blockchain development feel more fragile than modern software engineering should be.

That’s exactly why Foundry has gained so much momentum. It gives Ethereum developers a faster, more opinionated, and deeply practical toolkit for writing, testing, deploying, and debugging smart contracts. If you’re building a DeFi product, NFT infrastructure, onchain game, or a startup experimenting with tokenized workflows, Foundry is one of the strongest development environments available today.

This guide breaks down how to use Foundry to build Ethereum apps in a way that’s useful for both technical founders and hands-on developers. Not just the commands, but the workflow, trade-offs, and the places where Foundry shines most.

Why Foundry Became the Default Choice for Serious Solidity Teams

Foundry is a Rust-based toolkit for Ethereum application development. Instead of relying heavily on JavaScript wrappers around smart contract workflows, Foundry gives you native tools built for speed and smart contract engineering first.

The core tools inside Foundry are straightforward:

• Forge for testing, building, and deploying smart contracts
• Cast for interacting with smart contracts, wallets, and chain data from the command line
• Anvil for running a local Ethereum node for development and testing
• Chisel for fast Solidity experimentation in a REPL-style environment

What makes Foundry especially attractive is not just performance. It’s the development philosophy. Foundry treats Solidity as a first-class language rather than making it feel like a plugin to a frontend stack. That matters when your product’s business logic lives onchain.

For startup teams, this means faster testing cycles, cleaner smart contract workflows, and fewer moving parts during early development.

Getting Foundry Running Without Overcomplicating the Stack

The installation process is refreshingly simple. On macOS or Linux, most teams start by installing Foundry using the official script, then updating the binaries.

curl -L https://foundry.paradigm.xyz | bash
foundryup

Once installed, you can create a new project with:

forge init my-ethereum-app
cd my-ethereum-app

This scaffolds a standard Foundry project with folders like:

• src/ for smart contracts
• test/ for Solidity-based tests
• script/ for deployment and scripting
• lib/ for dependencies

That structure is part of Foundry’s appeal. You can start shipping quickly without designing your toolchain from scratch.

The First Commands That Matter

Once your project is initialized, these are the commands you’ll use constantly:

• forge build to compile contracts
• forge test to run tests
• anvil to launch a local blockchain
• forge script to run deployment scripts
• cast to query chain state or interact with deployed contracts

If you’re coming from Hardhat or Truffle, the biggest shift is that the workflow feels tighter and less plugin-dependent.

Building Your First Ethereum App the Foundry Way

Let’s take a simple example: a basic smart contract that stores and updates a number. The contract goes in src/Counter.sol.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Counter {
    uint256 public number;

    function setNumber(uint256 newNumber) public {
        number = newNumber;
    }

    function increment() public {
        number++;
    }
}

Now run:

forge build

If the compile succeeds, you already have a cleaner start than many older Ethereum setups offered.

Why Solidity-Based Testing Changes the Development Experience

One of Foundry’s biggest advantages is testing in Solidity itself. Instead of bouncing between JavaScript test files and Solidity contracts, your tests can live closer to the code they verify.

Create test/Counter.t.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/Counter.sol";

contract CounterTest is Test {
    Counter counter;

    function setUp() public {
        counter = new Counter();
    }

    function test_Increment() public {
        counter.increment();
        assertEq(counter.number(), 1);
    }

    function test_SetNumber(uint256 x) public {
        counter.setNumber(x);
        assertEq(counter.number(), x);
    }
}

Then run:

forge test

This is where Foundry starts to separate itself. Tests are fast, expressive, and built with developer ergonomics in mind. You can write unit tests, fuzz tests, invariant tests, and fork-based integration tests in one environment.

Where Foundry Really Wins: Fast Feedback, Fuzzing, and Mainnet Forking

Foundry isn’t popular just because it compiles code quickly. It’s popular because it helps you catch costly mistakes before they become expensive onchain bugs.

Fuzz Testing by Default

In the earlier example, test_SetNumber(uint256 x) automatically fuzzes input values. That means Foundry tries many different values rather than only the one you hardcoded. This is powerful for startup teams building token logic, vault mechanics, access controls, or financial contracts where edge cases matter.

For Web3 products, input unpredictability is normal. Fuzzing helps developers think beyond the happy path.

Mainnet Forking for Realistic Simulations

One of Foundry’s strongest capabilities is mainnet forking. You can fork Ethereum mainnet or other EVM-compatible chains locally and test your contracts against real deployed protocols, token balances, and liquidity conditions.

That is incredibly useful if your app interacts with:

• Uniswap pools
• Aave lending markets
• existing ERC-20 tokens
• live multisig wallets
• production governance contracts

Instead of mocking half the ecosystem, you can test against actual state. For a startup integrating into existing DeFi infrastructure, this reduces blind spots significantly.

Cheatcodes That Make Smart Contract Testing More Practical

Foundry includes testing utilities known as cheatcodes. These let you manipulate the EVM environment in ways that make testing realistic and efficient. You can impersonate accounts, warp time, adjust block numbers, expect reverts, and inspect emitted events.

That means you can model user behavior, admin controls, token vesting, staking durations, and attack scenarios without writing huge amounts of custom boilerplate.

From Local Development to Deployment Without the Mess

Once your contracts compile and your tests are stable, the next step is deployment. Foundry handles this through scripts written in Solidity or using command-line options.

A typical local workflow looks like this:

1. Start a local chain with Anvil
2. Deploy contracts using a Forge script
3. Interact with the deployed contract using Cast
4. Repeat quickly as you refine the product

Running a Local Node with Anvil

anvil

This gives you a local EVM node with funded development accounts. It’s ideal for rapid contract iteration and frontend integration before moving to a public testnet.

Writing a Deployment Script

In script/DeployCounter.s.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Script.sol";
import "../src/Counter.sol";

contract DeployCounter is Script {
    function run() external {
        vm.startBroadcast();
        new Counter();
        vm.stopBroadcast();
    }
}

Then deploy locally:

forge script script/DeployCounter.s.sol --rpc-url http://127.0.0.1:8545 --broadcast

This pattern scales from local development to testnet and mainnet deployment. In practice, teams usually manage private keys and RPC URLs through environment variables for security and portability.

Using Cast for Fast Contract Interaction

After deployment, Cast lets you interact from the terminal without building a UI first. You can read contract state, send transactions, convert units, inspect calldata, and query wallet balances.

For startup builders validating a contract quickly, that matters. You don’t need to wait for the frontend to be polished before confirming the protocol logic works.

How Real Ethereum App Teams Use Foundry in Production Workflows

Foundry works best when it becomes part of a broader engineering workflow rather than a standalone dev toy.

A practical startup workflow often looks like this:

• Write and iterate on contracts in src/
• Build fast unit and fuzz tests in test/
• Use mainnet forks to validate real protocol interactions
• Run deployment scripts for staging and production environments
• Use CI pipelines to run forge test automatically
• Connect a frontend built in React, Next.js, or another stack using ethers.js or viem

Foundry does not replace your frontend stack. It strengthens the onchain layer so your application logic is better tested, easier to reason about, and less dependent on fragile custom setup.

That’s especially important for teams building products where one contract bug can undermine user trust or lock funds permanently.

Where Foundry Falls Short and When Another Stack Might Be Better

Foundry is excellent, but it’s not universally perfect.

First, teams deeply invested in JavaScript-centric workflows may find Hardhat more familiar, especially if they rely heavily on JS plugins or existing Node-based scripts. Second, frontend-heavy teams with minimal Solidity complexity sometimes don’t need the full power Foundry brings.

There are also onboarding considerations. Solidity-native testing is elegant, but it can feel unfamiliar to developers who expect every test and script to live in TypeScript. Some teams prefer keeping everything in one language layer outside the contracts.

Foundry also assumes a certain level of engineering seriousness. That’s a positive in production environments, but for non-technical founders trying to “click together” a blockchain MVP with no in-house smart contract expertise, it won’t magically remove the complexity of building on Ethereum.

In other words: Foundry reduces tooling friction, not product risk.

Expert Insight from Ali Hajimohamadi

For founders, Foundry is most valuable when smart contracts are not just a feature, but part of the startup’s strategic core. If your product depends on token logic, protocol integrations, treasury mechanics, or onchain automation, then your contract development environment should be treated as core infrastructure. In that context, Foundry is a strong choice because it encourages engineering discipline early.

The founders who should lean into Foundry are the ones building products where contract correctness directly affects trust, liquidity, or user funds. DeFi teams, onchain coordination tools, infrastructure startups, and crypto-native B2B platforms are obvious candidates. These teams benefit from fast testing, forked simulations, and a more production-ready development workflow.

Where founders should be more cautious is when blockchain is still experimental inside the business model. If you’re only testing lightweight tokenization ideas or shipping a simple proof of concept around wallet connectivity, Foundry may be more than you need on day one. In that case, the bigger question is not “which tool is best,” but “is smart contract complexity justified yet?”

A common mistake is assuming that a modern toolchain makes blockchain development safe by default. It doesn’t. Foundry helps teams test better, but it does not replace audits, threat modeling, or product judgment. Another misconception is that developers should optimize for stack popularity instead of team capability. The right move for a startup is the toolchain your team can operate reliably under pressure.

The most strategic use of Foundry is not just writing contracts faster. It’s building a culture where onchain logic is validated rigorously before users ever touch it. That mindset matters far more than choosing the trendiest framework.

Key Takeaways

• Foundry is a fast, Rust-based Ethereum development toolkit centered on serious smart contract workflows.
• Its core tools—Forge, Cast, Anvil, and Chisel—cover testing, deployment, chain interaction, and experimentation.
• Foundry’s biggest strengths are speed, Solidity-native testing, fuzzing, cheatcodes, and mainnet forking.
• It is especially well suited for DeFi, infrastructure, and products where onchain logic is central to the business.
• It may be less ideal for teams that are heavily dependent on JavaScript plugins or are only exploring very lightweight blockchain features.
• Foundry improves development quality, but it does not remove the need for audits, security reviews, and careful product design.

Foundry at a Glance

Useful Links

• Foundry Book (Official Documentation)
• Foundry GitHub Repository
• Foundry Official Website
• Forge Documentation
• Cast Documentation
• Anvil Documentation