On Roadmap

Last updated by Tim Delhaes 6 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.  
End user:  Allow them to design and manage workflows  
Chain connections:  Allow chains to connect and a result connect their dApp  
App Connectors:  Make it easy to connect more web2 systems  
dApp Connectors:  Make it easy to connect more web3 systems  
dApp Market:  Allow dApps to promote dApps built on our system. 
Network operator:  Nodes and connectors operating machinery 
Payment rails:  Turning users into customers and everyone else in providers.  
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 
allow users to create a simple w2/w3 workflows  
reliably execute these workflows 
provide the users with an execution log 
Furthermore the product should allow to  delegate  the  creation  (not the deployment!) of 
new chain connectors  
new w2 app connectors 
new CDS for app and dApps 
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  
keep adding more chains, more dApps and more Apps intelligently. 
keep adding workflow and front end features 
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. 
Refreshed On: Dec 08, 2022 09:37:43 UTC+00:00