What's the architecture of Taro?

A lot of our system design choices were made to maximize product development velocity because we are a small team with limited cash.

What technologies are used for frontend and backend?

We use Next.js for our frontend and our API layer. We use Firebase and Google Cloud services on the backend.

What is the backend architecture used? What are the databases used?

We use a RESTful API architecture + Firebase SDK for reading and writing data. Our API is used for shared business logic between the webapp and mobile apps or exposed to third party services for webhook logic.

We use Firebase for our database.

How are the videos streamed, payments handled, user logins handled?

Videos are streamed through Firebase.

Payments are handled through Stripe

User authentication is handled through Firebase Authentication.

How does Taro scale with users and give a smooth experience?

Since we use Next.js, we try to build and cache pages as much as possible.

How is the platform optimized from the perspective of cloud costs?

From the previous answer, making use of Next.js SSG and ISR everywhere we can helps with minimizing the number of calls to our database. There are more optimizations that we could be doing, but, Firebase is still pretty cheap even when unoptimized. Our time and resources are better spent iterating on the product than trying to optimize the infrastructure.

When the number of users on Taro increases by an order of magnitude, what are the changes to the architecture you would consider doing?

We might even consider using the same architecture for the webapp because the Next.js caching is working out enough for us enough where increasing by 10x doesn't necessarily mean that our costs will increase by 10x. Cloud platforms are so nice for ensuring stability and reliability at a reasonable cost where it makes more sense to focus on developing a better product.

Is the website built from scratch? Or are there any libraries and frameworks available to make it easier?

We stand on the shoulders of giants. There are so many great open source frameworks and libraries that we use, like Next.js and Vercel that automates the build and deployment process for us.

Taro seems like a well-built platform with smooth user experience and a lot of features. I'm surprised that all of this built by just one engineer (Charlie). What's the secret sauce? What are the tradeoffs made to still make things work with less resources?

I really appreciate those kind words! I think a lot of it comes down to being very intentional about whether we can leverage existing tools instead of building them ourselves, the "build vs. buy" argument. There are so many great services out there offering their products at very reasonable prices. We do try to go with the "buy" side as much as possible because you can essentially pay $xx-$xxx to do what it might take many months or years to do with many more engineers.

As far as feature development, we are very careful in doing a lot of user research before we start to build anything. We are also very intentional about making sure the scope is reasonable by only building the features that are requested by users.

What is the decision-making process that went into making all these decisions?

The key decision-making process is realizing that we are a startup with limited resources, and our goal at this stage is to reach product-market fit as quickly as possible. Every decision we make is based on that premise. This means that there are a lot of optimization or scale decisions that we can't get to or that we need to offload. While these sorts of challenges can be technically challenging and fulfilling, it usually means it's better for us to offload the work to different services that will get you something working immediately.

If you want to learn more, feel free to reach out to me on Slack. Would love to go in-depth about anything you find interesting!