The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers, 40 gigabit networking,   dedicated CPU and GPU instances, and worldwide data centers.  

Go to python podcast.com/linode,   that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show.   And do you want to get better at Python?   Now is an excellent time to take an online course.   Whether you're just learning Python or you're looking for deep dives on topics like APIs, memory management,   async and await, and more, our friends at Talk Python training have a top notch course for you.   If you're just getting started, be sure to check out the Python for absolute beginners course.   It's like the 1st year of computer science that you never took compressed into 10 fun hours of Python coding and problem solving.  

Go to python podcast.com/talkpython   today and get 10% off the course that will help you find your next level.   That's python podcast.com/talkpython.   And don't forget to thank them for supporting the show. Your host as usual is Tobias Macy. And today, I'm interviewing Jake LaMotta about butter CMS and the role of a headless CMS in the modern web ecosystem. So, Jake, can you start by introducing yourself?  

[00:01:48] Unknown:

Yeah. My name is Jake LaMotta. I'm the founder and CEO of Butter CMS.  

[00:01:52] Unknown:

And do you remember how you first got introduced to Python?  

[00:01:55] Unknown:

Quite a while ago at this point. I had started in PHP,   kind of dabbling in the web back in middle school, kind of early high school days. I started with a friend who introduced me to Python   and Django simultaneously, and also kind of the MVC   concept, you know, framework concept, model view controller concept.   And compared to PHP, I love the syntax of Python.   You know, PHP, at least the PHP that I wrote, I mean, inherently, it has, you know, dollar signs and semicolons kind of all over the place.   And not being very good PHP, mine was   certainly littered with those. So when I saw the syntax of Python, it was just like, wow. This is really clean and nice, and it just sort of felt like a nice kinda logical way to write code. So I was I was drawn to it by that.  



[00:02:38] Unknown:

Before we get too far into Butter CMS specifically, can you start by giving a bit of an overview about what a headless CMS is and how the use case and user experience differ for that as compared to traditional CMS such as WordPress?  

[00:02:52] Unknown:

So the term have a CMS is kind of a weird term, admittedly. Certainly, when I started Butter, I didn't call it to have a CMS. I didn't even know what to have a CMS was. I never heard of the of the concept. I thought of butter as what it is sort of on a technical basis, which is an API first CMS,   meaning   sort of an API first approach.   So there's really 2 parts to, like, ahead of CMS.   1 is the API, like, so the content API, which is what,   you know, the companies, developers will query content from is the content API,   and they pull that content into their own native application built in any tech stack that they want. And then the other piece is, of course, the content dashboard, which is where the marketers go in and actually marketers, clients, whoever, you know, they go and actually manage the content. So it's easy to use kind of from the dashboard. You can actually go create the actual blog post or landing pages and that kind of thing, upload images, do all that kind of stuff, and you don't need to be technical to do it. So that's sort of what I have with CMS is at a very high level. It's really the content API or set of APIs as well as the content editing dashboard itself. Yeah. And so as far as the use case and user experience and how it compares to a traditional CMS like WordPress,   so   on the marketer side,   on the surface, it is somewhat of a similar experience   to WordPress in the sense that, you know, the goal there really is to provide the marketer a really easy to use UI, you know, they don't need to be technical to use it, to update content and, like, do their jobs. And WordPress does this pretty well, you know, generally speaking. Certainly,   that's why it's so popular.  

On the dev side, though, is where   things change, and it's really kind of a night and day difference.   So with the Huddl CMS, like, with butter, you get to work with any tech stack. You get to work with the 1 that you're most proficient with. So, you know, if you prefer to work with Django or Python, you can start there, and you build out your own   application,   you know, marketing website using   using Django, and then you plug CMS capability into that. So you plug, you know, like, the content API   into   your own kind of native stack.   And with WordPress on the dev side, of course, this this WordPress flips this on you completely. So you don't get to start with again, assuming you're a developer who prefers Django   in this   example. If you wanna use WordPress, you   basically abandon Django. I forgot it right. You gotta dive into the WordPress world. So you you start with WordPress. You start with it as a sort of complete stack.  

You know, you would need to master its terminology,   how it works, the internals of it, its code base,   database schema,   of course, diving into PHP since that's what it's built in.   So you really go, you know, from there and kinda start hacking and slashing WordPress to customize it to do and behave the way you want it to. So it's very different approaches, very different experiences   on the development side.  

[00:05:39] Unknown:

Another interesting way to think about the use cases for headless CMS is, as you mentioned, versus   integrating   versus integrating   a framework such as Django CMS or Wagtail into your existing site for being able to manage that content and have it very tightly integrated with the overall application that you're building.  

[00:06:05] Unknown:

Django CMS, Wagtail, these are what I kinda think of as, like, traditional CMSs.   Every language or framework has these,   where they're very often, you know, open source CMSs   built in, you know, a particular native language, Django,   Ruby on Rails, etcetera.   And they're very similar to WordPress in the sense that, you know, they are large pieces of software   or maybe not large all the time, but, you know, they're they're pieces of software that you need   to own. So you need to install it, you need to host it and run it, you need to maintain it, so you need to patch it and ensure that it stays secure and up to date, and you need to customize it. And in order to customize it, if you need to customize it beyond sort of   its native capabilities   or, you know, its native API, then you need to dive into, like, the guts of of how it works.  

So, you know, those are some of the drawbacks with their traditional CMS is they are quite software heavy as opposed   to head of the CMS where   in terms of software,   to adopt the Headless CMS,   it's very, very light software wise. So, all you're really doing is you're querying the Content API,   which returns   just the raw content for, let's say, a blog post. When you query the content API and it returns, like, the text values and the images for that piece of content, for that blog post.   You can think of it in a way as instead of, like, querying your own database   with a table of blog posts,   you're querying   that same data from an API, basically.  

It's a very lightweight approach   to get fully functional CMS capability.   And in our case, with Butter, there's certainly open source, the CMSs, and for those, you'd need a host to maintain them, and all that kind of stuff comes into play again, if you go that approach. With with butter, we've decided to be sort of SaaS only, and so we handle   all of the infrastructure   and security and updating that kind of thing. So that's some of the assumptions that I'm making when I'm describing this. Can you dig a bit more into what you've built at Butter CMS, and what  

[00:08:04] Unknown:

motivated you to build a business around this particular problem area?  

[00:08:09] Unknown:

Kind of the origin of Butter   ties back nicely to to WordPress, honestly. So at previous companies,   I led engineering at a couple other start ups, and those start ups actually were built the the primary technology stack was Django.   So the business was sort of like an online marketplace for energy. So the business was the website that was the case. And so we had this custom marketplace   built out in Django,   and the marketing team came along 1 day. Yeah. And this is my mind, of course, the developer's perspective. So everything's happy, and then 1 day,   the marketing team comes along and they and they say, hey. We need to do our jobs and we need to be able to, you know, write blog posts, and so we need a blog for our site. It's, like, okay. Well, the first time around, I said, well, let's just go with WordPress because it's WordPress and that's what everyone kinda does.  

And so that was my first foray   personally into trying to get WordPress to work with the existing Django site. And at the time, I didn't have deep experience with WordPress, so ended up trying to find a WordPress consultant developer to help kinda build this out. And   they were a very capable developer, but even with that, it still took a really long time to   just get it to work, you know, to honestly just add a blog to our existing site. I felt like it should have been really, really trivial. Now, I should I should note that we didn't just go kind of the subdomain approach where you just do, like, blog.mysite.com.   We wanted it to live within the main domain of the site. We wanted, you know, my site.com/blog,   which is better for for SEO purposes.  

And so when you start doing that route, you get into the complexities of, like, URL routing and how the jingle URL routing   matches and plays nicely with the WordPress routing. And, like, who should own what part of the routing structure and that kind of thing. So anyways, it ended up being a really long, kind of painful process,   quite expensive.   And then the final product, again, I was not experienced in WordPress personally.   So we had outsourced the development of the WordPress blog, but now we, of course, had the problem of, I guess, I had the problem of how to maintain this thing. So anytime bugs came up or a security patch needed to get applied, that was on me to kind of own that and figure it out. So that was was kind of a painful process, and then that company got acquired into a larger company who did the same thing, and it was literally a case of deja vu. We went through the same experience.   Also built in Django,   and we needed a CMS, we needed to add CMS to the site. And that time around, I had learned from the first attempt at this. And so I kind of advocated internally, like, we should not go the WordPress route.  

And kind of going back to 1 of your previous questions, we actually went, we tried 1 of the open, I forget which, it was not Django CMS, but it was another CMS like that. It was an open source, kind of free CMS, and we tried to plug it into   our Django stack.   And it was cool from a developer perspective, and this also ties back to the question here of, like, what was my motivation for starting butter? So we used, like, an open source   Django   built CMS. And from the downside, it was like, this is cool. Like, this is designed to plug into our existing site, the Django site. But then on the marketer side, the editing experience was left much to be desired. It was really kind of clunky, hard to use, and there were still a lot of kind of problems that we had to solve as far as like making a nice experience to upload an image and, like, serving that image from a CDN, like, all that kind of stuff. So we lost that battle   with the marketing team, and eventually,   we ended up going down the WordPress route again. Yeah. So that was kind of the origin story. It was like, I sort of reflected back on the experience and said, like, there's got to be a better way to do this, you know, there's got to be a better, easier way. The marketers get an interface, like, the dashboard that they love to use, just like the WordPress   technologies   that they prefer, that they're most proficient with, and   being able to plug CMS right into those, like, right into that tech stack, whatever it is. So that was really the motivation. It's like, from a developer perspective,   what would be an optimal way for CMS to work for both developers to get integrated quickly, as well as for marketers to have a great experience managing content.  



[00:12:06] Unknown:

And another use case for having the CMS be an external service to the application is that if you happen to have multiple products, then it makes it easier to be able to use the 1 service across those different applications and be able to potentially reuse content, either just image assets or repurpose blog posts or reuse at least the general framework for landing pages and things like that?  

[00:12:32] Unknown:

Yeah. And that's a great point. And that's actually 1 of the strongest, potentially, you you know, arguments for headless CMS is that so the term headless, to kinda speak on that, is I never learned this in computer science, but apparently head refers to sort of the presentation layer of an app. In any case, that's what headless CMS means. It means basically the CMS system is focused on sort of the raw content,   and that content can get pulled into any and many front end systems   to present it. Right? So you could have, to your point, you have blog post content, you might have a desktop website that displays that content in a nice presentation for desktop,   and maybe that that's built on React, maybe it's built on Ruby on Rails, maybe it's built on Django. And you can also have a mobile, a native mobile app, you know, for your company that also displays that exact same content.  

And because Hadoop, CMS doesn't control the presentation, it doesn't control the front end, it just serves up the raw content, you could build that mobile app to then display that exact same content in a really friendly way for that platform, for that medium. So that's really powerful when you get into, again, as you mentioned, like reusing and repurposing content. So in butter, you sort of have these, like, it's more of like a kind of logical approach. Like you organize and structure your content in a more logical fashion, in sort of a more normalized fashion.   It's more of kind of like a data modeling exercise, and you think about it that way of, like, how do you actually set up content in a clean,   normalized way? And that allows you   to very easily repurpose it and reuse it in as many different places as you want, which is quite powerful.  



[00:14:01] Unknown:

To the point of treating it as a data modeling exercise and because of the fact that a lot of the people who are interacting primarily with the actual content creation side of things   don't necessarily   have as much of a background in the   technical aspects of doing things like data modeling or understanding the right abstraction layers. How do you approach the challenge of exposing some of those concepts to   the marketers or   to the content creators who are using Butter CMS for being able to create this information and make it reusable or remixable for being able to either use it across multiple platforms   or have core pieces of information that they're able to then plug in to different representations   or different, you know, timelines for being able to republish content?  



[00:14:51] Unknown:

It really goes into just kinda more disciplined up front planning of how the content is going to be used, what content needs to be managed, where it's going to be displayed and presented.   So in the case of butter, we have a concept called components.   And components are really meant to represent   or sort of map logically very nicely to kind of the UI   for your sites. You can decompose your, like, your home page of your website, for example, or some of the interfaces of your mobile app into into these components. So the example of a component would be image carousel.   Another 1 might be, you know, like a banner. Another 1 might be a call to action with a headline and a button or something like that. So you can sort of as a team, between the developers and the marketers, you come up with a common language   to say, like, okay. What are what are sort of, like, the set of components   that we want to provide to the marketing team so that they can go do their jobs completely independent of developers? And so that's kind of how   things play out. So in the beginning, again, marketers and developers collaborate and say, like, what's this library of components that that we really should be focused on creating? And then developers, designers, they'd go and implement that, and then hand it over to the marketing team, and the marketers are then completely empowered to, you know, compose content using   those set of components in any order, in any fashion that they want. So it gives them a lot of flexibility   to create   dynamic landing pages, blog posts, that kind of thing.  



[00:16:16] Unknown:

In terms of the overall scope of the ecosystem for CMS   platforms, both open source and commercial,   how do you view the current state of affairs, and what is your perspective on the way that ButterCMS   fits within that overall space?  

[00:16:32] Unknown:

In terms of CMS, there's a lot.   It's quite robust. Certainly, CMS is not new.   There's a lot of options to choose from, spanning industries,   use cases,   you know, company sizes.   So there's massive, massive enterprise CMSs, there's   small, free, open source, super lightweight CMSs.   There's so many options to choose from. So my 1 thing would be just, you know, pleading, like, please do not build your own CMS   if that's not like what your core business is   doing. Like, there's just a lot of options out there. So   if you can avoid it, you know, try to avoid building a CMS and then just use 1, anyone   internally.  

So we've spoken to some companies who, you know, maybe have a legacy   CMS that they built 15 15 years ago or something like that,   and   they're sort of taking a step back and looking at, you know, how much time is our development team spending maintaining this thing? How happy is our marketing team with it?   You know, when you build your own CMS,   it is trivial. It's like, Okay, let's just build a CMS to manage blog posts, and it seems very trivial,   But to build a great experience for the marketers   and by great experience, I mean, you know, just intuitive where they can just do the simplest things that they would expect to be able to do, upload images, resize images, have those images serve on the CDM,   embed videos, you know, all that kind of stuff. It adds up over time, you know? And so it may not be obvious on the very outset,   you know, to create like a blog post CMS, for example,   but it does get quite complex. And so we've seen a lot of companies kind of over time say, hey. You know, first of all, the experience that we built because it isn't our core business, like, you can't justify   spending time   maintaining the CMS and and improving it. Like, that's not your core business. I've just said, you know what? We're just gonna hand it over, and we're gonna migrate it over to butter and kinda let you guys sort of sort of manage it.  



[00:18:20] Unknown:

In terms of the overall state of the ecosystem for web development,   what do you see as being the driving forces that have made the headless CMS   become sort of the default approach these days where   the traditional CMS was very popular in the early to mid 2000. And in the past, at least, couple of years, I've seen a lot more movement towards the headless approach to CMSs, but also a number of other back end systems.  

[00:18:47] Unknown:

Have you heard of the the term Jamstack?   Yes.   So   there's a lot of marketing   around Jamstack, and it seems like it's getting a lot of popularity.   It's certainly a new kind of novel approach building web apps. And in terms of how the CMS plays really nicely in that world, Jamstack, for those aren't familiar, Jam is jam, so JavaScript   APIs and markup. So the idea is is basically   kind of no formal back end server, like running an application as you would in a Django or rails or dotnet scenario.   And   basically a bunch of services   that provide APIs, and you have, you know, JavaScript that queries those APIs   and pulls it into a front end, you know, being the markups to the actual presentation of it. And so there's a lot of marketing where   if you are new to the space, it feels like Heather CMS is popular probably because Jamstack is also gaining popularity.  

And there's also these   hosting platforms   like Netlify, Vercel,   now Cloudflare Pages, they just launched their own solution.   These hosting companies effectively   really kind of focus in, the Jamstack use case and statically generated websites.   So it's a very whole sort of kind of new approach to building websites. I won't argue that it's necessarily or strictly better. There are certainly pros and cons.   So there's a whole set of pros to having a statically generated site,   and I think there's also a whole set of cons as well, as opposed to, like, sort of traditional,   just sort of Django,   you know, application server just running and and doing things kind of the old fashioned way or whatever.  

So, anyways, kind of going back to your question. There's a lot of marketing around this, and it feels like Jamstack like, how the CMSs are popular because of Jamstack.   But it's funny because as I described before, my personal pain was it had nothing to do with the Jamstack.   I wanted to add CMS capability to   a tech stack other than WordPress, honestly.   And so   that's why it is   for butter.   And so   in my view, I feel like how the CMSs are popular because   developer there's there's more ways to build modern applications and websites ever before,   even going back to what you might call old, like, Django as a framework or Ruby on Rails. You know, if you want to build a site   using those technologies   and you need to add CMS capability to it. Have a CMS is really kind of like an optimal way to do that. So that's my view on it.  



[00:21:03] Unknown:

In terms of the actual content that people are using CMSs for, you mentioned blog posts, you mentioned landing pages, but I'm wondering if you can dig a bit more into the types content that are being produced and managed within these systems.  

[00:21:16] Unknown:

In terms of the type of content,   it's been pretty cool to see   sort of the diversity   of   industries and use cases,   you know, like the types of companies, what industries they serve, and   ultimately, you know, what kind of content they are looking to manage. And so it's been pretty cool because, really, you have seen everything you can sort of imagine, you know, from there's a hardware ecommerce company   that's managing, you know, marketing information, literally about nuts and bolts, you know, to   cryptocurrency   startups,   to, you know, large health care systems who   need to manage some   customer facing   kind of intranet portal content, you know, so if a customer logs into their health portal, there's like news and updates and that kind of a thing, and   they   can kind of plug butter into power of those things. So, you know, so the diversity has been really surprising and really cool, it's been really fun to see that. But, you know, most commonly, if you kind of had to boil it down, it's the stuff you would expect, you know, so it's mostly kind of marketing content, public facing content, such as blog posts,   landing pages,   e commerce content, you know, and the most common types of companies are like SaaS companies, e commerce companies, marketplaces, and those kinds of things.  



[00:22:31] Unknown:

You mentioned too the fact that   by using a headless CMS, it relieves your application development team from a particular concern within building something like a Django app or a Flask app. I'm wondering if you can talk through a bit more of the ways that people are integrating headless CMSs into their Python applications specifically?  

[00:22:52] Unknown:

Yeah. For sure.   You know, when I started Butter,   again, just given my background in Django, I the the first 2 frameworks that I focused on were Django and Rails.   When I say focused on, I mean, in terms of, like, you know, which ones we should kind of formally support   with an SDK.   You know? So we built out a Python SDK, which is basically it's a really lightweight wrapper around our content API. Just makes it easier to to actually fetch, pages and blog posts from the butter API.   In terms of actually integrating   butter into, let's go with a Django app,   it's basically these 3 high level steps. So the first thing, let's say you want to add a blog to your Django app   that, of course, doesn't have it. So the first step is, you know, you would add routes   just like you would for any other page. So you'd add, you know, some blog routes   to power your blog homepage and and the blog post page. So you have the routes. Those routes connect to Django views, you know, like the actual back end logic. The views are quite simple. So, basically, in the view, you're making an API call to fetch   the blog post content.  

So, you know, in the case of your blog homepage, you may be showing the 10 most recent posts as an example. So   you have a route for that. You have a Django view for that. In the Django view, it makes it, you know, kind of a 1 liner API call to fetch the 10 most recent posts.   And then you,   you know, the the data comes back.   The raw API returns data in a JSON format. If you're working with the Python SDK,   you know, we we kinda massage that a little bit when you deserialize it, but it's really easy to work with, you know, so the blog post structure   is common attributes you would expect. It's got an author, it's got a publish date, it's got a body, etcetera.  

And then you can very often just pass that entire payload from the API, like, the response   right into   the template context.   You know, so you pass all that data right into   the context for the template, again, in the case of Django,   and then the template just sort of renders out all of those variables into   the HTML and CSS to render out the full Blanco.  

[00:24:52] Unknown:

Python has become the default language for working with data, whether as a data scientist, data engineer, data analyst, or machine learning engineer.   SpringBoard has launched their school of data to help you get a career in the field through a comprehensive set of programs that are 100%   online and tailored to fit your busy schedule.   With a network of expert mentors who are available to coach you during weekly 1 on 1 video calls, a tuition back guarantee that means you don't pay until you get a job,   resume preparation, and interview assistance. There's no reason to wait.  

Springboard is offering up to 20 scholarships of $500   towards the tuition cost exclusively to listeners of this show.   Go to python podcast.com/springboard   today to learn more and give your career a boost to the next level.   And digging more into Butter CMS specifically, can you talk through how the actual platform is implemented and some of the ways that the design and purpose has changed or evolved since you first began working on it?  

[00:25:53] Unknown:

Butter is built   in Django.   The the most of it is built in Django.   The front end, especially in our dashboard,   it's evolved quite a bit over time. So we introduced Vue. Js to make   the dashboard a bit more responsive   and just a better experience. So it's Django kind of on the back end, Django REST framework for the API,   amazing API framework, Vue. Js on the front end.   That's sort of kind of the core platform. And then we use a bunch of caching   services and other providers. So, for example,   we use a service called Fastly   to help with caching and serving up our API.  

So what that means is Fastly has a, like, a global CDN   of, you know, kind of edge nodes   all across the world.   And whenever you, quote unquote, make an API call to Butter,   the very first time you make the API call, you know, it does it in our application server, we generate the the JSON payload, return it back to your app. The next time you make the same API call,   that full JSON payload is cached at the edge,   and so you get an instant response   from the Fastly server.   So so so we use services like that to help with performance caching,   availability,   response time, that kind of thing. We also use Amazon CloudFront   for hosting   media. So anytime you upload images into Butter,   we can, kind of process that image and put it into   put it into our CDM, which is powered by Amazon CloudFront, that kind of thing. But it's not overly complex. That's kind of the foundation of it, you know? We do keep it pretty   simple from that perspective.  

As far as how it's changed or evolved since we began   working on it,   performance is probably the certainly the top thing.   So,   you know, it's a good problem to have.   We've been fortunate to kind of grow over the years, and so it's a good problem to have, but it was definitely   it was definitely a problem to solve in terms of performance and response times. So, you know, when people call our API,   we're looking for, you know, sub 200 milliseconds, sub 100 millisecond response times because they're loading their page based on that response.   So we're looking for really fast response times.  

And, so there's a lot of work that we've just kind of done over the years   of, 1st, caching caching caching. This caching as much as we can,   as often as we can,   precisely as we can,   kind of at all layers of application. So I talked about Fastly, which sort of sits at the top. That's, like, the kind of the global CDN. And then, of course, within the application itself, we have sub several layers of kind of memcache and that that type of thing   to to output response times as well. And then we've done a bunch of database query optimizations.   When a request sort of makes it through   all the layers of of caching defense,   and we actually do need to hit the database that those queries are ideally as efficient, you know, as possible.  

So that's been yeah. So performance has been 1 huge area.   The other huge area is capability.   So   this is something I think probably most systems deal with, but   capability in the sense of, like, what you can do with Butter, you know, like, what are the use cases you can actually use Butter for. So in the very early days, you start off just focusing the blog use case, and over time, expand it into, like, a fully fledged CMS where you can build landing pages and all sorts of content types and stuff like that. So, you know, over time, our data model has gotten more complex as we build more capability, more features, and that type of thing, and just made it a more powerful system as far   as what you can actually do with it, you know, how flexible you can actually be when using Butter.  



[00:29:21] Unknown:

In terms of your actual journey of going from this idea of, I'm going to build a business around content management and making it easy to integrate a blogging engine into   overall journey of getting from point a to point b.  

[00:29:43] Unknown:

So butter is customer funded. We've not raised any money.   And, yeah, the journey has been kind of slow and steady from that standpoint,   and so it's not the venture backed route by design,   honestly. I had experience at venture backed startups at my previous companies, and   there's a whole don't need to dive into that, but it's not my preferred way of building a business, running a business, the incentives and stuff like that are not really kind of aligned all the time with customers. So   with Butter decided just to take the old fashioned approach and build a profitable   customer funded business.  

So the journey, yeah, honestly, you know, day 1 was   sort of leaving   with that experience where I tried to integrate WordPress into Django   and come up with my own   thoughts of, like, what would an optimal way like, what would an ideal experience be? Again, speaking primarily from the developer side, of course, the marketers need the dashboard, but, like, from the dev side, how would it work? And then saying, like, would anybody pay for this? You know? Like, would anybody pay for this? Is this even a problem that other people have? And so I was able to go from 0 to 1, and that was a huge milestone.   And then when I found 1 person to pay for it, you know, then the next question said, can I find 5 people to pay for this? And when I found 5 people who, like, you know, weren't my friends or whatever, then it just kind of kept growing from there. You know, can I find 10? Can I find a 100?  

And I've just kind of tackled milestone by milestone,   slowly but surely. You know?   Now we've actually got kind of a team in place and   have the CMS as a thing. You know, again, this was not, like,   some master plan. It was just I didn't even know what how the CMS was at the time. It sort of stumbled into it, you know, and apparently how the CMS has this kind of marketing momentum behind it. So we're have the CMS.   So we're have the CMS now.   But the origin of it has always remained true of just being a really great way to add seamless capability   for developers quickly   into whatever tech stack they want, and then for them to be able to hand it over to the marketing team and for the marketers to be super happy with what they provided. So,   yeah, it's been,   feel very fortunate, and and it's been a pretty awesome journey.  



[00:31:43] Unknown:

And in terms of actually building a content management system, as you mentioned before, at first blush, it seems like, oh, this is easy. I just add a model for being able to have text, and then I render it out to the front end. But what are some of the hidden complexities that you've had to tackle and some of the areas   that have been most challenging for being able to actually make a CMS that is   easy and pleasant to use   and something that other people want to actually give you money for?  

[00:32:11] Unknown:

I think most of the challenges revolve around   the marketer side, like, a great marketer experience.   You know, from a developer standpoint,   you know, how hard is it really to create sort of a rudimentary kind of   let's take Django or Rails, you know, just, like, build out a simple database table or a Django model that represents a blog post, it's pretty trivial   to, like, you know, figure out the schema for that. What's not trivial is building a great UI interface that layers on top of it.   What's not trivial is   all of the kind of edge case   marketing requirements and asks that pop up over time, you know?  

So, like, the very first data model for a blog post was   I'm I'm trying to go back and think about some, like, basically, the first feature requests, you know, that that came. Can blog post have categories? Okay. Sure. We added categories. Hey. Can blog post also have tags? Okay. Sure. We added categories and tags. Hey. I need to be able to upload images. Okay. So we built, like, an image   uploader file manager. Hey. I need to be able to resize images.   How do I embed videos?   You know? So, like, just all these kind of edge case sort of marketing requests, and that's just for blog posts. When you get into actual, like, more complicated   content modeling scenarios of, like, landing pages,   hey. I need to build an image carousel so it can have up to 4 images, but no more than 7 images. You know? How do I reorder the image carousel to be below the call to action on this page? Like, all this kind of flexibility and capability that marketers want. And it has to be sort of intuitive and easy to use. You know? It can't be some interface where you're like, well, you know,   you're asking the marketer to sort of manage   JSON files or something like that, you know, which is funny enough and not super uncommon sort of first stat that some companies do internally is they build out, like, you know, they literally have this sort of massive JSON file   that they put together, and it powers sort of the front end of their website. And then the developers ask marketers to they're like, hey. Can you just go edit this JSON file? You know, just edit the text or whatever to be whatever you want it to be. Of course, that means marketers actually need to, like, open up a text editor and commit, like, make commits to this thing called GitHub. So whenever you go down that path, like, marketers are not gonna be happy. Anyway, so the whole marketing side is not obvious as far as   really what goes into it. The other part is   scaling. So if you're, you know, lucky enough where you   are experiencing   really great growth,   you run into scaling challenges, you know. So 1st and foremost, like, okay, building an image uploader, it's not rocket science, but now that image uploader should probably tie into an actual, like, proper CDN.  

So now you gotta, like, get all your images hosted in the CDN so that your blog posts and pages load really fast so your visitors get media served in an optimal way. If you run into other scaling challenges, like, wow. We have a lot of traffic on our site. We are like, well, maybe we start caching some pages.   Well, if you start caching pages, you need to come up with a cache purging strategy.   You know? So there's just a whole lot of logic that can go into cache purging.   You can have a kind of a sort of a lazy brute force cash purge strategy, which is like, anytime any blog post is updated,   just clear the whole thing. You know? Obviously, that's not optimal.  

You want to have a precise cash burn strategy to say, like, okay. If just this particular blog post was was updated,   like, let's only purge just the cache entries for that blog post so that we're not clearing the cache for everything else. So there's a lot of considerations that go into to scaling it as well. Those would be, like, the 2 kind of big areas that I think are probably the most non obvious   when building it on CMS.  

[00:35:34] Unknown:

In terms of some of the ways that you've seen it used, what are some of the most interesting or innovative or unexpected   ways that you've seen the Butter CMS platform employed?  

[00:35:43] Unknown:

It's been really fun. So the biggest surprise is just the breadth of industries.   You know, there's the typical ones, like tech startups and stuff like that. But,   you know, we've seen   everyone from like law firms,   to health care, to crypto startups,   to like real estate companies,   to food delivery companies,   SSL vendors,   gourmet pet food delivery,   conference platforms.   I mean, I guess it kind of literally is like any business that has a website, you know, could theoretically   have a need for a CMS. So   I suppose when looking at it that way, I shouldn't be so surprised, but it's just been pretty interesting. You know, you might assume that only super high-tech startups might use this kind of a thing, but it's not the case,   at least in our experience, really, at all. It's really like anyone who's using any kind of technology stack that's not WordPress   and they need seamless capability,   you know, butter really does appeal to them. You know, and it's been pretty cool and fun. Like, it feels really awesome to be helping these companies, and it's really enjoyable, you   know, when you discover new companies that are doing something novel just by seeing, you know, like, who's signing up for butter and, like, what they're working on. It's been kind of an unexpected   perk or or experience,   you know, what what have you kind of building building butter as a business. It's actually a way to discover other companies and, like, what other people are working on. So, like, we have lots of Y Combinator companies that have signed up for butter, And, like, 1 recent 1 that came up that I thought was pretty cool is, like, they let you package together   your dream house online. So you, like, go to the website, They help you, like, find a lot for your home.  

You can, like, pick out the interiors,   and then they help you find builders to execute on it. So, you know, just stuff like that. Like, it's pretty cool that that company   exists and that they found butter and that they're using butter to, you know, kinda help solve some of their dev challenges.  

[00:37:28] Unknown:

And in terms of your experience of building out the technical platform and the business around it, what are some of the most interesting or unexpected or challenging lessons that you've learned  

[00:37:38] Unknown:

in the process? I don't know if scaling was unexpected.   You know, if you grow, that you're going to have to figure some things out. I don't think that's a shock to anybody, but just when you get into, like, the nitty gritty details of it, of   just, like, yeah, how do you solving some of those problems? How do you determine, like, when you need to   stop working on new features and, like, halt all feature development, like, we need to focus on scaling, you know, which is not sexy.   Customers don't see it for all intents and purposes. Like, you know, you can put a lot of effort and time into building some new caching algorithm and cache purging strategy, but from a customer's perspective, like, that doesn't really do anything for them. Like, they they can't do   it's not cool or sexy or whatever. But, you know, it can be tricky to, like, make those calls. Like, how far can you sort of push the current system before you really need to   invest in platform itself   and performance and that kind of thing. That's been interesting, you know, to to certainly sort of solve over time. Trying to think of some other challenging lessons.  

Yeah. Like, another lesson's been   less on the tech side, but more just on the customer support side.   So our customers   tend to be developers. You know, we're pretty heavily developer focused and developers   find butter, and and they're the ones who kinda kick the tires and poke around and do the free trial and all that good stuff. So just thinking about, like, how best to support them and ensure that   they can kinda go from point a to point b as as fast as possible. So a lot of that's, like, building great documentation and and supporting those docs. I think that's sort of like a golden rule that any kind of dev focused company should adhere by. I think Stripe's probably the 1 of the gold standards   that people probably most commonly think about when it comes to, like, amazing documentation.  

There's some challenges with documentation and, like, scaling out to supporting more technology stacks. This one's sort of maybe unique to butter, but   because our core business is an API,   we can technically work with, like, any technology stack out there and any and every as long as it can, you know, talk to an API, which is everything. And so, you know, how do we best support that? Well, investing a lot of time in, like, building SDKs,   starter projects,   example projects where, you know, even Java, you know, you build out, like, a Java project that's   kind of a minimal project, but it's, like, fully integrated with butter and and pulling content in some of the most common use cases and that kind of thing. That's been kind of a unique challenge. Certainly never faced that before,   building our SDKs, maintaining SDKs, and doing it across, you know, I think we're up to, like, 23 or 24   tech stacks, like, languages and frameworks at this point. So that's been a pretty interesting challenge as well.  



[00:40:06] Unknown:

And for people who   are looking at CMS systems and trying to decide what fits best with their particular use cases and environment, what are the cases where Butter is the wrong choice?  

[00:40:18] Unknown:

Very simply, certainly 1 obvious case where Butter is the wrong choice is if you are super proficient with WordPress.   So, you know, the way I've kind of spoken about WordPress, I don't sound too fond of it. I'm just generally not, but I also don't have any experience with it, which is also why I'm not too fond of it. So, you know, they kinda go hand in hand.   If you are familiar with WordPress, then it's an amazing ecosystem, and you could do all sorts of stuff with it.   So, you know, if you are starting with WordPress as your kind of core expertise and framework that you know and that you're most proficient with, then you should use warranty. Then you should probably use WordPress, you know. So that's certainly, like, 1 obvious use case. If you're just a really skilled WordPress, Drupal,   you know, there's there's other players beyond just WordPress, but, like, you know, if you have experience   and skills   with those frameworks and CMS systems, then, you know, use those for sure. Some other kind of indicators   when butter is the wrong choice.  

If you don't have, like, any existing site and maybe aren't super opinionated on the underlying technology,   like, you're fine with PHP and MySQL and that kind of thing, you know, then that could be a fine choice. And, like so there's lots of different companies.   You have to think about it sort of from, like, a company slash project perspective, you know, like, is this a small start up that's mainly kind of marketing driven, and they don't really even have an in house   developer perhaps, and you're just sort of trying to get any website up and running type of thing? You know? Like, if you don't have any in house tech expertise and you don't and you're not working with a developer,   butter's not gonna be a good choice for you. You know, you're you're probably better off with, like,   something that   can be stood up   with no developer   involvement at all. You know, whether that's a Squarespace or Wix site or something like that, or WordPress with, like, a off the shelf theme or something like that.  

So that that could be another indicator. Another 1 would be   if you're okay with, like, outsourcing all of your development to a WordPress agency   that you have a good relationship, you know, then we could definitely go that route. That'd be okay.   And I'd say, finally, like,   if it's gonna be   sort of a stand alone basic marketing site   and you don't have any other tech stack or applications   any CMS capability,   like, you could argue for that WordPress is probably or could be a better path to go down. It really kinda depends. Right? There's a lot of nuance to to this to determine if it's, like, the best fit for you or not. But those are some of the areas that come to mind. If I had to summarize again, it would be, like, if you're proficient with WordPress or if your team works with it and knows it well, stick with   it. Or if you don't have   any developers at all on your team, butter is not a good choice for you, you you do need to have some development expertise to kinda integrate and plug it into your site.  



[00:42:48] Unknown:

As you look to the near to medium term, what do you have planned for the future of the Butter CMS platform?  

[00:42:54] Unknown:

You mean beyond world domination?   No, I'm just kidding. No, honestly, it's just kind of part charting the same path that we've been doing. So   continue to improve the product   while refining it. So   this has been an interesting challenge too, you know, with, like, CMSs.   This ties back to some of the previous questions. Like,   when it comes to CMS, there is no limit to,   like, feature requests as far as what people have. There's millions of sites out there, and people have set them up in infinitely different ways. They want to do different things with them and manage them in different ways. So there's all sorts of feature requests that come that come into play. You know, that that's certainly obviously, a focus for us as a business to, like, improve the product, improve the capability of it, but it's really important to do that and challenging to do that while still, like, refining the product.   So it's pretty I won't say easy, but it's not super hard to, like, just keep building more features and more features and more features. What's not so easy is to, like, do that,   but also to, like, potentially strip away features   or to, like, refactor features   into a more organized way so that the product itself   stays simple and kind of refined and is easy to use.  

So, you know, like, just more capability, but easier to use. There's a lot of beauty and simplicity.   It's a really hard thing to do.   So that's a big focus for us, for sure.   But, yeah, just in general, you know, we wanna be, like, the no brainer choice.   We wanna be, like, the obvious choice to be the CMS for teams or companies   who are using modern technology stacks.   Modern being, I guess, kind of loosely defined. I mean, again, I'm a big Django fan, but it's even kind of old, I guess, by today's standards. But, like, anything not WordPress, honestly, you could be using dotnet, Java,   Django, Rails. You could be using all the new flashy Jamstack,   Next. Js,   Angular, React, all that kind of stuff. We did touch on mobile, but, you know, there's mobile frameworks such as, like, Ionic,   React Native,   where you can use those frameworks to build   theoretically 1 app in Ionic, for example, and then deploy that to Android, deploy that to iOS,   you know, you get dev efficiencies there. So if you wanna use that and you need seamless capability,   like, we want butter to be your go to choice   for adding seamless to that. Yeah. I should also mention,   we're, yeah, continuing to grow and currently looking for   a director of engineering   as well. So someone to take over all of the challenges that I mentioned before and really kinda own that. We're we're actively looking for for someone to do that as well. So pretty exciting time for  

[00:45:21] Unknown:

us. Are there any other aspects of headless CMSs and content management in general or what you're doing at Butter specifically that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:45:32] Unknown:

So if you go check out, like, our pricing, there's a lot of paid plans, but there is a free plan for personal use. For anyone who wants to kick the tires   and build out, like, a personal portfolio site,   tote Butter's totally free, you know, for that kind of usage. So if you wanna just kinda see what it's like to work with Hide the CMS   for free, I mean, launch your personal site on it or something like that, you can absolutely use Butter for that for sure.  

[00:45:55] Unknown:

Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks. And this week, I'm going to choose the TV show, The Arrow, that I've been watching recently.   Definitely a very interesting and pretty well put together show. Takes place in the DC Universe.   So, yeah, definitely worth to watch if you're looking for something to keep you entertained during the winter. So with that, I'll pass it to you, Jake. Do you have any picks this week?  

[00:46:23] Unknown:

My pick is I decided to kinda make a timely 1 given the light of the unfortunate US hack. That sounds   pretty darn serious, what I've read. There's a book called Ghost and the Wires.   It's written by a guy called Kevin Mitnick,   who   is pretty well known. Well, if you're in that if you're kind of in the security hacking space, he's, like, super well known, well renowned, and he tells his life story   about all the different   how he got into hacking and at a young age and that kind of thing, and the different kind of organizations,   government organizations that he was able to hack and how he did it. It's super insightful, super interesting book. Eventually, you know, he goes on the run and that kind of thing. But the thing I took away from it was   as someone who's not a hacker or really into hacking or anything like that, is that you would think that on the outside, a lot of hacks happen to do some super sophisticated technical means, And maybe they do, but this guy was 1 of the best, and he did it through social engineering.  

It seems like 99% of the time, which I found just to be fascinating. You know, basically, just like tricking people   at whatever government organization, whatever corporation   into just, like, giving him basically, giving him his passwords or or, you know, or running some command   in their system to give him an give him an opening to do it. So pretty interesting stuff. Again, just given the light of the of the recent hack in the US might be might be 1 to check out. Well, thank you very much for taking the time today to join me and share your experience  

[00:47:49] Unknown:

of working in the content management space and building a business around that. It's definitely a very   interesting and necessary problem domain. So thank you for all the time and effort you've put into that, and I hope you enjoy the rest of your day.  

[00:48:01] Unknown:

Oh, thanks so much. It was a pleasure. Thanks for having me on. This was a real honor, a lot  

[00:48:06] Unknown:

lot of fun, and you as well. Take care. Thank you for listening. Don't forget to check out our other show, the   podcast at dataengineeringpodcast.com   for the latest on modern data management.   And visit the site at pythonpodcastdot   com to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.