Community Update — April 13, 2018

Some quick clarifications about our upcoming contracts. 🖥

This week our team has been busy wrapping up the code on some final UX modifications and onboarding steps for Tabby Pay.

Rather than cover the small technical details, we wanted to use this week’s update to dive into a question that popped up in our community recently:


First, let’s clarify BlockCAT vs. Tabby

Much like how Google and Apple have their App Stores, Tabby is BlockCAT’s answer to providing one familiar location for all our product releases.

BlockCAT — The parent company.
Tabby — The smart contract platform.

Using the Google example, their parent company name is actually Alphabet, and they have multiple different products, such as Google Drive, Google Docs, Google Photos, etc. Our smart contracts will be structured similarly:

Tabby Pay — smart contract to send/receive/cancel ETH payments.
Tabby Airdrop — smart contract to schedule airdrops to Ethereum addresses.
Tabby Rewards — smart contract to generate user redeemable codes.


Solutions > Contract Platform

The average user isn’t looking for “smart contracts” — they’re simply looking for a solution to their particular problem.

Let’s say you came up with a brilliant idea, and you wanted to meet with a potential investor. To protect your idea, would you search the web for “Contract Platform” or “Non-Disclosure Agreement”?

From an acquisition standpoint, if we release a brand new smart contract with it’s own unique features and benefits, we would want to capitalize on organic (SEO) and paid marketing and point users directly to the solution.


Productizing our solutions.

We realized fairly early on is that each contract aims to solve a completely different pain point, which means that each product will need to be designed, built for and marketed to a particular type of user.

For instance, the user who is running their own token sale would be an entirely different user from those using the joint-payment contract.

Not only would each contract solve a completely different problem, but it would also mean that the UI/UX, pricing, marketing and acquisition channels would all need to be inherently different as well.

As Eric mentioned previously, to try and shove them into a one-size-fits-all solution would only serve to detract from their usability. Instead, each smart contract will essentially be it’s very own product.


How will users learn about your other contracts?

Just because we’re building our individual smart contracts separately for UX/technical/marketing purposes, doesn’t mean you won’t still be able to learn about them and access them from a central location.

All of our smart contracts will be accessible from tabby.io.

The only thing that’s changed is they won’t be accessible from within an app like interface, and instead will be presented as their own products.

BlockCAT.io | Information about our company, team, vision, products.
Tabby.io | Our contract platform, with direct links to each contract.
Tabby.io/pay
| Direct link to Tabby Pay smart contract.
Tabby.io/airdrop
| Direct link to Tabby Aidrop smart contract.

And yes, just to clarify, every smart contract will utilize the CAT token.

A great example of this approach is Zendesk, who offers distinct products such as their Support, Guide and Chat solutions separately.

Multiple products that solve different pain points — but still related to the main company objective.

While we’ve made efforts in the past to address this in our documentation, we realize that we probably could have done a better job of relaying this information to a wider audience.

If you have any more questions for our team, be sure to pop them into our Discord channel. 💪😼

That’s it for this week! If you have any questions, be sure to join our Discord channel, tweet to us on Twitter or chime in on the /r/BlockCAT subreddit!

Like what you read? Give BlockCAT a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.