Directus: a powerful headless CMS, but sometimes too technical

When it comes to headless CMS, Directus often comes up as one of the most serious options. And that’s no coincidence. The platform allows you to connect a SQL database, visually model your data, instantly generate REST and GraphQL APIs, and manage highly granular permissions through its Data Studio. In fact, Directus positions itself less as a simple CMS and more as a flexible backend for data-driven projects, with a full admin layer on top of the data.

From a technical standpoint, it’s an especially compelling tool. For a product team, a technical team, or an agency looking to build a robust foundation, Directus ticks many boxes: clear structure, access governance, API-first logic, compatibility with modern stacks, and the ability to power a website, an app, or multiple interfaces from a single source of truth. This is precisely why it’s generating so much interest among companies looking to move away from a monolithic or overly rigid CMS.

But one question often comes up once the project is launched: Is Directus as enjoyable for non-tech teams to use as it is for developers to set up?

This is where things get more interesting. Because in many projects, the real challenge isn’t just choosing the right backend. The real challenge is delivering an interface that business, marketing, content, or operational teams will truly understand, adopt, and use seamlessly on a daily basis.

And this is precisely where Directus, despite all its strengths, can sometimes show its limitations.
‍

Why developers and product teams love Directus

Before discussing its limitations, we must be clear: Directus is so widely adopted because it delivers real value.

First, it allows you to work with a SQL database using a far more structured logic than a traditional page-oriented CMS. You define collections, fields, relationships, and permissions, then expose everything via documented APIs. This approach is extremely valuable once a project goes beyond simple marketing content publishing and starts handling business objects, directories, catalogs, workflows, or data shared across multiple interfaces.

Then, Directus offers particularly granular access governance. Permissions and policies allow you to control what each role can view, create, edit, delete, or share. In environments where multiple profiles interact with data, this is a major advantage. It’s not just about publishing content—it’s about securing access to sometimes sensitive information with rules tailored to each use case.

Another strong point: extensibility. Directus allows you to go beyond the standard with interface extensions, modules, layouts, panels, or displays in its Data Studio. On paper, this opens up a wealth of possibilities to tailor the tool to a specific business context. This capability is real, and it’s also why Directus appeals to technical profiles who want a solid yet open foundation.

In short, Directus isn’t “just” a CMS. It’s an excellent content and data engine with a modern backend logic. And for many projects, it’s exactly what’s needed.
‍

Where the promise sometimes clashes with on-the-ground reality

The problem rarely starts during the technical scoping phase. It usually appears after launch, when the client or non-tech team starts using the tool daily.

On paper, Directus’s Data Studio is clean, clear, and well-structured. In practice, however, its usability remains closely tied to the underlying data logic. And that’s where the real challenge lies: an interface designed around a relational model, even if well-crafted, isn’t necessarily intuitive for users who think in terms of pages, blocks, campaigns, records, or business actions.

In other words, what comes naturally to a developer or product builder isn’t necessarily intuitive for a content manager, marketing lead, salesperson, or end client.

This friction isn’t just an isolated impression. It’s reflected in public reviews. On G2, one user explains that most feedback from their internal users concerns the editing interface, which is sometimes described as “clunky,” especially when editing child collections in a side drawer or understanding the relationships between collections—something that can make it easy to lose track of the component hierarchy.

This feedback is interesting because it doesn’t question Directus’s power. It highlights something more subtle, yet more critical in real-world contexts: the cognitive load of editing.

As long as the model is simple, everything works fine. But once you start working on a project with multiple interconnected collections, nested components, relationship levels, business validations, or role-specific workflows, the interface can become harder for non-technical users to grasp. The issue isn’t a lack of features. The issue is the gap between the technical structure and the user experience.
‍

The real issue: an excellent back-office isn’t always an excellent business interface

This is often where projects misdiagnose the problem.

We sometimes hear: “The client wasn’t trained enough.”
Or: “We just need to plan a more thorough onboarding.”

Of course, training helps. But it doesn’t solve everything. When an interface requires users to understand a data logic that doesn’t align with their workflow, the problem isn’t just educational—it’s also a product issue.

A good business interface shouldn’t require a user to think like the database architect. It should let them do their job with as little friction as possible.

This is why a tool can be technically excellent yet imperfect in a client context. Directus is highly effective for centralizing, structuring, securing, and exposing data. However, as soon as the main challenge becomes adoption by non-technical users, the question is no longer “Can Directus do it?” but “Is the native interface the best way to do it?”

In many cases, the answer is: not entirely.
‍

Yes, Directus is customizable… but not without cost

It would be wrong to say Directus doesn’t allow interface customization. On the contrary, the platform emphasizes a highly extensible logic, with app extensions loaded into the Data Studio and built in Vue 3, JavaScript, or TypeScript, using the Directus SDK. The official codebase overview also notes that the Data Studio itself is written in Vue.js 3.

But this is precisely where the important nuance lies.

Customization does exist. However, when aiming for a truly tailored interface for a client or business team, you quickly move beyond simple configuration. You enter a custom development logic: UX thinking, screen design, component creation, handling business cases, maintenance, compatibility with project updates, etc.

In other words, advanced customization of the editing experience comes at a real cost.

This need isn’t new. It has existed for a long time in the Directus ecosystem. An old GitHub issue already asked how to display a custom interface for clients while keeping the standard interface for admins. So this isn’t an edge case invented by a few agencies—it’s a recurring need whenever Directus is delivered to end users with very different use cases than developers.

This is where many projects lose time. They start with Directus for its quick setup, only to discover that making the experience perfectly suited to non-technical users requires far more effort than anticipated.
‍

{{cta}}
‍

Where non-tech teams really struggle

In the projects we see, friction points are rarely “technical” in the strict sense. They’re mostly tied to daily usage.

For example:

A marketing team doesn’t want to “manage a collection with relationships.” They want to update a campaign page without wondering where it fits in the content hierarchy.

A sales team doesn’t want to navigate through multiple views or understand the difference between a parent item and linked sub-elements. They want to quickly find the right record, update the correct information, and be confident nothing will break.

An end client doesn’t want to see a generic back-office with every possible option. They want a streamlined interface, limited to their scope, that speaks their business language.

That’s why Directus’s limitation isn’t necessarily its power, but its starting point: the tool begins with the data. Yet some users start with the action.

And this difference changes everything.
‍

Directus alone is often a great choice… until adoption becomes the priority

Let’s be honest: in many cases, Directus alone is more than enough.

If your team is comfortable with concepts like collections, fields, relationships, and roles, the native interface does the job perfectly. If you have product or ops profiles who already use structured tools, the learning curve can be quick. And if your main goal is to have a flexible, well-governed, and interoperable backend, Directus remains a very solid option.

But as soon as adoption by non-tech users becomes a key criterion, you need to shift your perspective.

The question is no longer just: “Does the system work?”
The real question becomes: “Will users interact with it smoothly, autonomously, and confidently?”

At that point, it becomes relevant to separate two layers:

• Directus as the data, permissions, and API engine
  
• a custom interface as the business usage layer
  

And this distinction fundamentally transforms the quality of the delivered product.
‍

Our belief at Scroll: keep Directus as the engine, build a front-end designed for users

This is the approach we advocate for projects where Directus is technically relevant, but where the native interface isn’t the best solution for user experience.

Rather than forcing business teams to adapt to the back-office logic, we prefer to keep Directus for what it does best—structuring, centralizing, governing, and exposing data—then build a front-end tailored to the maturity level and needs of end users.

Concretely, this allows us to radically simplify the experience.

The user no longer sees a generic interface. They only see the actions they truly need to perform.

Forms no longer reflect the full complexity of the data model. They reflect a clear business workflow.

Screens can adopt the client’s vocabulary, hide unnecessary elements, group certain steps, guide the user, reduce error risks, and speed up onboarding.

Behind the scenes, Directus continues to play its role as the foundation. The data remains structured. Permissions remain controlled. APIs remain available for other system components. The project thus retains the benefits of a modern backend without imposing its native logic on all users.

In our view, this is the best of both worlds.
‍

When should you consider a custom front-end on top of Directus?

Not every project needs it. But certain signals should raise a flag.

First signal: the client is non-technical and needs to frequently interact with the tool.

Second signal: the data model includes multiple relationships, sub-collections, nested content, or business rules.

Third signal: multiple user profiles with very different expectations need to use the interface.

Fourth signal: the tool should resemble custom business software more than a generic CMS or back-office.

Fifth signal: the main challenge isn’t just managing data, but ensuring user autonomy and long-term operational quality.

In these cases, it’s often more cost-effective to design the interface from the start rather than stacking workarounds or compensating for friction with ongoing training.
‍

Directus alone or Directus with a custom front-end: how to choose?

The choice can be summed up very simply.

Directus alone is often the right choice if:

• users are comfortable with structured tools,
  
• the model’s complexity remains manageable,
  
• the internal team has a product or technical culture,
  
• the primary need is to centralize and govern data.
  

Directus + custom front-end often becomes preferable if:

• end users are non-technical,
  
• ease of use is a business priority,
  
• the project involves genuine business logic,
  
• the interface needs to hide the model’s complexity,
  
• adoption and autonomy are just as critical as architecture.
  

The key point is that you shouldn’t have to choose between “Directus” and “no Directus.” You should choose how Directus should be used in your architecture.

And that’s a crucial difference.
‍

Directus is often an excellent technical choice, but user experience shouldn’t be an afterthought.

Directus clearly deserves its place among the most compelling tools on the market for structuring and exposing data. Its API-first approach, admin layer, granular permissions, and extensibility make it an outstanding foundation for many projects.

But in a real-world project, success doesn’t depend solely on backend quality. It also depends on end users’ ability to work quickly, effectively, and confidently with the tool they’re given.

This is where clarity is essential: an excellent content engine isn’t always an excellent business interface.

At Scroll, this is precisely why we don’t just look at a stack’s technical performance. We also consider the user experience it will enable tomorrow. When Directus is the right foundation, we keep it. But when the native interface becomes a source of friction for non-technical users, we prefer to build a simpler, clearer front end that’s better aligned with real-world use cases.

Because ultimately, a tool isn’t successful just because it’s well-designed from a developer’s perspective. It’s successful when the people who need to use it daily genuinely want to.