Berlin-based Contentful is an interesting startup solving a problem whose existence traditional CMS vendors have all but denied: managing content that is published somewhere else than in the channels the CMS controls.
North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.
13 August 2014
This article is a part of CMS selection article series by North Patrol.
North Patrol helps customers to make smart technology decisions and find the best implementation partners. Typically, we facilitate prestudy projects and evaluate vendors and proposals. Most of our clients are large companies headquartered in Finland.
Most CMSs have always presupposed everything is built on top of the CMS platform. Contentful approaches the world from a different angle. They provide a CMS that doesn't do templates, and doesn't do publishing. Contentful is just a content storage and a simple content editing tool that can be accessed via APIs. In many ways, this idea of having the CMS as a truly backend system has always existed, but for some reason hasn't gained wider popularity. Contentful is now the new kid on the block that wants to change this.
I interviewed Sascha Konietzke from Contentful in Berlin where Contentful has their office near many other startups in Kreuzberg
How do you usually explain to people what you are doing?
Our product is an API-based content management platform. We like to describe it that we are the same for content as Amazon web services is for a lot of other stuff. Amazon has different APIs for different use cases, such as EC2 and S3. We also have different APIs—an API for editing content, and an API for delivering content. We like the idea of creating these purpose-built, focused tools for developers.
Currently most of our users are developers. But we are seeing a lot of different client types. Often our tool is used to build rapid prototypes, and then after the prototype is ready, the customer wants to use us also for the production service.
We have many thousand companies on Contentful at the moment, but not all of them are paying ones. I can't tell more precise numbers, unfortunately.
What kind of journey have you had so far?
We launched the beta of Contentful last summer. We started by building the APIs. After the launch, the editing interface has also demanded quite a lot of work to be just right and cross-browser compatible. Approximately half of our development time is spent developing the editor and the other half goes to the APIs. We are currently 13 people here in Berlin.
What are your most typical usage scenarios right now?
The most typical scenario is a native mobile application running on iOS or Android. Many people don't want to put their content on a traditional CMS. So they like our model where they can just access the APIs to get the content. We also offer additional services, like content synchronization, which is pretty useful for many apps.
There are also a million other usage scenarios, and investors have been asking us this all along. Media companies and publishers are definitely interested in us, but right now we are also seeing the tool being used in various other industries, including financial companies and healthcare. For example, many iPad applications benefit from having the content synchronized, updated and accessible all the time.
How do you handle high-traffic scenarios?
We have built the content delivery network to scale from the start. Everything is cached and our CDN covers all the pieces. We are using Fastly as our CDN. That really helps us deliver content at an amazing speed and be highly scalable.
What kind of agencies are interested in you?
Tech-savvy digital agencies. Usually these agencies already have experience in building custom CMS tools for their clients. Many have used WordPress or Drupal so they know the limitations the template systems can cause. Especially in scenarios where you need to do a lot of customization, the CMS can be an obstacle. Our way gives agencies complete freedom in many ways and also gives customers nice tools for editing the content.
How do see yourselves compared with WordPress and Drupal?
I think WordPress is a very different tool for different purposes. We don't really yet have a story how we coexist with existing CMSs, but we definitely see ourselves more as a coexisting tool than a competing tool. Especially since we can also be used as a content delivery system.
Drupal is also developing towards more of an API-based system. But from our point of view, most CMSs are much more about managing templates and presentation. Content delivery through APIs is not their core functionality.
Our strength is also the content delivery network that comes with the product. Users don't have to worry about the content delivery since the product comes with a cloud-based delivery system.
Being a cloud-based system also enables us to do rolling updates. We don't have to worry about big version rollouts.
Isn't the content delivery tier a very different business from building a structured content editor?
At least for now our business is much more about the delivery part. Our editing tool is not very sophisticated yet. Many existing CMSs offer a lot more features, for example in workflow management and permission management. We are still more focused on solving simpler challenges. Most of our clients are also primarily interested in our content delivery system.
For example, previews are a hard requirement for us. If the client is using the same content in 16 different mobile applications, building the previews is a really hard task. Currently we can also provide unpublished content through our API, so clients can build their own preview applications—and some of them do.
We could naturally build simulations so that, for example, users wouldn't upload excessively large images to the iPhone applications, but those would still be just simulations.
You have two very different client groups: large media companies and digital agencies. Which is more important for you?
Agencies also bring us new media company clients so they are not always that different. Media companies are valuable for us also because they innovate new ways to use us. Some of them are even seeing us as a content platform for all of their content. Many media companies use many different kinds of editing tools, so we offer them a way to unify the delivery part. And we can also operate as a licensing partner for their content.
What are your biggest challenges at the moment?
The biggest challenge for us is hiring. I'd like to find 20 new people right now. From a feature perspective we are going towards a workflow system and permissions system. In those areas the challenge is in keeping them simple, yet powerful. They very easily become so complex that nobody can use them anymore.
How far can you go with your current funding?
With the current funding we don't have to worry about anything at least for the next two years or so—and that includes growing the company by at least 100%. We also have a strong group of investors and advisors that are well known in the industry. That gives us a lot of credibility.
Final words, anything you have learned about the content management industry during these years building your CMS startup?
The whole content management market has a big positioning problem. Everybody is calling themselves a content management system but in many cases they are just website builders or web publishing tools. Everybody is also saying they are doing mobile even though they are just doing responsive design. All this confuses clients.
We are also seeing that there is a lot of divide in the field. The php world is living in its own bubble, then there are the enterprise CMS guys and a lot of these "modern-age developers" who are using more modern languages like Ruby and Python. This last group is not interested in using traditional content management systems at all, but they still need to manage content for the applications they build. Naturally they are the most interested in us right now.
