How to build a DeFi app in 2024

A guide to building production DeFi apps that scale.

By Gareth on 6th Aug, 2024


Back in 2021 I joined Balancer, the popular AMM on Ethereum. I joined at a time when they had gained product market fit for the protocol but the v1 app left a lot to be desired. I was recruited to lead their frontend/product efforts and build out a v2 of the web app.

The Balancer leadership at the time were very ideological about decentralization at all layers of the stack and so pushed for the v2 app to be as decentralized as possible. What did that mean?

  • Static app - The idea being that it can more easily be deployed on decentralised file hosting networks like IPFS.
  • No API - Restricted to fetching data from Subgraphs, which were supposed to be the decentralized alternative to a caching API layer, and also onchain calls.

The thought process at the time was that we were moving towards an internet where this would be the norm for DeFi protocols and that the complexity and UX problems would reduce over time. I guess it was also thought that decentralized access points (domains) to these decentralized hosting networks would become more popular, i.e. pointing an ENS address at an IPFS hash and expecting users to access apps that way.

This did not play out.

Unfortunately, the world didn't go this way. Primarily because the technology didn't improve enough to make the UX better than a typical web2 app, in fact, it's still much worse if you try to build this way.

The critical point is that decentralizing frontends is pointless unless the access points are decentralized. I talk more about this in my post about why frontends won't be decentralized (anytime soon).

A new start

Balancer v3 gave us the opportunity to rethink everything. We looked at the decisions we'd made in the past and the disappointing results of those decisions when it came to UX. It became clear we had to ditch the decentralized frontend philosophy and build and open-source 'web2' app. By web2 I just mean leveraging web2 tech as much as possible when building a web3 app, e.g. a server-rendered app instead of a statically built app. This change in direction allowed us to pick the best tech for the job.

So with that context, here is how I would build a web3 app in 2024.

Ditch Static Apps: Decentralization theatre

Again, tl;dr; pick the best tech for the job. If the access point (domain name) is not decentralized everything else is irrelevant. For now, leverage the latest frontend tech or build with whatever allows you to optimize for UX, for us it was a server rendered Next.js app. If decentralization of all layers of the stack is important to your project then open-source the app, make it as easy to deploy as possible and write good documentation.

Keep the Frontend Dumb, Push Logic to SDK and API

In Balancer v2 we made the mistake of cramming a lot of caching and extractable logic into the frontend codebase. In self-contained web2 apps this is easier to avoid, with fairly well established patterns for separation of concerns. As with web2, the ideal is to keep the frontend as dumb as possible.

We pixel monkeys just want to make rectangles look pretty! Nothing more nothing less.

In web3 separation of concerns is a little harder to define. Generally, you also want to keep your API as dumb as possible and just cache and format onchain data there. The logic leftover needs to be carefully separated between an SDK and the frontend.

Build a protocol SDK

Move any pure logic that helps the frontend interact with the smart contracts into a protocol SDK. If it's useful for the frontend, it will be useful to other developers who may want to interact with the underlying protocol. The more you make the underlying protocol accessible to developers the greater the network effects. From a frontend dev perspective, the goal here is to extract as much isolated protocol logic as possible so that the frontend code can be really dumb.

Cache & format onchain data in an open-source API

It shouldn't be much more complicated than the title suggests. I'm not an expert on the tooling in this department but I know it's rapidly improving. Use subgraphs and or other available services to cache the raw onchain data and feed those into an API for formatting and any further data processing. Make the API open-source so that others can spin it up alongside your frontend, if decentralization is important to your protocol.

The frontend stack

Just use React

I made this mistake for v2. Vue had already been chosen when I joined Balancer to lead the v2 build-out. At the time I was more proficient with Vue than React so I was quite happy with that choice. The problem is, network effects. Like it or not Web3 is a niche tech vertical. There just aren't enough people building dev tooling in our niche to span all framework ecosystems equally, so by the law of network effects the best tooling is in the React ecosystem. It's also where the best people are for hiring, with exceptions of course.

Don't make it harder than it needs to be, just use React.

Frameworks are your friend

Don't reinvent the wheel. If you've gone with React... then go with Next.js. Use whatever framework does the most for you. There is enough engineering to do to get Web3 apps working nicely without worrying about typical web2 problems.

Component libraries, don't reinvent the wheel

Continuation of the above point. Try to minimise the time spent working on typical frontend/web2 problems like component building, so you can spend as much time as possible working on web3 flows and UX. There are plenty of challenges there that will take up your time.

Web3 tooling

As of writing this post, there are pretty clear winners in this space. Pick Viem/Wagmi as your core web3 packages, these are for interacting with your smart contracts and constructing transaction flows.

Then, pick a wallet provider that is built on top of wagmi. Two popular choices here are RainbowKit and ConnectKit. We used RainbowKit in Balancer v3 but I don't think there is a clear winner here yet.

Whatever you do, don't build your own wallet provider. It may seem simple at first but it's a Pandora’s box of edge cases.

A final comment on web3 tooling: don't forget smart accounts. This is especially true if you are building a DeFi app where your primary users are likely to be interacting with the dapp via a multi-sig like Safe.


Building a DeFi app in 2024 is still surprisingly difficult. This is especially true if your dapp is data-heavy and requires some non-trivial smart contract interactions. I expect this to get easier over the next few years but it really depends on how the wider crypto ecosystem plays out. The core problem at the moment is chain fragmentation, especially in the Ethereum ecosystem. If good chain abstraction can be achieved at the tooling layer then building mult-chain DeFi apps will become quite a bit easier. But I struggle to see how that works in practice at this point in time.

I also want to point out that nothing I've included here is groundbreaking... Most of it is just common sense choices. As engineers, it's so easy to get caught up trying to build fancy solutions. For DeFi apps the key is to really focus in on the core interactions and how you manage those, i.e. the transaction flows and presenting onchain data.

I have specifically included the year in the title of this post because I expect it to become redundant. At least I hope it does. Maybe in 2025 or 2026 there will be a common way to access fully decentralized apps and common patterns for how to build them.