I want to share my vision for the future of the developer experience with Guild. By focusing on developers as first-class citizens in our ecosystem, we can build a robust community and foster the creation of amazing applications on top of Guild.
I believe we can build a great developer and app ecosystem around Guild. One idea is to emphasize "Build on Guild" as a slogan—it rhymes and highlights that developers can build on top of Guild, not just use its existing UI. Having our own dedicated X account will be so helpful here because it shows how serious we are about prioritizing developers, not just community events. (I secured the @BuildOnGuild account)
We also need to have a dedicated Telegram group for developers enthusiastic about building on top of Guild. And we should dogfood our own Guild by figuring out how we can use Guild itself to create a meritocratic, levels-based developer ecosystem.
Let's stimulate development with incentives. ONCHAIN is a token that didn't start explicitly attached to Guild, but I know Raz is thinking a lot about how to leverage the token in a useful way for Guild's goals. I think it's a great token to experiment with rewards for building useful applications on top of Guild.
Let’s make the Guildathon a reality:
https://docs.google.com/document/d/1hr36i8pUEzSGSHY_keACNbedtRsXePgpUZr-ag5zF0o/edit?tab=t.0
Before it becomes ridiculously obvious that Guild is a great piece of infrastructure for apps that can be successful on their own, we really need to stimulate growth and handhold people, encouraging them with incentives and community support. Let's make sure we have people (like me) who are assigned to the responsibility of celebrating and championing those building on top of Guild—basically being the customer support representatives for developers. If the API is structured weirdly, if the docs aren't great, if there's downtime, or if there are any issues with the developer experience, people like me will be helping make sure that all those issues are documented and prioritized on the backlog.
We also need to make sure that our documentation is really good and emphasizes how much we are encouraging people to build on Guild. So let's create a developer portal. Right now, it just says all developers of Guild are centralized in Hungary. I think that's going to evolve as Guild becomes more of an ecosystem that, yes, has a centralized core team but also a robust community of people outside of that team building on top of Guild and being independently successful because of it.
Enhancing the Developer Portal
What does the developer portal look like? I think it could be very useful to have a web app that conditionally shows you information if you've just created a developer account with Guild. It could recommend quick-start guides and ask you what kind of apps you're building to suggest what kind of documentation could be useful for you.
Providing Honest Answers to Developer Questions
In terms of the actual documentation, we need really good answers to why you should use Guild—the trade-offs between building your own role management system versus using Guild. Also, let's have an article on how to have both your own user data in your own app and integrate that with Guild's powerful technologies. I don't know what the Guild team's thesis on that is, but this narrative of purely outsourcing user management to Guild just doesn't quite make sense. As soon as there's a limitation in what kind of data Guild can collect and make sense of and take action on, you're going to have to store your own custom data anyway. So practically speaking, the narrative of outsourcing user management or role management is not quite the right narrative, so we'll have to iterate on that.
Showcasing Real-World Use Cases
Overall, getting a lot of case studies on real-world apps that are using Guild to streamline their operations, outsource parts of what they need to do, and do things that they couldn't do without Guild will be very helpful. Lots of case studies will help developers who are considering using Guild and wondering how they can use it. Right now, there's really nothing there.
Once Flow State successfully integrates Guild, Flow State is happy to be a case study: The Guild Protocol: A case study of its utility to app developers (feat. Flow State)
Offering Cloneable Repo Templates
We also need to offer easily cloneable templates that allow people to play around with working mini-applications that showcase Guild's authentication superpowers. Let's showcase how we can segregate different functions in the app based on what roles people have, and demonstrate that it is possible for users to get access to an app without having to go to the guild.xyz page. Maybe it'll take some time to figure out how to do that, but the kind of jump to guild.xyz and then back to the app you're at is a painful experience. So getting to a place where you can check whether you have access to a role, and then if your on-chain activity maps to that role, you should be able to join directly within an app—not going to guild.xyz.
Improving SDK Documentation
I think we want our SDK documentation to be way better. Right now, it's kind of grouped almost just by how the code is written, versus what actual use cases an app developer would want to see. I've had some issues trying to follow the documentation and building my own little apps with Guild, so there's just a lot of different ways that the Guild NPM documentation need to be updated.
Sharing Our Evolution and Philosophy
I think we also, in our documentation, should explain our evolution to where we are today. For example, why are we shipping a new API? Why did we replace a lot of our backend? What is our philosophy around it? How do we intend for this API to be used? How do you engage in dialogue with us about systems architecture like this if you really believe in what we're doing?