hey @arkivnetwork hope this is taken into consideration I spent a good amount of time going through Arkiv’s MCP, docs and the Arkiv Hub throughout the ideathon last month well and also submitted some pretty good ideas and honestly, I think there’s a really strong developer experience buried underneath an onboarding experience that still needs a serious rethink. Starting with the docs: the problem isn’t a lack of information. There’s actually a lot of it. The problem is that a new developer has to connect too many dots themselves. You can read about entities, attributes, TTL/expiration, queries, SDK clients, wallets, networks and MCP individually and still finish with the question: “Okay, how do I actually build a normal Arkiv application from start to finish?” I’d make the primary Quickstart an actual end-to-end journey: create project → install SDK → connect → create entity → query it → update it → handle expiration → deploy a frontend. One working application that teaches the architecture as you go, instead of making developers jump between multiple reference pages. The examples also need to be much more copy → run → see-result oriented. I’d love to see complete reference implementations for something like a Next.js app, a React/Vite app, a backend/API integration and an AI-agent application using the MCP. The current documentation is useful for understanding individual building blocks, but more real-world workflows would dramatically reduce the amount of trial and error. There’s also a network/documentation consistency issue that needs attention. If a network has been retired or the current public network situation has changed, that needs to be impossible to miss inside every affected tutorial, example and tool. Developers shouldn’t discover halfway through a setup flow that the environment they’re following is no longer usable. A prominent network-status banner with “this tutorial targets X / current supported environment is Y” would eliminate a lot of confusion. The MCP is probably the part I found most interesting. The idea of giving an AI agent access to Arkiv operations like creating entities, querying data, updating entities, extending them, mutating multiple entities and streaming events is genuinely compelling. But the MCP onboarding currently feels like it assumes the developer already understands MCP configuration, wallets, authentication and Arkiv’s data model. I’d add a dedicated beginner path: connect test wallet → verify connection → install MCP → run a read-only query → make a test write → understand exactly what happened. The distinction between read-only operations and wallet-backed writes should also be much more obvious. I’d also rethink the UX around wallet/private-key configuration. Even with a warning to use a throwaway wallet, putting a private key into an MCP configuration URL is not the kind of pattern I’d want a first-time developer to internalize as normal. The product should make the safe boundary obvious and guide users through a disposable test-wallet flow rather than making the security model something they have to reason about themselves. The MCP toolset itself is strong, but it could do a better job teaching developers which tool to use when. A simple layer saying “I want to save data → createEntity”, “I want to find data → rawQuery”, “I want to modify data → updateEntity”, “I need multiple writes → mutateEntities”, “I need live changes → streamEntityEvents” would make the power of the MCP much more accessible. Then there’s the Arkiv Hub UI. This is where I think the biggest product/UX opportunity is. The Hub is trying to be a docs gateway, MCP setup tool, Skills library, Tools directory, ecosystem catalogue, explorer, network dashboard and developer portal all at once. Individually, those are useful. Collectively, the experience can feel overwhelming, especially for someone who has never used Arkiv before. The UI needs much stronger information hierarchy. When I land on the Hub, I shouldn’t have to figure out whether I should start with Docs, MCP, Skills, Tools, Faucet, Explorer or something else. The interface should answer three questions immediately: What is Arkiv? What can I build with it? What should I do next? Everything else can come after that. I’d make the primary journey something like: Discover → Install → Create → Query → Deploy. Then make the other sections supporting experiences rather than competing entry points. The Hub also feels a little too much like an internal developer dashboard in places. Infrastructure information is useful, but it needs to be translated into human-readable product states. Instead of making developers interpret network information, loading states and infrastructure telemetry themselves, show things like “Testnet connected ✓”, “Wallet connected ✓”, “10 test tokens available”, “3 entities created”, “Last transaction confirmed”. The UI should teach you what Arkiv is while you’re using it. The Skills section is actually one of the ideas I like most. Having patterns distilled from real hackathon submissions is potentially extremely valuable because developers learn much faster from proven implementation patterns than from abstract API references. But I’d push this much further. Every skill should have a very obvious “Try this now” path, with a runnable example and a clear explanation of what problem the pattern solves. If something as fundamental as “Start an Arkiv app” is only a proposed skill, I’d prioritize that heavily because it could become the front door for the entire developer experience. The Ecosystem section could also become much more than a showcase. Instead of simply showing what people have built, let me say “I want to build an AI agent / marketplace / social app / data-driven dApp” and immediately show me relevant Arkiv projects, the patterns they used, the relevant Skills, the MCP workflow and the code/repository to learn from. That would turn the ecosystem into an actual learning resource. Overall, I don’t think Arkiv has a documentation problem as much as it has a developer-journey problem. There is a lot of useful information, but too much of the responsibility for connecting it together is placed on the developer. My five biggest recommendations would be: build a truly end-to-end start your first Arkiv app experience; redesign MCP onboarding around a much clearer security and wallet model; organize the docs around complete developer journeys rather than only individual concepts; simplify and strengthen the Hub’s UI hierarchy so it tells developers exactly what to do next; and turn the Skills/Ecosystem sections into interactive implementation guides. The underlying primitives are interesting, the MCP has real potential, and the Hub is aiming at something valuable. But right now it feels like several good developer tools living beside each other rather than one coherent developer experience. The goal should be that someone can arrive at Arkiv knowing absolutely nothing, spend an afternoon with it, and leave with a working application — without needing to constantly ask themselves, “Wait, which part of the ecosystem am I supposed to use now?” That’s the level of DX I think Arkiv should be aiming for. also the admin @kiminza_codes is an amazing UI/UX designer shoot her a dm...or shoot a dm here