## The DatoCMS Blog # "It's just CRUD", and other famous last words when thinking 'I can just build a CMS with vibes' Posted on April 27th, 2026 by Ronak Ganatra So. [You read the last post](https://www.datocms.com/blog/who-needs-a-headless-cms-when-you-can-just-vibe-code-everything.md)? You nodded along? And then you got to the end and thought "ok but I could just build a CMS, it's literally just CRUD, how hard can it be"? Valid. Very valid. Lots of people do that. (Image content) This is basically a genre at this point. Every other Tuesday someone posts that they've replaced their CMS with a weekend project, or want to build one in X framework and markdown files and good vibes. There is barely ever a follow-up post later. (Image content) What's changed recently though, is that they're now not wrong about the easy part being easy per se. Like actually right. For example, [Leerob migrated cursor.com off a CMS over a weekend with $260 in tokens and 344 agent runs and wrote about it](https://leerob.com/agents) honestly and I'm not going to pretend that's not impressive because it genuinely is. In this case, the dev, the team, the use case, the stack, the stars, and the chakras, and then some, all seemed to have aligned. The "I just built a CMS" is now a whole thing. But for the rest of us, it isn't as straightforward. So if you're not him, the rest of this is for you. **Technically. Vibe building a CMS** ***IS*** **just CRUD. For like, a weekend.** No really. Need a simple blog? Have a `title`, `body`, `slug`, a `publish` button, a basic admin panel put together... That's what? An afternoon with a good prompt tops. The core of what a CMS does is not complicated - you have content, you need a place to add it, and a way to publish it to a site that has a way to ask for it. And honestly? If your use case stops here and your whole team are developers, with nobody non-technical ever touching the content on a site has a few page types and a blog that updates every now and then, then go for it. Build the thing. Keep it in the repo. Markdown your content. Vibe away. No gaslighting you into thinking you need a SaaS subscription for that use case. BUT. Yeah, there's always a but. Let's dive into that but. The mistake isn't building a "CMS". The mistake is not knowing where "CMS" actually ends. ### **What you're actually still missing** So the CRUD work is done and it works. You show it to someone and they say "this is great, can I schedule posts?" Huh. Oh right. That's Cron jobs, right? [Scheduled publishing](https://www.datocms.com/docs/general-concepts/scheduled-publishing-unpublishing.md). Sounds like a cron job. Kind of is. Claude, do your thing. Oh but wait. There's also stages for what needs to be scheduled? That content needs to be a draft until the Cron publishes it, and what happens when the scheduled post fails silently at 2am, and whether that triggers a rebuild, and what the editor sees when they check in the morning and the post isn't live yet and they ping you on Slack. Huh. I guess its time to build Build Triggers. That sounds like an easy [webhooks](https://www.datocms.com/docs/general-concepts/webhooks.md) project. Simple prompt. Then Marta from [marketing wants a preview](https://www.datocms.com/features/editor-experience.md) before publishing or scheduling. We're not even talking about "[Visual Editing](https://www.datocms.com/features/visual-editing.md)" as a requirement. Not a "open localhost:4321" preview. A "WTH is an IDE and why should I need one to see what I've written? Why do I need to install node and learn all about npm scripts for that?" preview. A "I need to send this URL to bossman who is on their phone and does not have a GitHub account and definitely does not know what a branch is" preview. Draft mode, shareable URLs, no login. Ok, this is starting to get a liiiiitle annoying. Then comes another "can you restore the homepage from last Tuesday" request. Uhhh. [Revision history](https://www.datocms.com/docs/general-concepts/versioning.md). Rollback. Who made the change and when. Sh\*t. Then a blog post needs to reference an author. The author has a bio page. Someone updates the author's name. It should update everywhere automatically. Now you're building a relational content layer. When did you sign up for this? You see where this is going. The issue with "I'll vibe a CMS" mostly boils down to misunderstanding the tooling and maintenance needed, which nobody seems to be putting into the estimate. This is where the "it's basically free" math meets the "I'm great at prompting" approach, and things quietly start to fall apart. ### But wait, there's more**™** Now, another myth in the CMS building world is that content is *just* simple text and structure so the database approach is just fine, because everything online is a table or a form anyways, and needs to find a way to live in a database. The reality is that a CMS treats the C as more than that. It is a database yes, but it's reallllly opinionated on *what* constitutes as "content". Assets, localizations, and other abstractions of "data" are what a CMS is really optimized for. So let's address those inclusions for the vibe build. [**Media**](https://www.datocms.com/features/images-api.md)**.** Uploads, CDN delivery, image resizing, focal points so the crop doesn't cut someone's head off, alt text, video encoding. You can vibe code a basic asset uploader in a few prompts (Leerob did exactly this and it works fine for a team where everyone's a developer). It's also not the same thing as a media pipeline that survives a team of editors uploading a 47MB PNG and wondering why the site is slow. DAMs are hella specialized in managing all that overhead and headache, so unless you also want to build a DAM, a CMS solution is definitely needed. [**i18n**](https://www.datocms.com/features/headless-cms-multi-language.md)**.** Not just a locale field where you can maintain a JSON of translated strings, but translation states: which fields are translated, which aren't, which are in review, which need updates, which localizations are outdated compared to the main locale, locale fallbacks so you don't serve a blank page when the German version isn't done yet, a way to have different editors manage German content for Germany v. for Austria, locale-specific publishing... the list goes on. Oh, and of course, the moment where your AI-at-build-time translation tool doesn't play nicely with your content model and you need to either build a plugin or hire someone. Localization is such a monster, even with choosing a CMS it isn't always a one-size-fits-all, much less so when building a CMS for a smaller use case. **Webhooks and build triggers.** We already touched upon this, but workflows aren't *just* create and publish. There's cache invalidation, triggering deploys on publish, triggering unpublishes, managing different frontends with different build parameters, what happens when an incorrect record breaks the build at midnight and nobody's watching the logs because field validations weren't considered in the beginning? [**SEO fields**](https://www.datocms.com/user-guides/content-modeling/intro-to-the-seo-fields.md)**.** Meta titles, descriptions, OG images, per-locale overrides, canonical URLs, structured data. You'll add these when someone asks why the page isn't showing up right on Google, and non-technical people don't want to address another batch of JSON strings when creating content, nor do you want to reconfigure your UI to add more fields and manage things retroactively because SEO overrides and fallbacks weren't part of the original scope. My point is, none of these are impossible to build individually. All of them together is a CMS. Which is the "complex" thing you were trying not to build, but are in fact, "basic expectations" when choosing a CMS. But these are just features, there's a whole other mammoth under the surface. [**Security and governance**](https://www.datocms.com/features/data-integrity.md)**.** Two editors is genuinely all it takes before you have a permissions and access problem. Who can publish? Who can only draft? Who can translate what? Who changed something accidentally? Where is the data stored? Can things be backed up? Are there environments? Who broke the schema? Who mislabeled a field in the repo? What happens when the new intern deletes the homepage? How do we handle GDPR content deletion requests? Can I slap on SSO because the IT department said so without rebuilding Auth0 or Clerk? And this is just the tip of the iceberg. I could ask hundreds of hypotheticals around this topic. Your vibed-up database has no opinion about who should be allowed to nuke your pricing page on a Friday afternoon. You'll need to build that opinion in. Then document it. Then explain it to the next person who inherits the codebase after you leave, which I know you're not planning to do because I barely ever document my grocery shopping list properly. Going back to the earlier reference of Leerob's (no shade, I legit think what he did is mad impressive), this is the exact reason why even our friends at [Sanity shared their take on why not to build a CMS](https://www.sanity.io/blog/you-should-never-build-a-cms) and this bit here summarizes all my thoughts too: (Image content) ### Oh. And about that "free" thing The math everyone does when approaching to vibe a CMS is monthly CMS subscription cost vs. zero (and by zero I mean LLM subscription excluded because we have one for 50 other things). The math everyone skips is the hours to build scheduled publishing, the afternoon the media pipeline broke, the contractor brought in because the i18n plugin wasn't good enough, the week the new hire spent understanding a system nobody documented because the person who built it thought it was obvious, the two days of chaos when that person left, and the time and effort needed to build ad-hoc feature inclusions like a DAM or Auth or SSO or whatever else. Vibe coding brought the build cost way down. Like super down. But it didn't change the maintenance cost. It didn't change the ownership cost. And it sure as hell didn't change the "we need this new thing and you built this so it's your problem figure it out" cost, which is the most annoying one. The monthly subscription you were avoiding wasn't *just* paying for a database and a shiny little UI. It was paying for ten years of other people hitting these exact walls so you don't have to. ### **So when does vibing a CMS actually make sense?** I said it at the top but I'll be more specific: [Leerob's situation was real and the call totally made sense](https://leerob.com/agents). All developers. One website. Mostly prose. Stable scope. Dev tooling where even non-devs are hella technical. A CDN bill that had gotten expensive for specific and fixable reasons (read: hosting video through the CMS CDN might not have been ideal for a site with Cursor's traffic). > We’re saving thousands of dollars in CDN usage by moving to lower cost object storage. As a side effect, build times are 2x faster by cutting out network I/O going to the CMS when prerendering pages. If your whole team lives in the terminal, nobody non-technical will ever touch the content, and your scope is small and stable and unlikely to grow, yeah, go ahead. Build it. Keep it simple. Even if you build a UI for non-technical users and you really think the overhead is manageable because its' not a massive team, it could still make sense. The question is whether that's actually your situation or just your situation right now. The moment someone who doesn't know what a pull request is needs to update something independently? You're not building a CMS anymore, you're running one, which is a very different scope.