Web3 software development: the process from spec to mainnet

Web3 software development follows the same arc as any product build, with one big difference. Once a contract holds user funds, most mistakes are permanent and public. So the process puts far more weight on the steps before mainnet (written specs, invariant tests, testnet runs, an external audit) and on the operations after it (multisig control, monitoring, incident response, careful upgrades). Below is the process we use, phase by phase, with the output each phase should leave behind.

If you are a founder, you don't need to run these steps yourself. You do need to know they exist, so you can tell when a team skips one.

The phases at a glance

These overlap in practice. Frontend work often starts during the spec, and audit booking should happen during the build, because good auditors are often booked weeks ahead. Build and audit are the big budget line items, but skipping the cheap phases is what makes them expensive.

1. Discovery and threat model

Discovery answers two questions: what are we building, and how could it go wrong? The first half looks like any product discovery: users, the core flow, what success looks like for the first version. For an MVP, the key output is a short list of what you will not build yet.

The second half is specific to Web3. Write a threat model before anyone writes code. List:

• What assets the system holds or controls, and the maximum value at risk
• Every privileged role (owner, admin, pauser, oracle updater, upgrader) and who holds it
• External dependencies such as oracles, bridges, other protocols and RPC providers
• What an attacker gains by breaking each part

This is where you should look at what actually breaks in production. The OWASP Smart Contract Top 10 for 2026 ranks access control first, business logic second and price oracle manipulation third. All three are design problems. You fix them in discovery and spec, not in the audit.

Discovery also settles the chain and language. That is a bigger decision than it looks, since it fixes your tooling, your hiring pool and your audit market. See which blockchain to build on for a decision framework.

2. Specification

Teams that skip a written spec usually pay for it during the audit, when the auditor asks what a function is supposed to do and nobody can answer in one sentence.

A useful contract spec has:

• State and flows. Every user action, what it changes and what it emits.
• A permissions matrix. Who can call what, with a timelock or without, and how roles are granted and revoked.
• Invariants. Statements that must always be true. "The sum of user balances equals total supply." "A position can be liquidated only if its health factor is below 1." "Nobody but the timelock can change the fee." These become your invariant tests later, and auditors love them.
• Upgrade policy. Is the system upgradeable? Who can upgrade, with what delay? If you haven't decided, read our post on upgradeable smart contracts before you do.
• Off-chain parts. Indexer, backend, keepers, relayers, and what happens when they go down.

Keep the spec short enough that people actually read it. Ten pages is plenty for most MVPs.

3. Build and test

Most EVM teams now build with Foundry. In the Solidity Developer Survey 2025, 57% of respondents named Foundry as their primary framework and 33% used Hardhat. Hardhat 3 added native Solidity tests that follow Foundry conventions, including fuzz and invariant tests, so the two are closer than they used to be. Either works. Pick one and stick with it.

What matters is the test pyramid:

1. Unit tests for each function, including failure paths and access control.
2. Fuzz tests that throw random inputs at functions, especially anything with math.
3. Invariant tests that run random sequences of actions and check the invariants from your spec after each one. This is where real bugs show up.
4. Fork tests against a copy of mainnet state when you integrate with other protocols. Mocks of Uniswap or Aave lie in ways the real contracts don't.
5. Static analysis in CI, such as Slither, so obvious issues never reach review.

Use audited libraries wherever you can. Writing your own ERC-20 or access control in 2026 is a cost with no upside.

The frontend and indexer get built in parallel against a local node. Our guide on how to build a dApp lists the current stack for those layers.

Something changed recently. Since Ethereum's Pectra upgrade activated on May 7, 2025, EIP-7702 lets ordinary accounts delegate to contract code. The EIP itself warns that this can break reentrancy guards of the style require(tx.origin == msg.sender). If your code or a dependency uses "is this caller an EOA?" checks, replace them now.

4. Testnet and internal review

Deploy to a public testnet with the same scripts you will use on mainnet. On Ethereum, use Sepolia for application testing. Holesky was deprecated in September 2025, and Hoodi is aimed at validator and staking testing. Most L2s and alt-L1s run their own testnets.

Use this phase for:

• Integration testing. Real wallets, the real frontend, the real indexer, testnet RPC latency.
• A bug bash. Give the team and a few outsiders a day to break it. Pay a small bounty per issue.
• Internal review. A senior engineer who did not write the code reads every line against the spec. This catches a lot of findings before you pay an auditor to find them.
• Deployment rehearsal. Run the full deployment and the handover to multisig, then write down exactly what happened.

5. External audit and fixes

Freeze the code at a tagged commit, then send it to the auditor with the spec, the threat model and the test suite. Our smart contract audit checklist lists what to prepare. The better the package, the more time the auditor spends on real logic instead of figuring out what you meant.

Plan for three steps, not one: the audit itself, your fixes, and a re-review of those fixes. Fixes introduce bugs too. Any change made after the re-review should go back to the auditor, however small.

For larger protocols, consider a second audit from a different firm or a public audit contest after the first audit. Different reviewers find different things. Our security ROI analysis covers when a second audit pays off.

6. Mainnet deployment

A good mainnet deployment is boring. It should look exactly like the testnet rehearsal.

• Scripted and reviewed. Deployment runs from a script in the repo, reviewed like any other code. No hand-typed constructor arguments.
• Matches the audit. The deployed bytecode comes from the audited commit. Record the commit hash in the deployment notes.
• Verified source. Every contract is verified on the block explorer on the day of deployment.
• Ownership moved. Admin roles go to a multisig, such as a Safe, with signers on separate hardware wallets, and sensitive actions sit behind a timelock. The deployer key keeps no privileges.
• Signing discipline. Signers check transaction data on the hardware device, not only in the web interface. The 2025 Bybit theft happened after attackers modified the Safe{Wallet} frontend so signers approved a malicious contract upgrade.
• Guarded launch. Start with deposit caps, a limited set of assets or an allowlist, and raise limits as the system proves itself. A bug found at a $500k cap costs far less than one found at $50M.

7. Monitoring and operations

From launch day, someone should know within minutes if something odd happens. Set up:

• On-chain monitoring. Alerts for admin actions, large withdrawals, oracle deviations, paused states and failed transactions. OpenZeppelin kept hosted Defender running only until July 1, 2026 and points users to its open source Monitor and Relayer, so older plans built around Defender need a self-hosted or alternative setup.
• Off-chain monitoring. RPC errors, indexer lag, frontend uptime, and error tracking in the app.
• An incident runbook. Who can pause, how to reach signers at 3am on a Sunday, who talks to users, and what the first hour looks like. Run a drill once.
• A bug bounty. Immunefi's standard scales critical rewards at 10% of funds at risk. Many protocols also adopt the SEAL Safe Harbor framework so whitehats can legally rescue funds during an active exploit.

8. Upgrades and maintenance

Contracts don't need dependency updates the way web apps do, but they still need maintenance. Chains change: new opcodes, new account types like EIP-7702, gas repricing. Integrations change too. The protocols you depend on upgrade, oracles deprecate feeds, bridges migrate.

Treat every upgrade as a small version of the full process: spec the change, test it including storage layout checks for proxies, get a diff audit, deploy through the timelock, and tell users before it executes. If you have a DAO, the upgrade also goes through governance, which is a reason to keep the upgrade surface small from the start.

At some point the right move may be to stop upgrading. One common approach is to remove upgrade rights from core contracts once they are stable and ship new versions as separate deployments. Decide what would justify that for you, and write it in the spec.

Where teams usually cut corners

In our experience, the steps that get skipped most often are:

• Invariant tests, because unit tests "pass"
• The re-review after audit fixes
• Moving admin roles to a multisig before launch, not after
• Monitoring and the incident runbook, because launch week is busy

Each of these is cheap compared to the cost of skipping it. If a team proposes a plan without them, ask why.

FAQ

How long does Web3 software development take?

For an MVP-sized protocol with an external audit, our planning estimate is roughly 3 to 6 months from discovery to mainnet. Simple token or NFT projects are faster. Complex DeFi takes longer, mostly because of testing and audit time.

What is the difference between Web3 and traditional software development?

The build steps look similar. The difference is that deployed contracts are hard or impossible to change and hold real money, so specs, testing, audits and key management carry much more weight. You also depend on public infrastructure you don't control.

Which testnet should I use for Ethereum development in 2026?

Sepolia for applications. Holesky has been deprecated, and Hoodi is intended for validator and staking testing. On L2s, use that network's own testnet.

When should I book a smart contract audit?

During the build phase, several weeks before code freeze. Good auditors are often booked ahead, and an early call with them can shape what you send.

Do I need monitoring if my contracts are audited?

Yes. Audits review code at one commit. Monitoring catches what happens after launch: unusual withdrawals, oracle problems, admin key misuse and attacks that target your integrations.

Building something on-chain?

We run this process for founders from discovery through mainnet and after, including smart contract development and post-launch support. If you want a second opinion on your plan, or a team to run it, talk to us.