BlockCAT’s Road to Beta
A message from Eric, the BlockCAT CEO
The last few weeks have been immensely valuable to us. After the token sale concluded, we knew the next immediate step was to hunker down and refine the key details in how to make BlockCAT a successful platform.
Today, I am happy to share further details that describe how BlockCAT will operate for the near future, and our revised roadmap that breaks down what we hope to achieve in the time leading up to the launch of BlockCAT Phase 1: The visual smart contract platform.
From the public alpha released during the token sale, we’ve learned and gathered extremely valuable analytics, metrics, and feedback. This information has been integral in shaping our near future vision and plan for the Beta.
However, it’s also become clear to us that several fundamental pieces of the alpha simply aren’t scalable or meet the usability standards that we intend to hold ourselves to with the Beta release. In particular, we’ve found the UI framework we experimented with (Vue.js) and its component library (Quasar) to be too immature to meet the rigorous demand of blockchain dapps. Much of the frontend code written for the BlockCAT public alpha had the feeling of trying to “put the square peg through the circle slot”, so to speak. As a result of this architectural incompatibility, the usability of the alpha suffered, which was noticeable in the occasional freeze-up of the UI. Usability and a pain-free experience is a top priority for the BlockCAT platform, and thus it’s been a strong opinion of mine that we ought to take the valuable lessons learned in the alpha and to move to a more mature, better suited UI framework.
The alpha contracts and UI will remain live for the foreseeable future, but will be shut down once the Beta has reached feature parity with the alpha. This date will be announced well in advance through our usual communication channels, please keep an eye out and make sure all Ether is withdrawn prior to that day.
The BlockCAT community has been very vocal about what they’d like our platform to focus on and target. We’ve been hearing a lot of great ideas, and we want the community wants and desires as the top priority for our platform. As a result, we’ve also structured our development cycle to reflect and accommodate for this.
Effectively, our development cycle will be a very rapid turnaround of prototypes, getting feedback on the design and functionality proposition, and then iterating quickly based on what people are saying.
Once the details have been ironed out, we fire off the specification to our in-house Solidity engineers, who will finalize the behaviour of the dapp in a smart contract. This is then deployed and integrated into the BlockCAT platform, where the process then repeats. Crucially, lots of prototypes will be on-going at the same time, and not all prototypes will be taken to completion. The process will allow for the prototypes of the highest demand to “bubble up” and be given priority, while the ones that have less interest will naturally fall to the end of the queue. It’s our expectation that this will help identify the pain points that the community wants to target in an organic fashion, without running the risk that we end up spending several months building contracts that nobody actually wants to use.
A contract that allows purchase pooling for token sales, and a token sale builder, are two use cases that have already received significant community attention. I’m glad to announce that BlockCAT will be targeting these two contracts as our main priority moving forward. It’s our hope that these contracts will assist in lessening network congestion by batching transactions prior to the launch of a token sale, reduce scam occurrences, and minimize the amount of insecure token sales by providing a secure, solid, and reliable platform for deploying custom ERC20 token sale contracts.
As a side effect of the revised, rapid iteration development cycle, BlockCAT smart contracts will be hitting the public market sooner than we’d originally projected in our whitepaper. Instead of having one complete platform be launched on a specific date, expect to see a rolling and regular release of contracts on a periodic basis. We feel this allows us to rapidly target the biggest demand contracts early, without requiring eager users to wait several months for the official release to occur.
Some of you have pointed out that the team section on our website is no longer there. This is due to a restructuring of our team in preparation for a significant number of hires that will be joining BlockCAT. With new hires comes a significant change in how BlockCAT operates, and it’s taken a little while to iron out exactly how the flow of information happens in our internal communication.
Our current intention is to grow BlockCAT out to a team of around 10 full time employees, split into two major departments: media and technical.
The core roles at BlockCAT will have the following responsibilities (in no particular order):
The BlockCAT CEO holds the key vision of BlockCAT, and guides the company in making sure that the course we’re on is the right course in terms of meeting community demand, profitability, and sustainability. Effectively, they determine “what” BlockCAT is doing.
The BlockCAT CTO translates the direction and vision determined by the CEO into a technical direction, and communicates this with their team. Part of this involves planning, budgeting, and making sure what the CEO intends to do is technically feasible and sound. The CTO can be thought of as determining “how” BlockCAT accomplishes its mission.
The BlockCAT CMO sets the course in ensuring that BlockCAT remains relevant and a strong player in the space. A platform that nobody knows about can’t build traction, and that is what our CMO will prevent.
The BlockCAT community manager distills the community conversation and filters out the noise. By refining and drilling down into the core message coming from the community, they relay this information to the BlockCAT CMO in order to help determine where and when BlockCAT should move. This role is key in identifying the use cases that are in demand and worth exploring.
The BlockCAT Inbound Marketer will drive forward the online presence of the company. They’ll plan, design and launch creatives that foster a unique relationship with our community and the wider cryptocurrency ecosystem.
The BlockCAT internal coordinator is the person who holds all of the different threads in their hands and prevents the operation from unravelling. They take the majority of the scheduling and daily burden off the key players in BlockCAT to ensure they can be focusing on exactly what they need to do. Our internal coordinator also ensures that all of the BlockCAT departments are staying in close communication, so that everybody can work in unison towards a common goal.
The BlockCAT frontend engineers are the bridge between the blockchain space and the user space. They’re the ones prototyping and designing the key components that empower our everyday users with all of the functionality and benefits that smart contracts provide.
The BlockCAT blockchain engineers build the smart contracts that drive the UI and give it functionality. If the BlockCAT UI is the steering wheel, then the smart contracts are the engine.
The BlockCAT backend engineer focuses on making sure the jobs of the frontend and blockchain engineers are as pain-free as possible. Blockchain data is messy and difficult to access, our backend engineers will take this data and clean it up to ensure that it’s readily available to our UI to use, which significantly boosts the usability of our platform.
The next few months are going to be extremely interesting for BlockCAT, and I’m excited for what’s in store. Feel free to tell us your thoughts and feedback on the direction of BlockCAT in our official Discord channel, or via email to email@example.com.