Why are you building this product and what has happened with jrnal.co?
Somehow the idea of having readers speaking to trusted voices; less verticality in how media content is delivered; the future of information being subject narrowness and strong editorial project; has always been around, even with jrnal.
Right after we managed to earn enough money to cover the costs at jrnal, I decided to spend some time with publishers. I had dozens of conversation and the same things keep coming back.
Publications we need to build an exceptional editorial project people actually want to pay — those that are still respected by the trendsetters — wanted to focus on their own subscriptions efforts as the market is substantially improving
Tech was a nightmare for every single one of them. I’ve rarely seen one deeply satisfied with its dev agency while big names such as Guardian were struggling to keep their tech people
I came back from my trip convinced that we would be more useful when supporting the rise of the next New Yorker or The Economist, rather than being at the forefront of their readers. Make sure they don’t have to worry about tech anymore.
Tech stack. Can media use the tools they’re already familiar with? Switch costs may overweight the benefits.
To build the product we use Ruby on Rails and React. Heroku and AWS to host our apps. Honeybadger and skylight to monitor errors and performance. Analytics is homemade. As it’s bespoke, we can tailor the application to our client's needs, with the opportunity to integrate peripheral tools media already know.
Please note that publishers don’t have to fully switch their CMS from the beginning. They can just plug our platform for their membership on their current website. They will have to use the platform for content dedicated to their members and keep their website for public content. For us, we are stepping inside the publishers' newsroom with our tech so it’s still worthy.
Upcoming product features and roadmap. Why do you want to build your own CMS?
We are meant to offer a more streamlined alternative to the typical process of cobbling together tools that are essential to making the small and medium publishing model work and we’ll evolve with the business needs.
Our roadmap debut is visible here. To a further extent, we shall add tools such as ML for personalisation and automation, VR and alike for experiences, data mining for audience & content analysis, metered paywall for conversion etc.
The product strategy we decided to adopt here is that rather than building thousand of features, roughly working and that will never be used, we will build/integrate them on a request basis. The current roadmap is the result of our discussions.
Why build our own CMS? Because we couldn’t offer a truly compelling experience — provide tools that will effectively help publishers to focus on what they do best, build a community and actually make money — unless we have a hand on everything.
We would otherwise be another plugin, one among Wordpress +13K other plugins.
State of the competition and your market positioning. Why would such a big company as FT (1M+ paying subscribers) want to use your solution instead of building their own on the top of their current CRM?
Regarding competition, Patreon is considering coming on this field. They are using Mc Sweeney’s like a beta tester. So is Steady, a German company focusing on solo publishers. Substack, which started by providing tools to build a paid newsletters is moving into Podcast but it won’t take long before they move here too. Wordpress, Google and Civil partnered to build Newspack which might somehow end up doing exactly what we are doing. But it’s meant to be available by the end of 2020. We have until that to make them irrelevant. Dennik N received funds from Google news initiative to build a back end (with no front end) which is kept open-source. It’s called REMP2020
We can also consider as competition publishers such as Washpost (Arc Publishing), Vox (Chorus & Concert io) which publicly stated about their willingness to license their tech.
Regarding our positioning, We are specifically targeting media with both, a subject narrowness and a strong editorial rigour (From The Carton to Guardian Weekly). Why these? Because they are the one with the most expansion potential outside of the “classical path”.
As an example, one of our first clients is Little White Lies, the London movie magazine. They have millions of subscribers potential, not only for content, review and columns they plan to produce but because they can launch a project like Mubi + curate numerous of movies theatre around the world + launch movies answer to MET Gala + Even start writing documentary for platforms such as Netflix or Amazon Prime … And still, be relevant for their journalistic mission and their members/subscribers.
It’s our mission to make sure they don’t have to worry about tech on the whole journey. This is what grabbed Sifted’s attention.
Why would such a big company as FT use our solution, Specifically for Sifted, it’s because they will be better off with The Athletic stack rather than FT stack. I have personally met with Sifted CEO and he is questioning whether he should build something bespoke or go with our tech… Going with FT stack isn’t an option. It's built specifically for FT need and move it toward membership alike model doesn’t just worth it.
In general, from what I have learned from 2 years in this industry: even though they have the financial resources, so far not every publishing outlets have the staff and capability to create their own program because:
It’s hard to attract and retain a good team of tech folks when the competition is all good tech companies out there.
It’s not seeing as a true competitive advantage to own your tech. The needs are the same. Back ends are roughly similar and only the front end identity and content finally matter to the business
Your current team and relevant experience.
Our most relevant experience is our previous company: jrnal.
Balthazar — Co-founder — Full stack developer — Ecole 42 & Wild code school — Bachelor in Cinema. B main job is building the whole tech, build the features, manage the back ends & servers and help on legal stuff.
Tristan — Co-founder — Design & front end — Former head of Atixnet Lille — Bachelor in Cinema — T main job is designing the whole platform + every doc, being obsessed with the UX, Integrate the features B built, help me on sales & prospection.
Konan — Co-founder — Ex-Financial Luxury Analyst & Self-taught web developer — Ms Finance & Political Sciences. I hold the product vision, in charge of the sales & prospection, working on the funding round et I write about the venture. I am also Balthazar’s intern writing code.