1. Objective

The Developer Relations workstream (manned by @ui369.eth and @arentweall ) have been auditing our current developer experience (DevX) and interviewing community developers interested in building with DAOhaus. We interviewed 6 teams (e.g. Plaza, Nestr, Sobol, Karma, Guildxyz, Hedgey) and studied our previous integrations with developers. Mainly, our findings pointed to 2 questions:

  1. Developer Personas: What are they building? Why work with DAOhaus?
  2. General Feedback: How has the experience been so far? Any feedback?

2. Who are they?

Most teams are solving specific and well-defined problems above the governance layer, such as task management, token-gating or reputation models. They are early-stage startups that are iterating heavily on their product, aspiring towards product-market fit and traction.

Some teams are building on-chain solutions, while the rest are solely off-chain. Generally, crypto-native problems and solutions (e.g. timelock escrows & reputation) require on-chain solutions, while more traditional or Web2 solutions (e.g. task management) stay away from smart contracts, etc.

Here is a summary of the teams we talked to:

Name Problem Space Stage of Integration
1 Plaza Service Agency To be explored
2 Nestr Collaboration Integration in progress
3 Sobol Collaboration To be explored (Summon)
4 Karma Reputation Integration in progress
5 Guildxyz Token Gating Possible in next 3 months
6 Hedgey Escrows & Lockups Integration in progress

3. Why work with DAOhaus?

Broadly speaking, all softwares have the following components:

  1. Application: Everything that makes the software useful (e.g. application logic, program, middleware and infrastructure)
  2. Data: A record of all interactions from the application

Developers will work with another software if their application or data creates a better user and/or developer experience. Through our interviews, these are a few models and reasons why developers would like to work with DAOhaus.

3.1 Partner Integration Models

Projecting into the future, all 4 models will be important to DAOhaus as well as our partners.

Model In the long run, this becomes important because…
A Partner reads our data partners want to surface contextual DAO data in their applications
B Partner writes to our application partners need entry points to DAO governance (e.g. giving shares from a bounty board or NFT marketplace)
C We read partners’ data this will help to create a better user experience on DAOhaus as other developers build primitives (e.g. identity, reputation, etc) that add to DAOhaus functionality
D We write to partners’ application partners will want easier ways to interact with other dapps and protocols trustlessly through their minions.

3.2 Prioritization & Recommendations

As of today, models A (Partner reads our data) and D (We write to partners’ application) are the areas we should be prioritizing today. These 2 models have (1) existing demand and (2) existing infrastructure, allowing us to achieve meaningful success with the resources we have today.

Model A (Partners read our data) Model D (We write to partner’s application)
Existing Demand As mentioned, most DAO tools are still early-stage and sorting out product-market fit in their own problem space (e.g. reputation / task management / etc). That remains their first priority.

Some of these tools now have traction in their core product offering, so the next step is to surface contextual DAO data that can enrich their user experience.
The early-stage nature of these DAO tools mean that these DAOs want more usage and traction on their contracts and protocols. If they are targeting DAOs, the DAOhaus application is a good platform for more users to use their products / protocols.
Existing Infrastructure Today, these developers can query our Subgraph APIs for this data. With our current infrastructure, we already enable this use case - this process is easy to access. Today, our recommendation for these developers is to create custom proposal forms (i.e Boosts) through DAOhaus. With our current infrastructure, we already enable this use case - this process is difficult to access.

Given the above, DevRel team will focus on existing demand and existing infrastructure (i.e. Models A & D) by creating better developer documentation, tooling and engagement. As the magesmiths are shipping future infrastructure (i.e. v3), we will be providing inputs for v3 infrastructure to magesmiths, while keeping external developers updated.

4. How has the experience been so far?

4.1: Partners are unclear how they can integrate / work with DAOhaus

DAOhaus is largely an open-source project that embraces other developers integrating and building on top of our application, infrastructure and data. With this, we welcome developers to build “anything they want” like a blank canvas.

This creates 2 issues:

  1. Emergence & openness in how developers can work with us creates ambiguity. To work with external developers, it is often easier to illustrate possible use cases and integration modes, so they can envision what works best for their application.

Recommendation: Going from “build-anything-you-want emergence” into more well-defined integration modes, we can create developer interfaces, documentation and tooling to evangelize, educate and onboard developers on DAOhaus.

  1. There are actually some areas we want to own, but we have not aligned internally on our approach vis-a-vis external developers. These include Boosts vs Bolt-ons (how do we enable external developers who want custom UIs), payment rails, marketplace and curation mechanisms). When developers have a blank canvas, they will gravitate towards larger problems to solve (i.e. the above issues).

Recommendation: Producing a map of what’s allowed & not allowed will help give greater clarity, save time and avoid disappointment & tension for external developers.

4.2 Developing Integration Categories

As we are embracing composability and building developer interfaces, we will need to be clear about the developer personas, their problems & their expectations of a “good” solution.

Who are our users? What problems are they solving? What primitives do they need?

Answering these questions will help identify partners, prioritize resources and scope out requirements and start execution.

Recommendation: Identify areas of strategic importance & create clear products and interfaces for external developers.

The end goal would be to reveal our developer-facing product offerings and value proposition with the aim of making them understandable and accessible.

An example would be Chainlink’s product suite below. They have clear use case categories, even though most of the products share the same underlying infrastructure.

4.3 Four Integration Models

Since developers have shown demand to work with us in the above 4 models, we can assume there are valid problems to be solved here. Hence, we could adopt the 4 product strategies / lines below.

“To better understand these 4 product lines, it’ll be useful to dive into the target audience, problem, solution and revenue model (see below for sample)

A. Data Feeds and D. DAOhaus as a Platform seems to be the closest to consumption and usage by external developers today. This is because the existing infrastructure has already enabled developers to read data or build Boosts.

From an execution point of view, DevRel will continue to improve DevX for today’s MVP versions of Data Feeds & DAOhaus as a Platform. On a longer time horizon, the magesmiths team will have these 3 product lines in mind while designing developer interfaces in v3, so that we can provide the most optimal Data Feeds, Embedded Governance & Platform product”

Recommendation: Magesmiths aligns on the above 4 categorizations. Existing development timelines can be revealed through this lens to improve developer interfaces and experience.

4.4 Developer documentation & tooling can be improved

Our current resources for external developer integration can be improved. Today, developers need to understand, navigate and work on the DAOhaus codebase instead of working on packages, APIs and SDKs provided by us. Imagine being teleported into a strangers’ kitchen and being tasked to cook dinner without knowing what ingredients & appliances are available, where to find them, what works and what doesn’t, etc. Developers are having a similar experience with our code base.

The creation of custom forms have made things easier, but there is still a big barrier to developers integrating with us. We should take these into account when building for v3 developer interfaces.

Recommendation: In the same vein as prioritizing existing demand & infrastructure, the developer relations team will improve developer documentation for v2, so that these developers can better understand and navigate our stack to build what they need. This includes more explainers, tutorials and samples to achieve common modes of integration.

We have been already executing on this workstreams and aim to publish the following in the next 2 weeks:

  • 1x text-based tutorial to build a boost (inspired by Jord’s workshop on the Mint a Million Boost, see here for current progress)
  • Broad documentation improvements: Conceptual Overviews & Explainers

We will then seek developer feedback with these updates.

4.5 Developer engagement & support can be improved

Previously, as DevRel did not have dedicated focus and support, there was feedback that the developer support was intermittent, causing a loss of momentum and progress in some projects. This will be improved with UI369 and myself looking after developer engagement.

Recommendation: DevRel to improve developer support & enablement

Initially we will continue to have more high-touch developer engagement to gather feedback, gauge interest and provide support to enable developer success. In the short run, the focus here is NOT to create processes & engagement strategies for developers en masse.

We want to be grounded in helping existing developers achieve success with existing infrastructure This includes bi-weekly check-in calls, ad hoc support and regular feedback sessions on developer documentation.

5. DevRel Summary

5.1 Looking Back: Progress Update

To close off this discussion, we wanted to take stock of our progress & some focus areas moving forward.

S/N Focus Area Progress (Forecasted by end June)
1 Improve DevX Audit: We have audited the docs and are on track to completing the following docs improvements

Docs Improvements:
  • We will publish the first text-based tutorial for building a Boost (with code snippets, videos & annotations) by next week, lowering barriers to Boost developers
  • Once the above is complete, we will create more guides on Subgraph queries (i.e. supporting DAAS use cases)
  • 2 Engage Community Developers We created a CRM with 10 developer teams and ran developer interviews with 6 of them. The findings have been published above and will inform our developer relations efforts moving forward.
    3 Deliver 3 Boosts Currently, there are 3 developer teams who are integrating with DAOhaus and we will assist them in going live. (Karma & Nestr consuming our data feed, as well as Hedgey building a boost).
    4 Gather feedback for v2/v3 compatibility We did not explicitly talk about v3 requests, but we gathered more general feedback on our developer product offerings which should be helpful for v3 nonetheless. This is an ongoing workstream.

    5.2 Looking Forward

    Moving forward, based on the current obstacles, tensions and objectives, this is how DevRel could potentially support our priorities moving forward (of course, subject to change)

    Focus Area Tentative Deliverables Tentative Timelines
    1. Improve DevX & increase adoption on existing infrastructure (i.e. MVP for Data Feeds and DAOhaus as a Platform)
  • Organize more live coding sessions with v2 Devs
  • Enhance tutorials & documentation for Boosts (DAOhaus as a Platform)
  • Create tutorials & documentation for Subgraph queries (Data Feeds)
  • Continue high-touch engagement with developers
  • Get XX Data & Platform integrations live
  • July - Aug 2022
    2. Support the product strategy & developer interface design in v3
  • Provide inputs on developer-facing persona, problems, solutions in product strategy
  • Gather feedback externally & provide feedback
  • Define clearer product offerings & interfaces (once direction is clear)
  • July - Aug 2022 (Maybe announce something at MCON?)
    3. Create DevX foundations for future infrastructure (i.e. v3) & increase adoption for all products (Data Feeds, Embedded Governance & DAOhaus as a Platform)
  • Organize more learning sessions with v3 Devs
  • Create more tutorials, docs & tools from these learning sessions
  • Continue high-touch engagement with developers
  • Grow the developer community
  • Get XX Boosts & Platform integrations live
  • Sep 2022 & beyond

    Followup questions for Magesmiths / Warcamp:

    What is the product strategy that DAOhaus wants to own?

    What are some primitives / interfaces we want to enable developers to build?

    Which features of V3 can begin to involve our developer ecosystem? (development, integration, requirements gathering?)

    This discussion should help us address:

    • Partnerships / B2B aspirations for sustainability / strategy
    • Composability aspirations for v3
    • Revenue model & value accrual

    Great and detailed work!


    In addition to the outcomes reported here on 23 June, we’ve made the following progress on our 4 main objectives:

    1. Improve Developer Experience:
    • The first round of improvements to dev docs are live! Changes include:
      • Added a complete step by step boost development tutorial (with code snippets, videos & annotations).
      • Re-organized dev docs sections for better clarity & flow
      • Updated concepts & explainers for DAOhaus concepts
      • Normalized terminology across user & dev docs
      • Added an app overview & updated explanation of Code legos
    • We believe this structure puts us in good shape to work on subgraph guides & v3 docs moving forward.
    • Annotating the graph projects themselves would be a good step forward.
    1. Engage Community Developers: We ran our 2nd Fishbowl live coding sesh led by @jord. While there were some technical difficulties, dev turnout and engagement was good.
    • Video & Audio of the event was captured & can be edited into snippets to support developer documentation
    1. Deliver 3 Boosts: We’ve completed 1 (Hedgey) out of the 3 integrations (Karma, Nestr & Hedgey) we focused on.
    • Hedgy Boost & Proposal functionality works fine, but this has not passed local QA due to issues caused by new Safe Minion v2 bugs. Boost should go live after next week.
    • Nestr & Karma - We have been providing Graph API technical support - documentation improvements on Graph would be a big help to them.
    1. Gather feedback for v2/v3 compatibility: We have some notes from developer interviews, but otherwise no new updates here.