Simen Svale - sanity.io
devtools.fm
March 16, 2025
{/ TAB: SHOW NOTES /}
This week we're joined by Simen Svale, the co-founder and CTO of Sanity.io
Sanity is a content management system that's built for developers, and it's a great alternative to traditional CMSs like WordPress.
Sanity focuses on developer experience, and it's a great choice for building modern, scalable content-driven applications.
- https://sanity.io
- https://www.linkedin.com/in/simenss/?originalSubdomain=no
- https://x.com/svale
Become a paid subscriber our patreon, spotify, or apple podcasts for the ad-free episode.
- https://www.patreon.com/devtoolsfm
- https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe
- https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758
- https://www.youtube.com/@devtoolsfm/membership
{/ LINKS /}
{/ Paste show notes /}
{/ TAB: SECTIONS /}
[00:00:00] Introduction
[00:05:35] Understanding Sanity CMS
[00:09:21] Sanity as a Content Operating System
[00:17:53] Ad
[00:18:12] Portable Text and Real-Time Collaboration
[00:24:08] Grok Query Language and Its Advantages
[00:29:14] Introducing Sanity Create
[00:30:27] AI in Content Creation
[00:39:23] Sanity's Plugin API
[00:48:15] Future of Sanity and AI Integration
[00:53:02] Conclusion and Final Thoughts
{/ TAB: TRANSCRIPT /}
Simen: There should be no secret codes in the CMS. Because that's what I'm used to is like, oh yeah, we just double at sign.
That means like it's something magical happens when you mentioned something. With sanity, you can make sure that you can invent all of those things and there is a proper schema for it and it becomes a proper user interface for it.
[00:00:20] Introduction
Andrew: Hello. Welcome to DevTools. FM. This is a podcast about developer tools and the people who make them. I'm Andrew. And this is my cohost, Justin.
Justin: Hey
Justin: Uh, but before we dig into that, would you like to tell our audience a little bit more about yourself?
Simen: Yeah, sure. Thank you for having me. This is amazing. Uh, so I'm, um, I have been in, uh, so actually with my co founders, we've been working together since the late nineties. So I'm, I'm dating myself a little bit terribly forever. Uh, and we used to, we always used to have these kind of, uh, boutique agency, uh, business where we like, we were usually around like 10 people and we would do things that were kind of connecting design, art, and technology.
Some of this would be like marketing things. And some of them would be really, really weird stuff. Um, so we'd be kind of, I don't know if I'm a developer, I have a, in Norway, I have a life. Um, achievement award with my co founder for this as a designer. I I'm not a designer, but like, yeah, we do all kinds of things.
Uh, I think, uh, my, my, the only where I'm pretty confident with my technical skills, but I do a lot of different things. Um, I, uh. I used to, uh, it's like back in the day, we were, we weren't really working so much with content. We were working mostly, um, with kind of, it was a time where like user generated content was a big thing.
We made it very early social, uh, media kind of site for Norway, for the cultural sector in Norway, which were good. We kind of introduced Norway to the, to the, let's say post tech world, social media. Um, uh, before Facebook and Twitter kind of, uh, took that role. Um, And, uh, so we were like big into user generated content and kind of, uh, different ways of, uh, for companies and media to kind of engage users in interesting ways.
So when we were approached by a company called OMA, which is an architecture agency that, uh, is run by a very famous architect called Rem Koolhaas, which me and my co founder Evan, we are big, big fans of him. Like we, we have all his books and we've kind of reading them since we've not since our twenties.
And we're like, Isn't he dead? Or like, uh, like he knows about us. Like, it's like, he's so huge to us. So like, just the fact that, like, we were requested to do something for them was just so immensely huge. And he's supposedly this terrible, terrible person. That's what people told us. Like, he's like, yeah, The Steve Jobs kind of character, he is kind of draconian leader, so you're like, oh, he might be, be, be, be terrible to us.
That would be amazing. Uh, so , so we kind of took that, uh, uh, kind of, uh, or, or we, we had to kind of pitch for that job and we did that. Uh, and he did, he was pretty terrible to us. It was super interesting and we were like super excited. Uh, but that brought us back into something where content was important.
Because now, uh, they needed a, uh, like a web presence for this company. They've been making seminal architectural projects since the 80s. So for, in our minds, we were creating this, this super important library, this kind of archive of all of their work. So we'd like, you have to go find all of your like books and all their stuff in the highest possible quality.
And you have to go find all of that because we're going to make this kind of pristine. Archive with like a database of everything and that's going to power your website and they were like, oh, that's amazing We're going to do that. And then we started looking for a system and then that's when we became angry because we felt that At that point like we wanted to create something that was usable By non technical like by the pr department by the business development department by the people in the company who knew about the architecture It doesn't didn't necessarily care about the tech But he also wanted to be structured and proper and to be able to power like we were going to make books and websites From the same content.
So like we needed it to be very principled Um, and that's when we realized like even this new kind of breed of the so called headless systems were still very much like web Systems and in my opinion pretty tactical like there you still WordPress with like a an API on them kind of mentally so we were like I don't I want something that is born as a database.
That is kind of thought of as a, as a proper database system, but then still presents as a content system. It has all the, all of the APIs and the facilities that a database has. It has a data model that is as rich and maybe even richer because of JSON. Uh, like we used to do tables, now we can do hierarchies and JSON is better.
So like we wanted that. And then it turned out we had to build that. We created it initially as an internal tool. And then we used it for, uh, Diller Scofidio, a different architecture agency. We used it for MIT, and I think MIT was the inciting incident. They said, like, What is this system? It's like it's better than anything we can buy and that's when we can it kind of clicked Like we should probably not be just using this tool We should be the company that makes this tool and that's when we turn that into a startup and that's why i'm here
Justin: That's incredibly exciting.
Simen: Yeah,
so.
Justin: I think this like We've had a few other guests who've had this, like, uh, if you build something internally and then that turns into a product, um, how do you think, uh, that helped shape? Like what it ultimately become.
[00:05:35] Understanding Sanity CMS
Justin: Uh, so, and maybe it like helps to, to step back and kind of talk about like how users interact with sanity or how they were interacting with sanity at that time.
Um,
Simen: let's talk about like what it is. Maybe for yeah, exactly. Like what what is it? It's a It's a it's a It's a, uh, to, to, to your, to, to the content team, it's a CMS. It's a, it's a, it's a admin dashboard. It's where you create your content, where you configure your stuff, where you do the day to day operational things.
Um, in, and of course it can be, it's very often is websites, but it can be all kinds of things. It's used for everything from training dummy training programs for like first aid systems. And I realized today it's used for Norwegian tax law. Uh, managing Norwegian tax law. I didn't know that. Um, So it's used for a lot of different things.
But the point is like, uh, uh, the, the way most people meet it is as an admin tool to run some kind of content operation. And, uh, to a developer, it's a framework. It is a framework for building a CMS, of course, it's super easy that you can just the easiest thing you can do is just define a number of content models and you just run it and it's a CMS, but then it has all kinds of ways if you're a front end developers with react kind of capabilities, you can do everything with it like everything, then you can automate things you can create Custom workflows.
You can build all kinds of stuff that and that was kind of our like when when we were, uh, creating this, my kind of anger was partly like one thing is I want this database system. Also, I care about my users and in one sense, my users are my Is the content team, like my, my actual customer is all me. It isn't their customers that they're that's their customers.
I want to invest in them. Like I want to talk to the business development team, realize what they are spending their time on and have the ability to, to, to create something that really helps them. That's why I wanted it to be super customizable the way only code can be. But then still. The kind of principle is that we, anything that's generic, generic, like, uh, like curing things, real time collaboration, comments, tasks, like all those things, we just take that away.
You don't have to build any of that. But anything that you need to, like, we watched today, this demo of this tax law system. Lots of bespoke workflows, like a new law is changed, it's triggering this workflow for interpreting that law. Uh, for some kind of team that knows about like, I guess they are lawyers, probably.
That kind of stuff. Uh, so it's kind of both a system for line of business applications in a sense, like for, for these kind of internal tools, but like, but it also is a system that now scales to, I mean, it's used by skims like Tim Kardashian's clothes brands. This system like Santa is used. Directly during kind of black friday at skims.
That's not like that's like a that's like a denial of like an ongoing one week denial of service attack. Our API is handled that with no kind of middleware. So like sanity is the system that you can use to build. And it's very cheap, uh, on the free plan. You can easily build your, your, your boyfriend's dog walking app for no cost, but it scales to, uh, like planet wide kind of Burger King is using it to run all of the kind of, uh, menus worldwide is by skims to run the content operations for the, it's used by Unilever kind of corporate sites.
So it's like, And that was one of the things we wanted. We wanted this thing as a developer. I hate like having to learn all of these different systems. The point of sanity was, was supposed to be able to kind of scale to all of these different use cases. That was a lot of different stories in one. I'm sorry.
Andrew: it's fine. Uh, so I, I find it interesting that you think about sanity as a database. I think that kind of like a lot of. Like the realizations come out of that.
[00:09:21] Sanity as a Content Operating System
Andrew: And one of the things you call sanity and your blog posts and your docs is a content operating system. So like, what would you say are the parts that go into a good content operating system and what you've done at
Simen: Thank you. Exactly. No, that we struggled for the longest time, to be honest, to figure out like what to, because we didn't feel. That headless was like, uh, like I said, like it didn't really cover what we were going for. It was such an obvious thing. Like everything is headless, of course, like, uh, if you add an API and now you're headless, like that's not really the thing.
Um, The thing for us was, uh, and, and, and content operating systems kind of means two things to us. Uh, for, from, from the developer in me, content operating system means it's like a platform to build the kind of found, like the foundation to build all of these. Cause, uh, the CMS part of this is like just one thing, like with AI automation and integrations, like I'm building this whole kind of system of integrations of automations of triggers, like a new story comes in.
And it needs to be. Uh, like for example, Love Holidays is a travel agency. They, they have, they are resellers of hotels from like different vendors. They get like supplier information from, from, and then, then they automate the, the editorial process of kind of taking all these different hotels, bringing them together.
Uh, use AI to, to, to help with that, accelerate that, to, to translate them into different languages. All of that is kind of part of, in my, in our opinion, that's part of, that should be, that's part of your CMS in a sense, like that's part of your content operations. And we kind of want to move away from this kind of perspective of content management to more of a process oriented view.
Like I'm, I'm designing something that goes in time, that goes on forever. You need to think about it as a process, as a content operations thing. So. That's what this, uh, good content, uh, operating system is. It has a, it has a good database that's optimized for content. And it, this can mean some very simple, dumb things that kind of was super rare.
Maybe other systems have it now, but when we started out, like there was no other way to embed content, like structure data inside texts. Uh, and have that be curable and processable as a database record. Like, to us, that was like, that's the obvious thing, that's what content is. It should be just, paragraph is just an array of a certain kind of object, and then you can have other kinds of data in there, and then that should be processable as, uh, just as well as any other kind of data.
So that's like, having a backend like that. And then, Supporting all of your needs in terms of automations and integration with other systems. And then, uh, one thing we're introducing very soon is compute. It should have, like, we have, of course, webhooks. But, like, we're bringing that into the platform. So, like, you will be able to kind of just define your, your backend functions, your AI automations.
And that will just be part of your content projects. I mean, you deploy, you deploy both your, your schema, and also the, all of these automations and integrations. And then, of course, on top of that, You need that framework to build, to, to have full control of the operational kind of user interface. Like what are people doing day to day?
It has to be, of course, super easy to build out, but it also has to be customizable. So the, the kind of data, data layer, the distribution system, the automation and integration system, and then of course the user interface from something that's super easy to build out. But then, uh, all the way to, to, to, to full freedom when you need to.
And then, of course, uh, I'll add to that right now, when, as we are on this, uh, DevTools podcast, I think the interesting thing right now is that It was nice for a time to have this drag and drop that felt friendly for a while to have like visual tools, and we resisted that sound is very cold oriented like you have to define everything in code.
And when I got cursor, and I got warped, and I'm like, now I'm so happy that I can now because now my kind of AI workflows can now do everything for me. They can build out whole content pipelines and, and, and, and help me do that because they are, it's, it's, it's all in code. It's all understandable by AI.
It's all kind of, uh, able to be built out by, that's not, I guess, an important part of content operating systems right now, but it is tomorrow.
Justin: So building out the content pipeline for a media company like food network and HGTV, and they were using Adobe experience manager, uh, which. Was, uh, you know, it's a tool. Uh, and the, the thing is like the, the editorial team had a very bespoke, like workflow and the, the engineering team did a lot of work sort of bending a, um, to their will to try to.
You know, cater to this workflow because like you were saying, it's like, those are your customer. You like want them to be really happy, really productive. And that's like the mark of a good content management system. So I guess my question for you is like, the challenge was building like a content management service is that you have to kind of be everything for everyone.
Uh, and how do you do that? Successfully without it making it either so generic that it's not useful or like so narrow that again, it's only useful for some people.
Simen: Yeah, no, I, I guess we are like by, by being programmable, we are cheating a little bit because like, uh, it's very easy to add plugins and to customize things. And so like we are, of course, sanity at its, at its, at its heart is very simple. Like, uh, it is deceptively simple. Like if you, I think some people think it's just like some, some simple forms and some like very, very, very generic stuff like that.
The, the, the devil is in the details as you start like using that and realizing it's real time. Collaborative and there's all kinds of stuff like that and I think that to us that was kind of part of the part of the like the As like in my role as like initially founder and like the cto kind of thinking is to always be thinking about At a certain level this reusable General building blocks, like the way the database works, the way the APIs are shaped, the way we do the things to make sure when we think about a new API or think about a new abstraction to think about how they will be used for many different use cases and try and limit the kind of, uh, number of things you have to learn.
I, I guess some people will say at this point, like there maybe are too many things, but, uh, uh, there are a lot of things, uh, features insanity at this point, but yeah, I think that, but, but I, but I do agree. And also there is a tension there because with sanity, of course, that's a selling point. That's like what most of our customers tell us is like the customizability is the kind of, that is where the conversation starts and then they are happy about all those things too.
But like that's, and when we ask, like, What's the alternative for you to like what other products would kind of you compare it to would be like to build something ourselves. So that's kind of what drives people to use sanity is like sometimes I say it's a it's a it's a database with a weird word go to market or it is like a framework to build content operations applications.
That's but I do also think it's kind of a foot gun sometimes because I realize sometimes I talk to. Especially very mature companies that are about to replicate a terrible workflow because that's what they're used to. And, and like, because that's not always the right thing to do because like, that's, this is an opportunity to evolve.
And that's what, what we sometimes are, are struggling with, like with, with, with, with very mature customers who are then about to go down. And you know, like, I know for a fact that this is going to be terrible for you. I can see it already. I can tell you right now, but I realized that you're going to do this whole thing.
And then we're going to be a little bit sad. Like, I hope that you remember, remember, I told you so, and I'm, I'll be here to, to help you when you come back. Uh, but I think that is the, um, the challenge. And because I think, uh, it is also a good thing to sometimes be very opinionated. And I think that's where sometimes, uh, we have old, like in terms of.
That we are very opinionated as people, but we have been very much, um, uh, our language is always, oh yeah, you can do anything. Like, how do we do this? I can do it like in seven different ways. Uh, so what we realize is that our, our users actually want more guidance, want more opinions, want more clear guidance.
And of course they can do whatever they want, but we are trying to be more, uh, clear and prescriptive about like, what would be the sanity way of doing things. But like, you'll still probably find a fair, amount of places where I say, Oh yeah, you can do whatever you like. And yeah, for some people, that's amazing.
And for other people, that's just, that's just terrifying. Yeah.
Andrew: Cool.
[00:17:53] A
Andrew: We'd like to stop and thank our sponsor for this week, but we don't have one. So if you'd like to sponsor DevTools FM, head over to DevToolsFM slash sponsor to apply. And if you want to find another way to support the podcast, head over to shop. devtools. fm, where you can buy some merch and rep the podcast.
With that though, let's get back to the episode.
[00:18:12] Portable Text and Real-Time Collaboration
Andrew: So let's dive in a little bit to some of the tech you guys have built. Uh, starting off, uh, one thing that is a problem with CMSs is, uh, vendor lock in, and you mentioned it a little bit, but you've added some like primitives that help make your content a little bit more portable. So can you go into like what portable text is and how it plays the sanity workflow?
Simen: Yeah. No, you, you, you know, like, uh, uh, in my mind, when we started designing the backend, which has, which I, which I really was like a great time in my life when we kind of designed it initially. And I, I thought like we, I want a database that just feels like a bunch of JSON documents. I want to feel like I can have a JSON, kind of an ND JSON file on my, uh, in my, in my, um, in my folder and just stream it to sanity.
And now it's just for, for some magical reason becomes real, a real time database and that's pretty much what we have. So the, so the kind of, uh, the, the content backend at sanity is a JSON database. Uh, So that's very portable. Like that works everywhere. And then, um, and then, so, so that's just general, look, most shapes you can do with JSON, you can describe in a sanity schema and it becomes editable to, to, to your editors.
Uh, I think any, but I won't know, any is a big word, but like most reasonable data structures, you can define, define them in sanity and they will be maintainable. Uh, nested documents and arrays of objects and whatnots, um, and then there is one thing that like, like you said, like, there are certain formats that you just have to have.
And one thing that was important to, to us was that the text is data. So text has to be able to embed content. And that is at least two ways, like you have to have the ability to embed, of course, the Like if I have defined the content type, let's say it's a product. I want to be able to reuse that content type as part of a text.
I would be able to say like this is a sidebar that has a product and all that modeling should be the same schema that I use everywhere else. I should be able to reuse those types. Uh, so then that's the first thing there's always a way that's, that's simple. Like there's a, a text is an array of, um, of objects and some of them are of type span and others might be of type.
products. So that's block level things. And then, uh, so that's pretty obvious. Um, and then we, we also wanted to, so I, I really love like forward leaning, interesting web designs and very often what limits those aren't the ability to program them, but the ability to manage them. So I think I want very expressive content models.
So one of the things I wanted was to be able to have marks be data. So like one thing is of course links, but you want to be able to associate any kind of data structure that you design with a span. Let's say you want some kind of interesting visual thing where Lady Gaga's albums parallax scroll behind your text and always line up with the mention of the record.
Now you need some data to kind of power that. So, so, so, so, so we have a standard for Marking up text with marks with data and having blocks and that is a standard that kind of have had to be invented in, in, in our experience. So then we made it open source. So that's an open standard that's documented and, uh, and, and there, I don't think it's very widely adopted, but, um, but it's at least, at least it's well understood.
Uh, and then we have lots of tooling around it and we recently open sourced, I think that's clearly to me the best, uh, kind of editor like which editor kits on the planet right now is the portable text editor. That is then kind of a, um, um, a component, a component that you can use in your own applications that will then follow a portable text, uh, schema and allow you to edit those documents.
Andrew: Yeah, I, yeah, I use sanity for a side project I'm doing and the portable text is kind of what hit me with like, oh, wow, this, this really does open me up to like creativity. Cause like simple things like say you have some documentation and you want to make a sidebar table of contents for the headings.
Like if your stuff is represented in Markdown or some other format, it might be actually. Um, uh, I don't know if it's going to be a lot of work to get that data, but because everything is so structured, I have the freedom to do whatever I want.
Simen: Yeah, exactly. And I feel like, uh, like exactly that where you want to, as a, as a content editor, you want to be able to work with blocks and you want to just think about this as, uh, as content you're editing, but as, as developers, we want to be able to then understand what the intention was. Like, this is a, uh, not just like a YouTube video.
This is a video that's supposed to autoplay without sound and without interactions, because this is actually an illustration like, and, and with portable things, you can encode all of these intentions and make that clearer. So that as a developer. developer, there is no question. There is no like secret codes or backticks before the, your YouTube URL.
That was actually one of our first kind of, uh, post it notes during the design phase was like, uh, there, there, there, there should be possible to do all these kinds of creative things and there should be no secret codes in the CMS. Because that's what I'm used to is like, oh yeah, we just like, you just double, uh, double, double at sign.
That means like it's, uh, something magical happens when you, when you, when you mentioned something. Yeah. So that's over with, with, with sanity, you can kind of make sure that you can invent all of those things and there is a proper schema for it and it becomes a proper user interface for it. Yeah.
Justin: That's pretty cool. I didn't realize y'all had a standard for it. I would love to check that out. Um, there's a lot of, uh, I feel like the local first scene especially has been chewing through a lot of ways to represent, uh, text content in a way that can be, uh, sort of shared over CRDTs. Uh, so. be interesting to look at and see what the
Simen: Yeah. No, I mean, I mean, we, uh, sanity is real time collaborative. People are like, we have loads of people working in the same document. So, uh, portable text is working super well with this real time patch based workflows that we, we don't, we don't, we're not specifically using CRDTs, but something very similar to that.
Justin: That's awesome.
[00:24:08] Grok Query Language and Its Advantages
Justin: Uh, one of the things I wanted to ask about, sort of looking through the docs, um, so I noticed that you have your own query language called Uh, and I was, I was curious about, like, could you tell us a little bit more about Grok, and then why did you write Grok versus using Open Standards?
Maybe this predates, like, GraphQL or something,
Simen: No, no, doesn't.
doesn't. We were, like, it was very clear to us that, uh, GraphQL was a big, big, um, was going to be. It wasn't very big then, like, it was, uh, like, coming from, like, RESTful APIs, of course, like, uh, GraphQL is the answer to a lot of the nightmares of that. So, like, we were excited about, uh, GraphQL, but looking into it, I was, like, I, I, I don't agree that GraphQL is a query language.
It's actually like, it's a great API pattern. It's a fantastic API pattern. If you want to define a controlled API, uh, GraphQL is the way to go. Uh, it is, really is the way to go. If you are defining a query language for a content model where you want to be very open about what you use. Now, if you look at this generated GraphQL, like generated GraphQL APIs are the worst.
They are, uh, they, they are huge and they unfold every possible combination of every kind of filter that you might want to do. And like they're either that, or they are taking everything as parameters and then they aren't really GraphQL. Anyway, there's like a query language embedded in some parameters.
Like there is no, in my opinion, there's no real way, good way to do a query, uh, language in GraphQL. Okay. What it is fantastic for is a stable API. Uh, so, uh, so then what you need with a stable API is then you express it in terms of something else. So typically you express your graphical API in terms of the SQL, right?
That's what you transform it into some kind of query language. Maybe it's MongoDB or something, but you always, you always have a lower level query language that you have to transform it to. And that's the actual query language of the, of the content, uh, kind of store that you're using. So. Our thinking was, I, um, I don't think there exists any other query language that is for JSON.
JQ exists now. So there is one, but like, and grok is surprisingly similar. Like that's a parallel evolution. Um, and the thinking was, uh, I love SQL. It's very old fashioned, but it's fantastic. The technologies be powering SQL is amazing, but it's for tables. It is, it doesn't, like if you, if you use BigQuery, that's kind of how SQL looks when you, uh, when you are, when you have kind of JSON shaped data, and it's kind of terrible.
So the thinking was with Grok, we want to have a, a query language with the abstraction level of SQL. It kind of is a, it isn't, it isn't actually similar, it isn't fulfilling the same role as GraphQL, it's fulfilling the same role as SQL. And then our, uh, and then actually what's coming out, uh, I, I hope it would come out earlier, but it's coming out soon now is a way to.
Define a GraphQL API in this, in a, in a, in a manifest and map it to, to, to grok. So that in reality, your end users are using GraphQL because I love GraphQL. I just think it's great for when you design the API for one specific use case. That's when GraphQL shines. And that's why I still like I support it.
Like we, we do have GraphQL support. We have that kind of, in my opinion, terrible support. Uh, every other CMS has where you just kind of derive the API from the schema. But when you're coming out with this one, where the one that we actually recommend using, where you design intentionally what you want people to be able to query about, and then that's what you expose.
And then you map that to grok. And we would have to have some kind of query language. Um, and, uh, I guess the one we could, the ones we could have borrowed would be MongoDB, uh, or Elasticsearch or something. But we wanted joins and we want it to be a little bit sweet to write, and we want it to be a little bit fun.
And I think rock is, uh, like a, it is, uh, maybe it looks a little bit weird in the beginning because it's very typographic, but it, if you just spend like a second or two, it is. Very simple and very straightforward and very kind of general, like, uh, like it has a few building blocks and if you get those, it's pretty simple, but then it becomes very powerful.
It has, um, uh, for example, for our webhooks, you can use grok to define rules about how a document changes. So, like, you can describe, like, if this field changes in that way, then I want to trigger a webhook, stuff like that. So it's been a very useful thing. But yeah, we tried for the longest time to not invent a query language, and then it turned out we had to.
That's also an open standard. We have a open source implementation in JavaScript. There is a formal specification, and there is a test suite that's open source. So if people want to implement that, it is very easy. I actually implemented a Uh, new, uh, graph, uh, grok parser from scratch in the weekend, uh, because I wanted to see how fast a cursor could help me do that by giving, just giving it the specification.
And I made one in C plus plus, and I made one in Python and they both passed the test. So it's getting pretty easy to start, uh, kind of implementing grok in your products.
Justin: That's pretty, that's pretty awesome.
Andrew: Uh,
[00:29:14] Introducing Sanity Create
Andrew: since we're on it, uh, and you're talking about AI now, uh, it seems like in a lot of Sanity's communications lately, there's been a little bit of a focus on AI. And I think you guys are taking a unique approach to integrating like an AI helper into a content creation workflow. you can walk us through what that looks like.
Simen: Oh, now you have to be careful because now I'm going to be talking for hours, but
I try to Okay
No, yeah, you know, like, I, I, I used to be a writer earlier, like, uh, in, in my life. Um, and one of the things I hate with AI, I also hate that partly as a, as a developer. AI has this tendency of. Like I, I asked to cursor, like, uh, how would you implement this new data type I'm thinking of in our back end?
And he goes like, Oh, yeah, we do it like this. And then it starts kind of reaming out seven new files on a test suite for them. Like, um, yes. Like I wanted to do that with you, like now, and now I'm just reviewing this pull requests and that's terrible. Um, and the same thing is with writing, like, uh, uh, if you write in the kind of chat mode, you, you give a brief.
It will give you that whole text. Now I have to read it and I, and then I'll have to tell you how to change it. And uh, now I'm copy editor and I wanted to be a writer.
[00:30:27] AI in Content Creation
Simen: So, uh, we created a, uh, product called Sanity Create. And it's going to be, it now, it's a separate product. It will, it will be kind of, uh, as, uh, a sanity evolves, it will become part of the kind of standard package.
It will be closer to the studio. It's a way to. Right. first and foremost, AI needs context to help you. So the first thing is, this is a, this is a normal, it looks like notion or something like a general writing tool like that, but it has a sidebar where you can add your notes. And the thinking there is like, of course, for humans collaborating, it is very nice to have a separate space for the notes.
It's like, Typically when I, uh, work with in Google Docs or Notion and in collaborative writing projects, all of the notes are in the document. It's a very messy document. It's full of instructions and notes. And like in sanity create, there is a separate kind of section for all of the meta meta communication or all of those notes.
But the point of that is that the AI Also can read that so that when I am writing I can say okay, maybe continue from here I feel like from here, uh, like i'm writing a documentation article. I kind of written my my kind of gambit my interesting opening I think you can take it from here. You go like a command period and it starts writing, but it doesn't give you like Uh, both logo information.
It writes one sentence for you and if you like it, you tab and it keeps going and you tab and it keeps going and it tab and, ah, I don't like this so much. You just start writing it. You take the wheel and you go like, nah, I think it should be some more like this. And then you can go back and you can take turns.
And then it becomes more like an actual collaborative thing where. Where you actually are empowered and by the time your text is done There's no revisions because you brought it together Like you've read all the whole thing and you and you took your choices the whole way And when you took a different direction, I think very often ai is pretty like make very boring decisions But are really good at doing the obvious stuff.
So very often You you get to think I don't want to get to this point now I feel like we should like do a little kind of like a switcheroo and like start talking about something else You do write that and then the ai kind of And with the new Sonnet models from Entropiq, it's pretty good at writing too, actually.
So like, when it takes over, it's pretty good at that. So, so, so that's part of it. Then The kind of crux is that we realized that a lot of our customers have a, it's a separate kind of job to implement content. Like in many big companies, it's like someone takes a Google doc from like some content process and they copy pastes it into the right fields.
And there's documents, and I've collected those documents for a while, like where it says like, yeah, this is a case study, blah, blah, blah, for so and so customer. And like, these are the main use cases. And like, yeah, these are, so basically it's an instruction for filling out the form. Uh, and I, and I, and I realized like, uh, I, I'm like that myself, like it's, it's hard to be creative in a form.
So you actually like want to write in this kind of more free form shape. The thing with scientific creative, it is, it can be connected to your content studio and it knows your schema. So actually it can then, uh, by itself, follow those. Instructions. So we can actually like in real time, map your document to a structured content document.
And the really cool thing is like, if you use sanity with real like real sanity has a really good real time preview and mode with like visual editing and everything. And if you set this up, you can actually edit in your text. And that gets immediately reflected into your document and then into your preview.
So you have live preview and this goes way beyond like just like an article, like a blog article for that simple. But you can even describe like landing pages with like, oh, and I need a CTA hair. They should be blue and like, uh, and then I will, and it will implement that for you. So that's pretty cool. Uh, that's sanity create and it's, um, it's, it's free to use.
It's just like, um, uh, go there and start playing with it. And, um, Yeah, as it, uh, as time goes on, it'll be integrated more and more into the product, but it will still be free to use, uh, I, I think. It's the plan, at least.
Justin: That's awesome. It is like a lot of opportunity there to be as you integrate into the product, because it's already a part of all these like content editors workflows and like it spreads out and like a lot of people get to take advantage of it. That'd be, uh, that'd be pretty powerful.
Simen: Yeah, and what we realize is one thing is like the content team, like if you have a very, let's say you're working on merchandising in an e commerce company, like you want a studio, you want the forums and you like, you live there and you live and breathe those things. Very often, a company has like a second group of users who are like journalists, for example, in a media organization, or even like external collaborators who are like, let's say, like, uh, uh, uh, talked with one company who has, um, They do the LMNO health.
They do like, uh, information systems for hospitals, like, like critical information for nurses and the people who are creating the content are nurses. They are not content professionals and might not even care very much about like, Oh yeah, we have this new content model for guides and you should like add step here and might not care very much about like learning that.
With Santa Create, of course, they can, they can work in a much more intuitive way for a nurse. Um, and then that, then that system can automate. The the migration into a structured shape and then of course that can be then validated and quality assured by by a content professional But then can do lots more stories every day and the same thing we talked to a company doing they had like a Sponsored content like a branded content and of course those people then you collaborate with someone who really don't care about your cms They just want like one page to do the like to help like review the story and maybe add some some flavor to it That's also like a great use case for sanity create It's kind of like this DMZ at the perimeter of your ACMS.
Andrew: Yeah, I, I love how it is just like, so, so easy to use and that AI translation layer seems crazy. And I'm also a big fit. Like, there's kind of two dichotomies and AI tools. There's like the tab. Workflow where it's like a helper that's coming along with you and working with you as you go and like the one shot, do it all for you.
And I'm really not a fan of that second workflow because as you said, you become a reviewer. I don't want to be a reviewer of code. I want to be an author of code and the tab workflow just works so much better for that.
Simen: No, I think that, and then, and then the other part is this, I wonder why, like, um, I feel that is, like, we did it with a sidebar notes. I think there should be more ways to help add context to a conversation. Like, some, like, like, everyone has this kind of, you can add things, or you can mention things, but, like, Very often I need to, uh, add a new conversation, uh, like I'm creating a new conversation.
'cause this one has gone mad, mad that, I mean, that very often happens at some point the AI just goes mad. It's too much context and I have to start again. I would love to be able to have some kind of pattern where this is like my main line context. Like, this is what I'm working on. I'm creating a database system that is so and so, like, this is like the, for like, this is like the every day you wake up.
At least know this, uh, and I feel there's a, that's a, a, um, a pattern that I, uh, feel we haven't like different tools have different ways of solving that, but like, I'm looking for a way to have that thing. Yeah. Context just come along with me. Like this is my, this is a job I decided to do today. So every time I talk to an agent or something, it should know that that's kind of my mode today.
Yeah. Like a situational background prompt
Justin: Yeah, yeah, I'm excited to see this new generation of tools, especially it seems like you're doing it very thoughtfully. And that's, uh, I think what we because there's a lot of, there's a lot of folks just rushing ahead.
Simen: Yes. Yeah. Yeah. Yeah. No, I think, uh, we have the Privilege in a way, like I feel like as developers, we see the future. Our tools are from the future. They are like so far ahead of everything else. But I mean, like, uh, using like warp with, with cursor or, or windsurf, that's how content authoring should feel like in a couple of months, uh, that would everything should feel like, but we have, of course, like this little benefit of, um, Uh, most of, uh, our, just like the industry we are.
The targeting developers in our space are not maybe the most eager to, to deploy all of this immediately. And that's kind of fine. So we can take our, like a little bit more time getting everything right. But I do, I'm really excited about, it was a time in the, in the beginning, I was a little bit worried that like is structured content.
Not going to be very important anymore because these AI tools can just kind of take any kind of pile of garbage and figure out the structure of it. And then as time goes by, I realized like there is a, it's a very important world here where we, where we quality assure our content. So the, the, what AI helps us do is like bring in content that is unstructured into a structured, uh, uh, universe and there we can quality assure, we can make sure like this is a fact, this is a kind of brief, this is more kind of a, like a description of a thing, whereas this is the price you can't kind of, you can't like invent a new price, but you can invent a new description slightly for a new, new, new audience member.
Um, And that turns out that the structured context stuff is just more and more important. So, so, and, and, and with AI, we can just work with it more efficiently and in more complex and automate things better. Yeah.
Justin: Yeah, it's awesome. I
[00:39:23] Sanity's Plugin API
Justin: wanted to switch gears a little bit and talk about. plugins. Um, so for a lot of creative systems, uh, having a plugin API is like incredibly important. Uh, and, and y'all definitely have one. So like, I was just curious, like what the shape of plugins are, what it allows you or as a developer, uh, using sanity to do.
Um, and you know, any, any like difficulties or, or I don't know the story of like getting there to, to building the API. It seems like building a plugin API is like kind of a hard thing to do.
Simen: Yeah, it is kind of a hard thing to do. Yeah, no, no, the way we, the way we tried to design sanity was. You can almost call it like a microkernel application. We try to say like everything is a plugin. Like that, that, that was the kind of the, the, the design kind of principle. We try to create a, an application framework that like, uh, when you, when you rendered it just sanity, it's just a white canvas.
There's nothing there except the infrastructure. And even like the main toolbar, uh, that everyone is using is kind of provided. With the same API as the plugin API, because it's just all plugins all the way down. So that was the thinking, like if we, if we get that API, right. Then, then like, there is no, like the goal was like, there is no separate plugin API, right?
Like this, just the, the API of, of sanity. So the way that works is that there's a number of different resources, uh, like a tool, uh, structure, which is like a navigational structure. There's a schema, uh, there are like, uh, content types. There are different, different, different resources. And, and basically, uh, uh, and, and, and the whole, HoloLens is defined like that.
And then the plugin is just a, like providing a number of those resources. You just like, yeah, let's say you have, um, You have a custom input. Let's say like you, you design a map input. So this map input has a, has a data type that it needs. Uh, and it has a react component. Um, and it, so, so, and then basically you, you, the plugin of that is just defining that content type.
Uh, uh, providing that as a, to the schema system and then attaching that to that editing component that you made in react. And then whenever anyone kind of now says type Colon geopoint or whatever you call that type that will just call upon your entire kind of the stack you invented And let's say you want to have a central management tool to see all of the geopoints I don't know like i'm just inventing this as we talk now you you you you you you need like a canvas kind of full view This is called a tool So you just provide a tool, a tool is just a react component that you then provide any call it a tool, give it a name, and we will just a pair.
And when anyone clicks that, they will load your component. And that's just another resource that you provide in your plugin. And if you want those to appear together, you bundle them as one plugin. Uh, and it's just a list of those resources. We super simple, super dumb in a way. Uh, but that's one thing we hit kind of. In all humility, I feel we hit the head pretty, like, dead on and immediately by not having a, like, we're not thinking about this as a, a, a plugin API at all, just the API.
Andrew: Yeah, that makes a lot of sense. Like if you've, if you've leaned into a plugin API, by the time you're like, okay, user plugins, it's like, oh, well, we've defined every part that this thing could want to integrate into our system already.
Simen: Yes, exactly. It's like, uh, there's no concept of having a hook for plugins. There's, that's not a thing. Like if we, let's say we need a, um, a way to place a, um, a, um, a button in the main toolbar, like if, if we need to do that, there will be an API for that. Because, uh, I, I'm exaggerating a little bit. I'm not sure that's possible, frankly.
Because, because that's a single resource we're providing. So, like, that might not have a, that might not be possible. But, but the point is, like, uh, we are not adding hooks. We are just, we just decide how to carve up the, the resource, uh, system. And that's what we provide. And that's what anyone can provide.
And, um, and we do the same thing with our backend, frankly. Like, we don't have Private APIs. Uh, we, we, we, we, we probably have some, but like in, in general, all of the, like every API that's involved in like presence and real time collaboration, how mutations are on the wire, you might not care about that, but if this is all documented, like you, you can, you can do that yourself.
And, uh, and, and, um, we are working on, uh, on tooling and SDKs that makes it even easier, but these are all like, if you need to build Build some of this in Java or interact with that from somewhere else is all like all of the APIs are first class. It isn't documented things because we are, that's how we are thinking.
Like, um, we were thinking that if we need it, you need it. Uh, and we're building a platform and everything is kind of a built by, by, by, by parts that are loosely coupled. And most people will not care. Like they will want the big picture tools. And that's kind of. Fine, but the point for us is like like back in our agency days It's like we want to have every most things should be super easy.
Uh, reasonable things should be Easy and then everything should be possible Like there should be no because like every customer has this one request And it's a kind of super annoying to be able to to say like no That's actually not possible because this is a hosted system or yeah. And, and, and our, and our approach, our dream was to be able to have a system that is both like, we take care of everything.
Uh, like I don't, at least back in the day when I wasn't like, I don't, I didn't, I didn't love to have to kind of manage databases and run kind of servers. And like, I'm, I'm even back in the day, we had actual physical servers that were like, we had to SCSI controller was done. Like I hated all of that. So I wanted this product to have that go away.
Uh, while you still have all the control you would have in something like WordPress where you'd like, you'd have all the code, like you can do all the stuff that matters, you can do all of that, but all of the, like getting the content out to edge nodes and that, that just disappears. And that's, that was kind of the design goal. get kind of,
Andrew: go
Simen: people talk about local first, I'd be like, yeah, that's, that's a bait and switch thing. You don't want that.
Andrew: Yeah. The, the main takeaway I have from sanity is just the flexibility. Uh, it sounds like it's at so many different levels from backend to front end. Like even with plugins, it's so nice that like you guys. Handle the content management part and then just hand it off to me, uh, in the end do the rendering.
So like I wanted to add code examples to my documentation. That was super easy. I just popped in a plugin. I could edit it there. And then when it's on my side, I had full control on how text highlighting worked and how it was displayed within my content. So that flexibility is, is so cool.
Simen: That's super nice. Yeah. And that, now that's where we started, right? Like that's where we came from the first, like when we, I think, I don't know the stories in the companies, like with various hair, but like to, to me that was like where we came from, this kind of freedom of this, like this design. It was about the sign to me like, I want to be able to, like all the time I had these ideas that I, that, that I, that I want to do.
And then I can't give, I can't hand the control to a customer or to the right people, so I can't do them. Like I have to do something that is more automatic or something like that. And I had a had a great conversation. It's tomorrow actually tomorrow. It's not not now You have to cut that out because it's not tomorrow now Uh, what is tomorrow at the time of recording we are but there is there will be on our youtube channel You can find in a webinar with the people who created the website for lady gaga And that was super fun to me because that was like, that's a beautiful, like animated, colorful, playful website.
I feel like too, too few of those currently, like this is like super, it's like a small things like they have, I don't know how they did it. They have like these kind of bump maps, I think for all of the products. So like when you change the color scheme to match a certain record, all of the products are lit.
With that kind of color scheme. I don't know how they did it, but it's an unreasonable attention to detail, but that is kind of, yeah, that was, that's what I was initially excited about that kind of opportunity to do this is amazing things and create amazing experiences. And then. Like, like I mentioned, like one of our first customers was Burger King and they were about this operational thing.
They were about like powering their, like having a content team be able to define a, a menu and then have that kind of trickle out to like delivery apps and ordering kiosks and even like, uh, behind the counter kind of screens for, for burger kind of cooks. And we were like, oh yeah, yeah, that makes sense.
That makes a lot of sense. We didn't think of that at least I didn't think of that and now of course that's like I guess our business is like half and half these two kind of content operations or Remarkable experiences like how I think about it. Uh, and and hopefully sometimes it's both
Justin: Yeah, that's, that's super awesome. And, and just like a really impressive business. I mean, that you can cater to all of these is incredible. Um, so as we wrap up our episode, we always like to ask a future facing question, um, and sorry, am I cutting out?
Andrew: Yeah, we
Simen: Yeah, we are pretending because I know being
Justin: Okay.
Simen: just
Justin: Uh, uh,
Simen: don't a planning to
Justin: no, all good. Oh, good. I'll restart. Um, so as we, yeah,
[00:48:15] Future of Sanity and AI Integration
Justin: as we start to wrap up the episode, we always like to ask a future facing question and, you know, I think for you, like, obviously, what do you think is next for sanity? And like, I don't know, in this new world where we have AI capabilities, sort of, as you're talking about with new features coming out in sanity, how do you think this is going to change how we Uh, create content, uh, and edit content.
Simen: Yeah, no, I think, uh, I think that what I'm most excited about right now is this kind of, uh, a content operating system, uh, direction, uh, of the company where it's. It's really all about developers. Like, uh, like we had periods where we're like, are we thinking, are we too technical? Should we talk more like high level strategic?
You realize like we are, uh, we are developers and we are for developers. And like the whole strategy is about making sure we double down on that. And it's all about, to me, like. What I wanted was to be able to have like Like we talked about like I have I have back end functions. I have ai integrated I have the ability to define my my studio and of course all is integrated with the front end frameworks that I like Like that is that is like where we are working really hard at something now to just make sure that is completely rolled out And to me personally i'm super excited about back end like about content compute about automation and kind of just being able to run my my code inside the kind of database um and then And then as you said, like, uh, AI is, uh, the, the kind of the, the stuff that's going on with, with kind of especially language models, of course, to, to us is incredibly interesting.
Um, and I think, like, our position on that is that sanity is about, it is very much about efficiency. A lot of people who use sanity are about like. Building workflows and optimizing how their teams work and kind of creating this suite kind of workflows that are kind of oriented around how the company thinks and that doesn't change the AI tools just makes that richer, deeper, you can go further into like what you can automate.
And to me it's always about like we talked about like you you talked about like the tab versus wall of text kind of Workflows in ai and we are very much about that tab workflow and it doesn't always mean that it does small things I think like the the things we are seeing in the lab right now is like being able to do huge Comprehensions on all of our content and like these are like not tab like workflows You can like really really comprehend all of the stuff stuff that you just couldn't reasonably do.
Uh a moment ago Um And then it is about that tab moment that moment where like you as a human go in and like Uh, these are now I have all the information. This is how I decide to act This is how I or this is that sentence that is really important to me This is how I want to decide to shape that and I think that is That is kind of the kind of user experience that we are designing for now.
That's kind of zoomed out using the the power lifter mode of like ai to kind of do these huge operations and then be able to zoom in And be extremely human on what you think matters and I think one thing like developing In a kind of AI, uh, assisted coding environment, what you learn is you, I thought a lot of the coding I did was coding and I realized it's just chores.
Like a lot of the stuff you do as a developer is just obvious. Like I'm gonna, gonna sort this array and put it into buckets in a, in a, in a hash map. And then I'm gonna, gonna sort those and create some, some, some, some drop down with that. That's all just choice. That should just be that sentence. And that's what AI does for me, like where I know, I have a sense for when AI can take over, and I have a sense for when I need to really lean in.
And I think that is a completely new experience to realizing how, how many of the, like, the decisions we make aren't really decisions, we're just Unpacking an obvious thing and that's where the what I think is interesting for for content operations or for all kinds of work In the future and the interface that we use to that Is to optimize for getting to those moments where we where we really do the decisions that really matters and that we really care about And to have these to make sure that these the other decisions that we automate away um, and I think that's that's a lot of the stuff we're working on now like the developer experience and of course Uh, to, to me, at least I think it's so, so fantastic to, to be able to collaborate with, with, with AI when, when building these things.
So making sanity, even like we're working hard to make sanity just better and better as part of a kind of AI assisted workflow, uh, getting it into all of the tools and getting agent kind of like, and we're working really hard with the. Um a mobile context protocol if I can have support for those things to kind of integrate with agents and stuff like that So that's a huge thing for us.
So that was a lot of things I don't know if you want to edit this down, but that's that was my brain dump. I'm, sorry. Yeah
Justin: that's great. Fantastic.
[00:53:02] Conclusion and Final Thoughts
Andrew: Well, that wraps it up for our questions this week, Simon. Thanks for coming on. This was a very fun time going through all the different ways that you enable developers to make good content experiences. So thanks for coming on.
Simen: Thank you for having me it's an amazing conversation
Justin: Yeah. Thanks, Simon. I feel like building a CMS was, is the classic like developer trap and y'all, y'all did it, you won the
game
Simen: mistakes time time
So
or cms. Yeah
Justin: you're, one of the rare, rare few to not only do it, but to do it well and make it into a very successful business. So congratulations
Simen: another kind words wrapped in an insult. Thank you. I love it. Thank you. No, this is amazing.
Discussion in the ATmosphere