DAO tooling is all the rage these days.

But there are definitely some challenges.

This post shares some thoughts on DAO tooling based on my experience as a member of multiple DAOs, building DAO tooling at Mirror, and working closely with DAO operators over the past year.

First, let’s look at some of the challenges.

“DAOs” aren’t a market

Saying you’re building DAO tooling is like saying you’re building tools for corporations. It doesn’t really mean anything. There are protocol DAOs, social DAOs, NFT collector DAOs, service DAOs, grant DAOs, and more.

So the first step in building DAO tooling is to clearly define the target audience.

DAOs needs vary

Most DAOs share the same core components:

• Funding mechanism to bootstrap a treasury and issue membership. Usually a crowdfund, NFT drop, or token sale.

• A multi-sig to store assets and authorize transactions. Usually a Gnosis Safe (if building on Ethereum).

• Group chat so members can communicate. Usually Discord or Telegram.

• Governance process to make strategic decisions like how to diversify the treasury, compensation plan, org structure, etc.

• DAO operations teams to handle contributor onboarding, payroll, treasury management, marketing / comms, etc.

But depending on the type of DAO you’re building for, they’ll most likely prioritize completely different feature sets which impacts the product roadmap. A few examples:

• Protocol DAOs. Prioritize security and transparency. For key activities like governance, protocol DAOs tend to prefer on-chain protocols instead of UIs that just write to a database. Protocol DAOs have treasuries worth tens of millions, and some in the hundreds of millions. Because these are decentralized organizations, redistributing these funds for investments, compensation, grants, etc. requires the security, transparency, and automation of smart contracts. Building for protocol DAOs requires a highly technical team that’s comfortable shipping production code in adversarial and risky environments.

• Social DAOs. Prioritize active communication between members. Love it or hate it, Discord is currently the tool of choice for social DAOs. However, many DAO tooling projects are trying to build “web3-native Discord” by starting with token gated chat functionality. I doubt a project can differentiate enough by starting with token gated chat features since Discord already does this pretty well and has strong network effects. Instead, I think projects should focus on building a useful single-player tool for DAO members (i.e., a feed of on-chain activity, NFT drop tooling, custom governance product, contributor directory, project updates via a feed and email, etc.), use the single-player tool to aggregate a critical mass of DAO members, and then layer in social features like messaging, social graphs, and notifications to build a network that could eventually rival Discord.

• NFT collector DAOs. Prioritize mechanisms for adding funds to their treasury, governance tooling for investment decisions and easily coordinating to allocate funds. Most NFT collector DAOs on Ethereum use Gnosis multi-sigs to secure their crypto assets. An area of opportunity is building a social app to ease coordination between collectors and also implement abstractions on top of Gnosis multi-sigs to automate how funds are distributed. For example, it’d be cool if community members voted on a governance proposal to sweep the Squiggles floor if it reaches 5 ETH and if the proposal passes, the tool queues up a transaction that’s automatically submitted if the criteria is met within a specified time period. The Gnosis SafeSnap module makes this easier to execute. As we’ve seen with financial flash mobs like Constitution DAO, Mirror crowdfunds, and PartyBid, there’s a fast growing market of people interested in collective ownership over blockchain-based assets, they just need tooling that meets their specific needs.

It’s challenging to build a generic DAO tool because different DAOs prioritize different features. So narrow the focus, become the dominant solution for a specific use case, then expand from there.

For some inspiration, here’s a great overview of the current DAO tooling landscape for specific use cases.

There’s no clear business models (yet)

If your DAO tool is a protocol (i.e., smart contracts deployed to a blockchain network), the obvious business model is an on-chain transaction fee. But most DAO tools are just UIs that write to a database. For the latter, there aren’t clear business models yet.

You could integrate Stripe and take a fiat transaction fee but many DAOs aren’t incorporated and don’t have a bank account which could limit your potential market size. The other downside of a fiat transaction fee is that you don’t generate on-chain revenue which will limit your ability to eventually deploy a protocol, launch a token, and give ownership to community members. This is a long-term risk that will be difficult to integrate if you don’t start with the right technical and cultural foundation.

Although there aren’t any best practices yet, there are a few potential ways that DAO tools could monetize such as a monthly fee in USDC, an NFT subscription, or a utility token.

I think the lack of clear business models for DAO tools is a near-term concern that will eventually be solved. Especially as more activity and computation moves to L2s and low-transaction fee blockchains which will enable new creative ways for projects to monetize on-chain.

Everyone is competing over the same handful of legitimate DAOs

Although many people can agree that DAOs have long-term potential, the reality today is…

There just aren’t that many legit DAOs out there yet. Most DAOs are just for the lolz and don’t care about becoming long-term projects. When a new DAO tool launches, you usually see the same three to five DAO logos presented as customers on the landing page. I also think this is mostly a near-term concern that will eventually be solved as it becomes easier to start, manage, and scale DAOs.

Regardless, if you’re building a DAO tool today, you should think deeply about your go-to-market strategy. This could include having a well-known DAO operator on the founding team, taking investment from high profile DAOs and DAO operators, building biz dev partnerships, issuing token incentives, etc.

Once you’ve acquired the initial set of target DAOs and built a product that keeps them highly engaged and retained, it probably makes sense to focus on features that make it easier to start the type of DAO you’re focused on so you can expand your market instead of just increasing revenue from a limited set of customers.

---

Although there are challenges with building DAO tooling, I still think there’s tons of opportunity if you’re thoughtful. Here’s some high-level guiding principles based on what I’ve seen work:

Start with services

When every DAO tool is competing over the same handful of DAOs, you need a distribution advantage. One of my favorite approaches is to start by providing services to different DAOs so you can develop expertise in a specific domain, build relationships with core teams, and eventually productize your service. A great example is Llama DAO.

They started off as a small team submitting governance proposals on treasury management for top DAOs like Uniswap, AAVE, Gitcoin, and FWB. Pretty soon, they became the go-to experts in treasury management. They also built a community of high-quality contributors, grew deep relationships with all the top protocol DAOs, and are now productizing their services through their own protocol. In the services phase, engage in DAO governance forums, contribute to working groups, apply for grants, execute bounties, submit pull requests, build Dune dashboards, publish proposals. Do whatever it takes to start developing relationships and expertise to inform how you productize your services.

And pls don’t be this type of DAO tooling founder.

Dominate a niche

As seen earlier, DAOs needs vary. Depending on the type of DAO you’re targeting, they’ll have different requirements across protocol, interface, feature set, marketing, biz dev, and more. Instead of building a mediocre product for a wide initial market, build the default product for a very specific domain. To do so, think about your positioning vertically and horizontally.

Vertical focus would be a specific type of DAO (e.g., protocol DAO, social DAO, NFT collector DAO, etc.). Horizontal focus would be a specific tool for different types of DAOs (e.g., governance, treasury management, payroll, contributor onboarding, etc.)

To start, I’d build something at the intersection of one vertical focus and one horizontal focus (i.e., governance for protocol DAOs or contributor onboarding for social DAOs). Consider this your strategic starting point. Your first milestone is to become the default product in this market. If your DAO tool is a networked product (e.g., social app, marketplace, collaboration tool), focus on liquidity over scale early on.

In this context, liquidity refers to the quality of experience a user has when engaging with the product. In networked products, liquidity usually depends on the number of other relevant users engaging with the product. For example, if you’re building a DAO social app, the quality of experience is determined by whether people engage with the content you post and whether there is enough interesting content to engage with. Collaboration tools are similar.

A recent example is how Clubhouse started off with just one audio room where everyone was a designated speaker and consisted primarily of Silicon Valley founders, operators, and investors. Every time someone opened the app, a Slack notification was sent to the Clubhouse founders and one of them would rush to open the app and greet them in the audio room. As more people joined, there would usually be at least a few relevant people in the audio room to chat with. This created liquidity and ensured most people had a good experience when using the app. Over time, Clubhouse created separate roles for speakers and listeners, allowed people to create their own rooms, and expanded to other networks outside of Silicon Valley. Many networked products start off with this constrained approach to drive liquidity (e.g., Facebook and Tinder with college students, Amazon with books, Uber and AirBnB expanding on a city by city basis, etc.).

Most networked products don’t need massive scale early on, they just need a minimum viable network for a specific market so the initial users have a great experience. So think about your strategic starting point, liquidity, what drives it, and how you can measure it before scaling.

From there, you can expand by providing adjacent tooling and / or distributing to different types of DAOs.

Focus on retention and biz dev

Once you’ve defined your initial market and what drives liquidity, you can start thinking more deeply about product and distribution.

On the product side, you should be laser focused on improving existing features and adding new features that keep your initial set of users and DAOs engaging with the product on a recurring basis. If they continue using your product, great! How engaged are they? How does it compare to other products? If not, are they using another product? Why? Do they need a new feature? Are existing features not working? Are they using any product for this use case? If not, maybe this isn’t a core problem for them. Observe customer behavior, gather feedback, and understand the broader market. Also, think about your product’s hierarchy of engagement and build engagement loops so each time a user engages, it leads to a) further engagement in the future and b) more engagement from other users.

Many times, engagement loops are driven by social features like follow graphs, a feed, profile pages, notifications, etc. which are scalable ways to keep users coming back on a recurring basis.

Here’s an example of a social engagement loop.

And a more detailed look.

Once you’ve mapped out your core engagement loops, identify which steps you want to prioritize, iterate, and layer in other engagement loops to strengthen your network. It’s also important to think about how you can build these features in a way that optimizes for composability across the web3 ecosystem. For example, storing content on a decentralized storage protocol and encoding social graph relationships as NFTs. Building in this way allows you to create a protocol that other projects can integrate with for their own use cases which helps the ecosystem and drives growth for your protocol.

On the distribution side, onboarding a DAO is more like enterprise sales than bottoms-up adoption. This is because most DAO tools today are coordination tools. Whether it’s for governance, compensation, communication, transaction management, etc. the tool usually needs buy-in from a specific working group or a few core team members before it can be adopted. Because of this, start by targeting two or three top DAOs in your defined market. Get in touch with the decision makers. Work closely with them. If you solve their needs and make them happy customers, they’ll refer the next batch of DAOs and you’ll be off and running. Remember, liquidity over scale early on.

Grow the market

At a super high level, there are two ways to grow a DAO tool:

• Increase the average revenue per DAO

• Increase your number of DAO customers

You can increase average revenue per customer by increasing prices / take rate, offering more features, and driving more engagement. But given the limited number of DAOs in the market today, you’ll probably run into an upper limit pretty early if you don’t build a system to onboard and retain DAOs at scale.

Early on, you can rely on relatively manual biz dev efforts. Over time, you’ll need to invest in more scalable strategies like token incentives, developer tools (e.g., SDK, API, documentation, subgraphs, etc.), grant programs, and ecosystem investments. Each of these growth strategies probably deserves their own post which I’ll save for another day. In web3, one of the best growth strategies is launching a well-executed DAO which we’ll cover in the next section.

Become a DAO

One of the novel affordances of web3, blockchains, and cryptoeconomic networks is that they enable new internet-native org structures. That’s basically what a DAO is.

The best DAO tools will become protocol DAOs. The purpose of a protocol DAO is to create a self-sustaining protocol (shoutout G for this definition). Another good description of this end state is a Hyperstructure.

Elements of a self-sustaining protocol DAO include:

• A smart contract-based protocol with a value capture mechanism (e.g., a transaction fee)

• A token representing governance rights and equity in the protocol

• A governance process for making updates to the protocol

• A developer ecosystem building valuable product / protocol integrations

• Community initiatives to keep DAO members engaged and activate new members (e.g., working groups, community calls, onboarding sessions, IRL events, hackathons, etc.)

I recommend studying protocol DAOs like Yearn, Uniswap, Curve, AAVE, Compound, and Index Coop to get an understanding of how this works in practice. Read their docs, use the protocol through a UI, go deep into the governance forum, check out their GitHub, hangout in Discord, join a working group, apply for a grant, execute a bounty. Take note of the common patterns across these DAOs and understand the frameworks they use to make strategic decisions (going deep into the governance forum helps a lot with this). A lot of these projects followed the progressive decentralization playbook to become DAOs.

Web3 is about decentralizing power and giving ownership to a broader set of stakeholders. Becoming a DAO is the best way to do this. In a future post, I’ll share case studies on how top projects evolved into protocol DAOs.

---

Although there’s definitely some challenges with building DAO tooling today, there’s still quite a bit of opportunity if you narrow the focus, become the dominant solution for a specific use case, and expand from there. Take your time identifying gaps in the market, focus on liquidity over scale early on, and progressively decentralize.

It’s that easy 😛