Principles for building developer products: a CTO’s perspective
Developers have always been at the center of Contentful’s mission. When I decided to found Contentful with Sascha, I wanted to work as a CTO for a company that served developers. I wanted to support developers like me, who worked in teams that impacted product and strategy along with technology. Contentful gave me the opportunity to do this and dive deep into the topics that excited me most.
Now, seven years later, I want to share with you the history of how we developed Contentful, what we learned along the way, and the three principles that guide our product. We believe that developer products should be accessible in price, documentation and setup, built with the latest technologies, and easy to integrate and automate.
These principles reflect our product vision and demonstrate how we will continue to support builders all across the globe as we continue to mature as a company. And they don’t apply only to Contentful. We believe that they are integral to all successful developer products.
Free, well-documented products let you start and scale quickly
I can still remember learning about Linux in the ‘90s. I couldn't just learn and build simultaneously from my desk. Dial-up connection limited internet access because of its hefty price tag, and raw manuals were all you could find online anyway. Books were also expensive. I remember going to the bookshop to read a few pages from the most updated books at lunchtime — and then try things at home at night. I’d be back at the shop the next day to try and understand why it didn’t work.
Luckily, this has changed over the last few decades. Now I can build prototypes of quick ideas in the span of a single lunch break. The general adoption of APIs and free access to developer tools and learning resources has sped everything up.
We believe that all developer products must be free and easy to set up. This is why we’ve always had a free Contentful plan for developers, and why we improved our plan with the Community edition. We want to enable developers to build any side project for free — let it be a blog, a cookie shop or something completely different.
It’s also why we’re making sure you have everything you need to get started. Documentation and guides speed up the development process, whether you’re dealing with HTTP endpoints and JSON in the form of APIs or figuring out how to model a content structure. Contentful offers hundreds of pages of developer documentation and a help center for web app users.
I’ve noticed that some companies treat the signup and onboarding flows as a minor matter. Nothing could be further from the truth. The time it takes from signing up to issuing the first meaningful API call has an outsized impact on the growth trajectory of any developer-focused company. Getting your website up and running in five minutes with Contentful is not a marketing slogan. It’s a pragmatic benchmark we measure ourselves against as we continue to evolve our product.
Documentation forms part of a successful developer product the same way that proper tooling does on the CLI. That's why we developed the Contentful CLI. It enables users to navigate our product and helps developers get started. And as we add new features and capabilities, we continue to insist that they’re scriptable and accessible via the CLI.
Incorporating the latest technologies ensures you’re ready for the future
If you bring up the topic of modern technologies at an enterprise gathering — and I can bet you my Nintendo Switch — the next three hours will be consumed by discussions about how to define the word “modern.” When I say modern, I'm thinking of new technologies that come with the potential for scale and mass-developer adoption.
When we built early versions of Contentful, we used Markdown for content editing, REST APIs for serving content and Angular.js for our web app. Those were the technologies to use and the rise of the Jamstack soon thereafter showed that we took the right path. Fast forward seven years and the technological landscape looks different. React has gained massive popularity, GraphQL has changed the way to query data and component-driven design systems are now the de facto standard. What does that mean for our product?
We constantly reevaluate our building blocks and, when necessary, rebuild key components of our platform to take advantage of new technologies. In retrospect, adopting Kubernetes to run our infrastructure was an easy call. But building the GraphQL API was not. Sure, GraphQL allows developers to query the data they need in a single API call, speeds up the development process, and simplifies technical architecture. But we needed to decide if we wanted to commit our engineering resources toward adopting a technology that, at the time, no paying customer had requested.
GraphQL's technical capabilities and the palpable excitement displayed by the developer community convinced me to take the leap.
GraphQL was by no means an isolated story. We went through a similar process when faced with the decision to transition from Angular.js to React to keep up with the JavaScript ecosystem. Or when we talked about replacing good-ole Markdown with a JSON-based Rich Text editor.
Now that GraphQL and React are becoming the industry standard for the next generation of digital projects, the bets seem obvious. But these types of decisions rarely offer easy answers when you have to make them. That’s why we adopted the principle of taking risks on the latest technologies to drive our decision-making.
Integration and automation increases everyone’s effectiveness
I’ve learned two important things about CMSes in the past decade of building Contentful. First, content is crucial for digital experiences. This means that in addition to connecting Contentful to the frontend layer, engineering teams expend tremendous amounts of energy bringing data in and out of our platform. Building extensibility into our product makes our users more productive and our platform more valuable to them.
We’ve consistently invested into adding new ways to integrate third-party systems with Contentful. We started with basic webhooks to communicate content changes with other services. Then we made our webhooks configurable. Because there was no standardized payload to connect services, this allowed developers to quickly integrate Contentful with other services. Then we opened integration to editors without technical training by launching our App Framework. Now users can integrate SaaS products like Shopify, Typeform and Cloudinary right in the web app.
Best of all, developers can modify the web app to their needs thanks to our open-source ecosystem. This creates a seamless content-editing experience even though it's built with multiple services. Content becomes a core part of your infrastructure!
I also learned that relying on manual content management is suboptimal. CMSes — just like every piece of software — cry for automation. Automating manual tasks frees editors to focus on more creative and impactful activities. But even more importantly, automation helps organizations turn the messy process of building new software into something much more predictable, measurable and reliable.
Take the example of adding new features to your website. How do you manage your content when your product is under heavy development? How do you make it scale without breaking things? We went to the drawing board and defined the idea of CMS as Code. Even though content is available via an API, structural changes must be able to be performed in an automated and safe way.
And what about migrations? We invested in CLI migration tools and extended our infrastructure with environments. Contentful now allows you to edit, change and evolve content the same way you code. Branch out, change, migrate and test. You can bring it back into your main environment after you know everything works as expected. The CI/CD workflows you use with your infrastructure can also manage your content — ready to scale! Contentful will continue to follow its third principle: developer products must optimize for integration and automation. Developers want to build, not perform chores.
Contentful: By builders, for builders
I'm happy to see that Contentful now delivers 500 million content delivery API requests per day (plus 30 million GraphQL requests and counting). We’ll keep giving back to developers with our free edition, and new features we develop along the way. We’ve made it free and easy to get started, so you can go forth and experiment!
