Should we build our own CMS or use a headless CMS?

The first version of an internal content management system (CMS) rarely looks like a CMS.

It looks like a database table and a page in your admin dashboard. Add a form, protect the route, expose an API, and the job appears mostly done. If you already have engineers working on a SaaS product, building it yourself can seem faster than evaluating another platform.

That impression usually lasts until people begin using it.

Marketing wants to save drafts. Someone uploads a huge image from their phone. An editor deletes a page and asks you to restore it. A contractor needs access to the blog but should never see pricing. Product asks who changed the homepage on Friday afternoon. Engineering renames a field and discovers that 600 existing entries still use the old structure.

None of these requests is unreasonable. Together, they turn a small admin feature into a product of its own.

We encountered the same gap while building Dyrected. Teams were not struggling to create the first form. They were struggling with everything that came after it. That experience shaped our view of the build versus buy decision.

Some teams should build their own CMS. Most teams should not decide to do it based on how quickly they can produce the first screen.

A basic admin page is not a CMS

A basic admin page lets someone change a record. A CMS makes that safe enough for people who do not know how the database works and should not need to learn.

That includes the obvious pieces: content fields, authentication, an editor, media uploads, and an API. It also includes the less visible work that makes the system dependable:

• Clear validation when an entry is incomplete
• Draft and published states
• Protection against accidental deletion
• Roles with different levels of access
• Search and filtering once there are hundreds of entries
• Relationships between content types
• Migrations when the content model changes
• Useful errors when an upload or request fails

A developer can build a simple admin dashboard in a few days or weeks. If the requirements stay small, that may be enough.

A dashboard with polished editing, media management, granular permissions, publishing controls, audit history, and reliable handling of old content is a different estimate. Expect months rather than days, especially when the work competes with your main product roadmap.

The first release is only part of the cost. Every new content requirement becomes your responsibility after that.

Content models always grow up

Imagine that you are moving a hardcoded company blog into a database. The first content model is easy. It has a title, slug, body, image, and publication date.

Then the blog becomes useful.

Posts need authors and categories. Marketing wants related articles. SEO fields appear. Some pages need a video instead of an image. The body becomes a collection of approved page sections. Someone wants to schedule publication. Another person needs preview links for drafts.

The database can store all of this. Storage is rarely the hard part. Your team also has to update the editor, validation rules, API responses, TypeScript types, migrations, and frontend queries without damaging existing entries.

This is why we prefer content schemas in code. A schema change is an engineering change. It affects more than the editor, so it should be committed, reviewed, and tracked like the rest of the application.

Non-technical teammates should own the words, images, and entries inside that model. They should not have to understand whether changing a field will break an API response.

A good headless CMS preserves that division of responsibility.

Permissions become security work

Most internal tools begin with an administrator role and perhaps an editor role. It feels sufficient because the initial team is small and everyone trusts each other.

The requirements get more specific once the tool spreads through the company.

A writer can create and edit posts but cannot publish. A growth marketer can update landing pages but not legal copy. An operations teammate can manage FAQs. An external agency should only see the campaign it was hired to work on.

Now access depends on the user, action, collection, and sometimes the individual record.

You need to enforce those rules in the API as well as the interface. Hiding a button is not access control. Every new endpoint, bulk action, import tool, and media operation has to respect the same policy.

This is one of the easiest areas to underestimate because a permission bug may stay invisible until someone sees or changes something they should not.

If you build internally, budget for permissions as security infrastructure. Do not treat them as a set of disabled buttons near the end of the project.

Media is more than a file input

File uploads are another feature that looks finished early.

Choose a file, send it to storage, save the URL. It works beautifully in a demo.

Production introduces less cooperative files. Images are too large, use unexpected formats, have duplicate names, or lose their connection halfway through an upload. Editors need progress indicators and useful error messages. The frontend needs responsive sizes. Accessibility requires alt text. Teams eventually want a library where they can find and reuse an existing image.

Deletion creates its own mess. If an asset appears on four pages, should an editor be allowed to remove it? If they replace the file, should the URL remain stable? When an entry is deleted, does its image stay in storage forever?

These are solvable problems. They are also a poor use of a product team's time when media management has nothing to do with what makes the product distinct.

A mature headless CMS has already dealt with the boring cases. Boring is a compliment here. Uploading an image should be boring.

Your frontend does not need to change

A common concern is that adding a CMS means rebuilding the website around it.

That is not how a headless CMS works.

The CMS stores and manages structured content. Your frontend requests that content through an API or SDK, then renders it with the components and styling you already own. The editing system and presentation layer remain separate.

You can also migrate gradually.

Start with a frequently updated area such as FAQs, announcements, or blog posts. Keep the rest of the page in code. Once the integration is working, move other content when there is a reason to do so.

Your routes do not need to change. Your design system does not need to change. Customers may never know that the source of the content changed.

Building internally can support the same architecture, but your team must create and maintain the API. That includes authentication, filtering, pagination, caching behaviour, error responses, and versioning as the schema evolves.

When people estimate an internal CMS, this API work often disappears into a single line on the project plan.

When you should build your own CMS

There are good reasons to build.

If content management is part of the product customers pay for, the workflow itself may be your advantage. A legal publishing system, a specialist learning platform, or a regulated document process may need behaviour that a general CMS cannot express cleanly.

Strict infrastructure or regulatory requirements can also narrow the available choices. In that case, owning the full stack may be necessary.

Small, fixed requirements are another reasonable exception. If an internal settings page contains five fields and only two trusted people will use it, introducing a CMS may create more complexity than it removes.

The useful test is whether you are building a settings form or an editing system.

A settings form updates a small number of known values. An editing system manages growing collections of content, relationships, uploads, permissions, and publishing states. Once you are building the second one, compare it with a headless CMS before writing more code.

When a headless CMS is the better decision

Use a headless CMS when your product is valuable without the CMS itself.

Your engineers should be improving the product, but content changes keep pulling them into small updates. Marketing or operations needs independence. The company needs a safer workflow than editing JSON, opening pull requests, or sending developers messages whenever a sentence changes.

It is also a strong fit when you already have a frontend you like. Headless architecture lets you add an editing layer behind it without surrendering control of the design.

The subscription or hosting cost is visible, which can make it feel expensive next to internal development. Engineering time is less visible because it is spread across planning, implementation, code review, bug fixes, support, and future migrations.

It still costs you.

Why we recommend Dyrected

We built Dyrected for product teams that want to keep control of their application without owning another internal platform.

Developers define collections, fields, validation rules, and access control in TypeScript. The schema lives in the repository, where the team can review changes in pull requests and track them through Git.

Dyrected generates the admin interface from that schema. Editors get focused forms, media management, and access to the content they are responsible for. They do not need access to the codebase, and they cannot quietly change the structure your frontend depends on.

Your application reads content through a REST API or type-safe SDK. Dyrected can fit into an existing Next.js or Nuxt application, so you can keep the frontend, components, and deployment workflow you already use. You can adopt it one content area at a time.

Teams can use Dyrected Cloud or self-host it when infrastructure control matters.

If you need a proprietary editorial workflow that defines your product, build it. You will understand the tradeoff and have a reason to keep investing in it.

If you need structured content, a dependable admin interface, permissions, uploads, and an API so your teammates can work without engineering support, those are solved problems. We do not think your team should lose months solving them again.

[Join Dyrected early access](/early-access) and add a CMS to the product you already have.