Creating a place to matchmake media industry people
There are three groups of people in media industry in the USA:
- Video creators (aka content makers) — look for sponsors to help them produce content, places to showcase the content, and ways to increase the audience.
- Businesses — look for content (TV shows, movies, series, etc.) where they can put ads.
- Distributors — constantly need high-quality video content for their channels (TV and Youtube channels, video platforms, etc.)
Where can they all meet? There was no such place until in 2019 the idea of creating a convenient platform for content makers and buyers was born in the heads of three marketers from NYC: Lou Severine, Will Schmal and Fabio Pigo.
Purrweb’s Linkedin profile says that we specialize in MVP development, have experience with marketplaces, and UI/UX design is our forte. We hadn’t worked with videos before but had experience with photos and audios. Similar projects that we developed are Tunetank — a marketplace for musicians and Daiokan — a marketplace for photographers. That was exactly what the client needed so we perfectly matched. Discussed the project, shook hands and started working.
Focusing on the essentials
The project was supposed to combine Vimeo, Youtube and Shutterstock functionality and become an ultimate video marketplace. To cover such a scope you would need at least a $1.000.000 budget.
As it usually happens, through multiple discussions we managed to convince the client to develop only the key features during the MVP stage:
- Registration and onboarding.
- Ability to choose the role of buyer or seller.
- For buyers (businessmen that search for advertisement spots, and distributors that want to buy out rights to broadcast videos):
- search by tags and use filters,
- view content and add to favorites,
- create content plan in the calendar to know future spending
4. For sellers (video creators that search for sponsors or distributors):
- fill in profile, so that buyers could navigate easily,
- upload content.
- choose a subscription plan.
We prepared such an MVP to release the product as soon as possible and easily implement new features after the release.
Then we decomposed the work scope into six sprints:
- UI/UX design and MVP structure.
- App architecture, registration and accounts.
- Content search.
- Calendar and projects.
- Payment system.
- Admin panel.
Tested the app every sprint in parallel with development. The project team included 7 specialists: a project manager, 3 developers, 2 UI/UX designers and a QA engineer.
Creating a convenient service for the whole industry
The clients wanted not to compete with similar platforms but to cooperate with them and create an ecosystem. That’s why we didn’t focus on distinguishing the app from the competitors. As a reference, we used such marketplaces as Upwork and Linkedin.
The clients completely trusted us in terms of UI/UX design and relied upon our vision. They had no special requirements, and only gave us a few references with elements they like. Their key demand was to get a user-friendly interface.
Protecting content from unauthorized users
To upload videos on the platform, we needed a high capacity storage. We decided that AWS S3 can handle the task — it’s a cloud service that allows users to store and retrieve any amount of data, at any time. At Purrweb, we usually work with AWS, since it has a huge variety of services. To process and compress videos, we used aws step functions. The less the size of a video, the less money our client pays for S3.
Integrating data storage wasn’t so difficult as making content available only for authorized users. The thing is that there are two types of content on the platform: private (users see it only after purchase) and public (users can view the content on the platform and purchase it if they wish). To give users access to the private content, we used Amazon CloudFront.
We made authorization, and initially, unauthorized users couldn’t do anything on the platform. But users wanted to share content on social media, and how were their subscribers supposed to see anything without authorizing? That’s why we thought out several scenarios:
- Content maker uploads video on the platform and chooses the content visibility in settings: private or public. If private, the system generates a passcode. The user can share content via email: the recipient gets the link to the video and the passcode. Code’s temporary — only works for a particular time, and then expires.
- If public, unauthorized users can see the information on the project by following the link, they don’t need a passcode. The rest of the content on the platform stays private: it can be seen and purchased only after registration.
What about indexing?
From the very beginning the client was sure that the platform would need search engine indexing so that users could find the platform in Google or Bing.
Since we create single page applications, we needed server-side rendering to enable app indexing. That’s why we used Next.js. We worked with it multiple times (Next.js + Nest.js is our traditional tech stack for web apps) and didn’t expect any difficulties. However, we wanted to index private pages, in other words pages that only authorized users could see. Doubt that a search engine bot would want to sign in… That’s why when we tried to put together server-side rendering and authentication, we faced difficulties with refreshing tokens both on the server and the client.
When rendering happens on the server, a user needs an access token to get to the platform. If the token is expired, it needs to be refreshed or the user will need to authorize again. That’s why refresh tokens are used. The problem was that we couldn’t figure out where to safely store the refresh tokens.
There were two options. The first — to give search engine bots only public pages (but our client needed the private ones too), the second — to store tokens in cookies, which is not secure. Because someone could steal the token, get access to data, sign in to the user’s account on the platform… Both options were not great.
We wondered: how to make authentication safe and at the same time enable indexing of private pages? Decided to use one domain for the server and the client, and to store tokens in secure cookies. It turned out to be an optimal solution. Now private pages are indexed and authentication is safe because tokens are stored in a secure place.
That’s how it works for users:
- A user searches in Google «cool content for advertisement»;
- Gets results with private but indexed Contentplace pages;
- Follows the link;
- And sees a message: «Please sign up to see the content».
As a result, the users get what they were looking for, and the platform gets authorized users. Win-win.
Thinking about money
As for the payment system on the platform, initially the client saw it all in black and white: either it’s entirely free, or the users need to pay for everything. And if they need to pay, the price needs to be high — more than $1000 a month. After discussing it with each other they decided that the strategy did not sound great, and came up with an alternative — approximately 30 different subscription plans. At that moment, we realized that we needed to join the discussion.
We spent about 12 hours on video calls with the client: explained different types of subscriptions, pros and cons of every approach. Decided that on the MVP stage the platform would have three subscription plans. For content makers we added a one-month trial and two plans with 25 GB and 100 GB storage space. The third plan was a super special offer for the first 100 users. They would get the ability to update their subscription to the most expensive plan at the price of a basic one. Further we agreed to divide subscription plans not only by GBs but also by extra features, when they appear.
Integrating a payment gateway
We were choosing between two platforms: Stripe Connect and Braintree Marketplace. Relied on Stripe, since we had more experience with it. It’s the most popular and reliable solution with multiple payment options for users. Plus, it’s very convenient for developers — it offers a lot of documentation, examples of ready-made code.
There are three account types you can use with Stripe Connect: express, standard and custom.
- Express — an end user registers a new Stripe account for each particular platform.
- Standard — almost the same as Express but the user doesn’t need to create a separate account for every platform. If they have a Stripe account, it can be used on any platform with integrated standard Stripe.
- Custom — the user creates an account inside a platform: it doesn’t redirect them to Stripe, so they don’t leave the app. Such an option is difficult to implement (you need to know exactly which fields you need for registration, and it depends on the laws of the country where the platform works) and more expensive to develop.
We chose Express, since it’s the fastest and simplest option, and it’s cheaper to develop — perfect for an MVP.
What else is so good about Express? With this option you don’t need to think about KYC (know your customer) — client identification. In the USA, you need to pass KYC before performing any financial operation. Express has everything for KYC and we didn’t need to do anything custom on our side.
Finished in 3 months
We finished the MVP in spring 2020, then the client was testing the product and developing a go-to-market strategy almost until December. We didn’t abandon the client and had video calls with them every Monday.
After all the tests, they asked us to make a few improvements to the product. We added:
- ability to share content outside the platform by private links;
- several categories on the stage of project creation (tags that simplify the search for relevant content);
- subscription for buyers;
“Purrweb was the perfect solution for us to build the utmost viable platform. The way they worked helped us in building and designing our platform — better than we could have ever expected. We recommend Purrweb 100% for any of your developing needs.”, — says Lou Severine, one of the clients.