Last updated by Tim Delhaes 2 months ago
Our project is ambitious and never ending in its mission and the terrain in front of us is largely uncharted. So, how then do you define the destination and the road to it? More than a clear roadmap we first need a “compass” , a tool that allows us to take decisions at intersections, to choose directions and over time plot a course.
We can develop our product in different directions: focus on end user features or on developers, work towards decentralization or connect more systems. As a result our compass - unlike the real life counterparts - has to work in multiple dimensions. These dimensions should all be aligned with stakeholders of the system we are building since we are building for them.
While founders always love to do everything at the same time, experience tells us that it is impossible to do so. Fact is, the more you focus the more productive you become, the faster you move and the higher the return of investment will be for everyone. Furthermore I believe that buried in all the possible paths we can choose there is one winning sequence of steps.
So, what is the first step?
I believe the best investment we can do is into the product for our end user. Why? First, because building a working product gives us tons of credibility. It demonstrates that we have the people and the collaboration skills to get shit done. Second, because we can prove the theory that we can build a low/no code, on-/off-/cross chain workflow system that creates value for users.
Specifically the product should do three “simple” things right
Furthermore the product should allow to delegate the creation (not the deployment!) of
This system will allow us to demonstrate the power of the idea, win users to create traction and start generating an early network. We should try to make sure that
connectors and CDSs can be used (or serve as a code base) even when the project has been fully decentralized into a network of nodes
the workflow engine code serves as a code base for the distributed engine (or at least as a documented learning experience)
the vast majority of front end code can be continuously used and improved no matter what the engines core technology is at any given time
With that product n the market and acquiring users we have to
All these activities should work with clear budgets and require clear prioritizations. This work is ideally suited for also activating the community around Grindery: creating hackathons and Bounties together with our partner chains and dApps! This also connects to our dApp market dimension. The directories of our partner dApps (like the DAOs) become the best possible storefront display for the integration developed on Nexus. The work on those marketplaces could in the long-run be completely externalized and taken over by a separate team including InboundLabs agencies.
This really leaves us with two remaining dimensions to pursue which are Payment Rails and Network operation . The network can not be built without the payments since node operators need to be paid. However, payments can be deployed without a fully operational network. And this is what drives the decision in this intersection. We should launch our token or at least a first version of it.
We should release a token that can only be used to pay a single operator: ourselves. This is a bit like ANKR but with a single node. Launching payments early brings a few benefits.
The first one is that - no matter how limited and centralized the usage - we will have a working utility token. This is the analogy of having a web2 SaaS startup with paying customers. It changes how users, customers, investors and press perceive the project and its seriousness.
Second, it opens up new doors for collaboration and financing to our endeavor. We currently raise money with paper and tied to a traditional company. Using protocols and tokens to create incentives will open new pathways. Finally, the token will create the foundation to start working actively on the decentralization, the remaining dimensions. Essentially we will be working systematically on finding ways to put our token to use.
There are many successful web3 companies that are not decentralized. Fact is that some of the most successful ones are not decentralized at all. This includes all of the exchanges (likeBinance) and all API providers (like Alchemy). Other projects do the decentralization progressively like The Graph and ANKR.
While it is our ultimate goal to decentralize Grindery entirely and on all levels we should first make sure we provide a valuable service to our customers. Decentralization without providing value is like having a formula one driver without a car. With a simple, hosted service and token we will be able to empower users and developers to create dApps for the store fonts of our partners.
With that on track we can push decentralization forward.