Working with Schema Import/Exports and Recipes
July 14th, 2025
You know how we always flex about us not having ALLLLL the features under the sun but "just enough"? Well this is why. Because CLEARLY we don't want to build some complex, bloated, unused, buzzword-ridden pile of features that you don't care about (I mean, we got plugins for that innit?). And even more clearly, you wouldn't want to use that.
How do we know? We spoke to you đââïž
Similar to the extensive research we did in '23, I sat down with many of you again this year to unpack how you're using DatoCMS, what you like, what you don't, what you're missing, and what we can work on to improve things for you.
So while we unpack all that research into our own internal planning, check out what we've been discussing to get an idea of how your peers are using the CMS and what could be cool to explore together.
Buckle up - this one's gonna be a long read.
Headless is boring (that's good!)
Every single person we interviewed has moved to headless (in retrospect, I mean, this one was fairly obvious đ ).
No oneâs looking back. The decision to decouple content from presentation is now muscle memory. Monoliths just arenât in the conversation anymore unless thereâs a very specific legacy use case.
But why is it "boring"? What used to be a bold architectural move is now just⊠expected. Headless isn't hype, it's not "cool", it's not revolutionary, it's the norm.
Once we moved to headless, we never looked back. The boundaries are clearer, the flexibilityâs better, it just makes sense now.
API-first? Of course. Structured content? Naturally. Integration-friendly? Bare minimum.
So if everyoneâs already headless, what are people actually evaluating? Turns out: DX, UX, and how well the CMS fits into their real workflows.
CMS isn't the first decision
Multiple teams told us theyâre delaying the CMS decision until a project is more defined. Early stages are often built without one at all, just some mock data, maybe a Notion doc, or even AI-generated content. Once itâs clear a project needs a proper content hub, then a CMS enters the picture for a real evaluation.
This shift is important. It means people donât default to a CMS anymore. They wait to see if itâs worth bringing one in.
We often skip the CMS entirely in early phases: mock data or docs does the job until the projectâs real enough to justify one.
And when they do, the barâs higher than it used to be. Just having an API or supporting tomorrow's cool JS framework isn't enough. If it doesnât fit into your setup cleanly, or forces too much custom logic to make it behave, itâs out. The market's seen enough CMS saturation and maturity for clear choices to be made with informed decisions, rather than just choosing any Headless CMS for any project.
DX still wins (and loses) deals
Developer experience isnât just a nice-to-have anymore, itâs often the deciding factor.
When teams are choosing a CMS, theyâre not just asking âwhat can this thing here do,â theyâre asking âhow much of a pain in the a** is it going to be to maintain?â And that includes everything from how fast the APIs respond, to how easily it fits into their stack, to whether they can debug an issue without digging through obfuscated UIs.
Performance matters. Not just site speed and API speeds, but interface speed.
If the media library takes forever to load, the clientâs already annoyed, and now you look bad. So do I.
A good DX means devs can move quickly, trust the platform, and hand it off to non-technical teammates without dreading the support questions thatâll follow. A bad DX? Thatâs how migrations start.
I can love working in the CMS, but if it makes life harder for the next person in line, then itâs not working.
Editors just want things to work
And hereâs the flip side. Editors donât care about GraphQL or schema migrations, most of the time they barely know what's under the hood (why should they). They care that the preview works. That the text editor doesnât screw things up in formatting. That they can upload a 300000000GB (please don't) video and expect it to come on the frontend optimized without asking the dev team whatâs wrong.
A bunch of teams mentioned building small tools on top of the CMS to patch things, whether itâs nicer image previewing, easier entry duplication, or filtering that works.
Good UX beats clever features every time. Our clients donât care whatâs under the hood as long as itâs smooth.
We take that as a compliment, weirdly, because we want you to build plugins that seamlessly enable your workflows rather than focusing on 50 shades of features and then making you tweak your flows to fit ours. But it also shows thereâs room to streamline some of these flows if enough of you think it's a core requirement.
No/Low-Code isn't evil, but it's also not a âšmagicâš fix
We brought it up with some people. Others brought it up themselves. Either way, nearly everyone had some opinions on no-code and visual builder tools.
The pattern was consistent: healthy skepticism from devs, initial excitement from clients, and then⊠reality.
One dev said straight up that the code output from the visual builder they use is âgarbage.â Another mentioned they still use ****** but only by injecting âa ton of custom codeâ to make it work the way they want.
Itâs not that no-code is useless. Itâs just that the moment a project grows beyond basic layouts and static content, people start hitting their head on walls.
Clients love it at first. Then they realise itâs not a magic tool.
For high-stakes or high-quality builds, teams always come back to developer-led workflows. No-code has its place: MVPs, small sites, client previews, but itâs not replacing structured content models and frontend frameworks anytime soon.
Not because of dogma. Just because it breaks down under pressure.
AI is creeping everywhere
Bet you were surprised it took this long to get to AI huh? This year, AI came up even when we didnât ask about it.
Devs are using it for code completion, repetitive query building, or generating test content. Editors are starting to expect it for things like alt text generation, summarizing articles, SEO boosts, and translations.
It's creeping into almost every workflow.
But the most interesting bit was this: nobody wants AI to replace real people. They just want it to get rid of the boring bits.
Weâve started building our own AI tools because the built-in stuff in many CMS is either too generic or too limited.
Thereâs also a clear pattern of people building their own AI workflows rather than using whatever generic tool is baked into the CMS. The request isnât âadd AI to Datoâ, itâs âmake it easy to hook in the AI we already use.â
Which is music to our ears, because we've avoided just "sprinkling" AI into the CMS to fulfil a hype for SEO. We're definitely thinking about how and when to include more AI, but aside from our gorgeous and business-critical emoji picker, we don't want to just slap on a generative content field and call it a day, so stay tuned for where this conversation will go.
In the meanwhile, we already got SOME plugins that scratch that AI itch:
There's a few more if you look around the marketplace.
Oh and speaking of plugins...
Plugins aren't just "nice to have"
Several of you told us that DatoCMS plugins were the reason they didnât migrate away. Not because they use all of them. But because they could build or install exactly what they needed without waiting on us to ship it.
That's the benefit of hosting your own super specific plugins - the public/community ones are just the tip of the iceberg when it comes to maxxing out Dato's capabilities. Some of you have really WILD private plugins making the CMS do all sorts of things đ€Ż
Modularity is a double-edged sword though. Some folks are worried about relying too much on community third-party plugins that might disappear or break. A few of you called this âlong-term liability.â
So your vibe here seems to be to give you the flexibility, but donât make us depend on it. Valid.
Enterprise features are also important to non-enterprise
Even dev-heavy teams are starting to care about âenterpriseâ stuff: audit logs, role management, permissions, data residency (shoutout to Switzerland for popping up multiple times), and predictable pricing.
No oneâs "excited" when talking about these things, but everyone wants them, especially agencies managing multiple client projects at scale.
More than one person said they lost time or trust because another platform changed its pricing model overnight or killed off a feature without warning.
What used to be ânice to have for bigger companiesâ is now just... expected as well.
So we're definitely looking into how we can make some of these topics slightly more "normalized" for all the users.
CMS expectations have changed
The biggest shift from the '23 chat to now is that people no longer see the CMS as the âmain thing.â
Itâs just one part of the stack. Sometimes late to the party. Always expected to integrate cleanly and never be the bottleneck.
You can call that boring if you want, but as we said way up, we think itâs a sign of maturity.
In the end, your CMS shouldn't be the tool you talk about every week (really fun topic at parties eh?). It should be the one that gets out of the way and lets you focus on everything else.
So what's next?
This research isnât just for a blog post. Itâs what we use to figure out what to build, and more importantly, what not to.
Weâre already thinking/talking about:
Better schema-as-code workflows
Smarter ways to support AI integration (your AI, not ours, for the moment)
More predictable pricing structures to avoid surprises
Improvements to media handling
And generally making the platform feel snappier and more flexible across the board
Weâll share more as we build. For now, if something here resonated, or if youâre rolling your eyes because your pain point didnât make the list, send me a ping.
âïž Seriously. This stuff only works if itâs a two-way conversation, and I'm always down to talk!