What I Learned Building My Side Project: Codetalks.TV

🤓 What is Codetalks?

As programmers, we know how important it is to be up to date in terms of programming languages, frameworks, methodologies and tools in general. We must always be in continuous learning. One of the best ways to stay up-to-date is by attending technology conferences and events, but many of these events are not in our city or we simply cannot attend. The positive part is that most of these events are recorded and are available for free through different video platforms (mainly Youtube or Vimeo), which is great, but there are a couple of problems:

❌ There are plenty of interesting events and talks around the world every week and it’s hard to be aware that they exist.

❌ Each event is on a different date and is published on different accounts and video platforms, which makes it very complicated to track the events that interest us.

That’s why we decided to create Codetalks.tv, a platform for developers that brings together the best programming talks around the world in one place. Each video is grouped by tags and event so that it is incredibly easy to discover conferences, watch lectures and keep learning.

📋 What should our MVP have?

Considering that this is a MVP (minimum viable product) we wouldn’t want to extend the development time too much, therefore, we tried to identify the key functionalities that would give meaning to the project, in this way we could validate if our idea made sense or not before continuing to invest more time and effort in it. The characteristics we identified as most important were:

• Talks finder
• View talks by tag
• View talks by event
• View available tags
• View existing events
• Send talks (Youtube & Vimeo)
• Subscribe to a specific tag
• Receive feedback and ideas

As for the design, it had to be simple and intuitive. It didn’t make sense to create anything new and extravagant and that’s why we opted for a design similar to that of Youtube, so that anyone can instantly feel familiar with it.

Focusing more on the look and feel, we decided to make a small wink to our potential users, the developers, for this reason we gave it the appearance of a code editor (VS Code?), and even… we used the famous Monokai color palette.

🛠 Let’s get to work

And it’s time to code!

One of the interesting things about a side-project is that you can afford to experiment and try new things out, so, we didn’t want to miss this opportunity.

Here is a brief summary of the technology stack we used, both for the backend and for the frontend. If you find it interesting, we will publish more articles explaining part of the development process in more detail.

Frontend:

• Create React App: Create React apps with no build configuration
• Apollo: The perfect partner for GraphQL. The client is designed to help you quickly build a UI that fetches data with GraphQL.
• Styled-Components: A very popular CSS-in-JS styling library that uses tagged template literals in JavaScript and the awesome power of CSS to provide a platform that allows you to write actual CSS code to style your components.

Other libraries or tools that have helped us a lot:

• Storybook: Open source tool for developing and organize UI components
• Plyr: This library is gold. It allows us to embed videos from YouTube or Vimeo, and customize them completely: Put our logo, remove the buttons from the original platform … etc..
• Formik: To create forms in a simple way (Everybody hates forms, right?). It is very useful used together with Yup, an input validation library.
• Color: This is another simple library to perform small operations with colors.

Backend:

• GraphQL-Yoga: Fully-featured GraphQL Server based in Express
• Prisma: Prisma is a database abstraction layer that turns your databases into GraphQL APIs with CRUD operations and realtime capabilities

Third party tools:

• Sentry: This is the tool we use to receive errors that occur both in frontend and backend. In this way we can eliminate the small bugs that arise.
• Mailchimp: This is how users can subscribe to receive the latest videos from a tag, when they do so their email account is added to a Mailchimp list and from there we can then send the weekly summary of the best videos.
• Cyfe: we use Cyfe to have in one place information from different parts of the platform. For example, we have a panel for Analytics, and another to see the number of users and videos we have on the platform. We can continue to add data and internal information from the platform to have it all in one place.
• Typeform: we use Typeform to receive feedback from users because it is a simple and quick way to implement it and have it integrated with Slack to receive information instantly.

And then came the moment of truth… 

🚀 The launch

The truth is that if we are taken out of the technical or product part we will feel like a fish out of water, one could say that marketing is not our strong point. That’s why, to define our launch strategy, we simply asked ourselves a question: Where are our potential users?, and based on the answers we found, we drew up a list of possible acquisition channels:

☠ Big portals (Disaster):

• Product Hunt: We tried to follow all the advice we read by different blogs regarding a successful launch in PH, we knew it was very important and one of the keys to the launch, however we only got 9 upvotes (very sad).
• Hacker News: We only got 4 points.
• Reddit: We sent it to the subreddit r/programming. It wasn’t published either.

At this point, and after a truly horrible initial release, we wondered if CodeTalks actually made sense, are we really solving a problem and bringing something to the community? our motivation crashed.

However, after a few days of decline, we decided to continue trying in other ways and this time, fortunately, it was better:

✌ ️Niche media (Not bad):

• Blogs for devs: We have appeared in several important blogs in the sector, which has brought us a very qualified traffic.
• Devs Newsletters: We have been quoted in several newsletters, many of them with tens or hundreds of thousands of subscribers.
• Twitter: Since the beginning it has been a great ally, we get a lot of traffic through this social network, partly due to a very cool bot we have developed that posts talks and mentions speakers all day long (this is for another post).

Despite not having had a spectacular launch, we have seen over the last month how traffic has been increasing day after day steadily. In addition, we have received a lot of positive feedback, so the general feeling is that people like it, and although we think we have not reached product-market-fit yet, we do believe that we are going in the right direction and that it is worth continuing to invest some more time.

In addition, we have a few very cool ideas for version 2.0, and…. why not, we’ll make another release later with lessons learned, maybe this time we’ll be luckier hehehe.

🎓 What we learnt

If we had to draw some key lessons, these would be:

1. Attempt to resolve a real problem, a pain that you have detected in your own flesh. In this way you will be your own target client and you will know what you need.
2. Keep things simple. Don’t go crazy with the technology stack or the features that the MVP should have. Try to launch quickly and validate your idea as soon as possible.
3. Since you’re doing a side-project, try to learn something new along the way. If the project finally fails, you will at least take with you new knowledge and something interesting to add to your portfolio.
4. Don’t be discouraged if your project doesn’t receive all the attention you expected at the beginning, it could be for different reasons. Be patient.
5. Listen to your audience and try to improve your product little by little.
6. Make lots of launches. Consider each new feature you add to the product as a new opportunity to make a new launch and get attention.