Most software engineers have built or worked on a SaaS product at some point. You define a problem, design a system around it, ship features, and iterate. There’s a relatively stable domain model. You know what a “user” is. You know what a “project” is. You know what your database looks like.

Working on a CMS, like we do at Directus, flips that entire mental model on its head.

When you’re building a CMS, you’re not building an application. You’re building the system that lets other people build their applications. And that means everything is dynamic — sometimes to a degree that feels almost philosophical.

That’s exactly what makes it interesting.

In SaaS, You Own the Data Model

In a typical SaaS product, the engineering team defines the schema. Even if it evolves, it’s still controlled. You can reason about it statically:

• Tables are known
• Relationships are known
• Validation rules are known
• UI flows are predictable

You can write code with assumptions. You can optimize for specific use cases. You can refactor with confidence because you understand the entire domain.

There’s a certain comfort in that stability.

In a CMS, the Data Model Is a Runtime Concept

In a CMS, the schema isn’t something you define once and version in migrations. It’s something users create, change, and reshape constantly — often in production.

• Collections appear and disappear
• Fields change types
• Relationships evolve
• Permissions differ per project
• Extensions modify behavior at runtime

You’re writing software that must work for data structures you’ve never seen before. Sometimes even things you could not imagine in your wildest dreams.

That changes everything.

Instead of hardcoding assumptions, you build systems that discover their environment dynamically. Instead of designing a UI for one workflow, you design primitives that can represent any workflow. Instead of optimizing for a single domain, you build for unknown domains.

It’s less about building features and more about building capabilities.

Everything Is Dynamic

The most defining characteristic of CMS engineering is that nearly everything is dynamic:

• Schemas are dynamic
• Permissions are dynamic
• Interfaces are dynamic

Even the UI is often generated from metadata.

A form isn’t a form — it’s a projection of a schema. An API isn’t a fixed contract — it’s a reflection of the current model. A dashboard isn’t predefined — it’s assembled from configuration.

You’re building a system where the “shape” of the application doesn’t exist until runtime.

From an engineering perspective, this means:

• You rely heavily on metadata-driven design
• You think in abstractions and primitives
• You design for composability
• You optimize for flexibility over specificity
• You handle edge cases you can’t predict in advance

It forces you to write code that is defensive, generic, and adaptable — but still performant and intuitive.

That balance is the real challenge.

You’re Building a Platform, Not Just Features

In SaaS, you ship features directly to end users.

In a CMS, you ship tools that let other developers and teams build their own features. Your users are often builders themselves. That changes how you think about APIs, extensibility, and constraints.

Every decision becomes a platform decision:

• Will this scale across unknown schemas?
• Can this be extended later?
• Does this assumption break someone’s use case?
• Are we limiting creativity or enabling it?

You’re constantly thinking one level higher. You’re not just solving a problem — you’re designing a system that allows other people to solve their problems.

It’s a different kind of responsibility.

The Interesting Part: Embracing Uncertainty

At first, the dynamic nature of CMS engineering can feel uncomfortable. Engineers like certainty. We like defined models and predictable behavior.

A CMS removes that certainty by design.

But that’s also what makes it fascinating.

You get to work on systems that must be:

• Flexible but structured
• Generic but ergonomic
• Dynamic but reliable
• Extensible but coherent

You end up thinking deeply about abstractions, boundaries, and developer experience. You start asking questions like:

• How do we represent any schema elegantly?
• How do we generate UIs from metadata without losing usability?
• How do we make something infinitely flexible without making it confusing?

It’s engineering that sits somewhere between product development and platform design.

And when it works well, it feels almost like building a programming language rather than a traditional app.

Why It’s a Great Engineering Challenge

Working on a CMS means constantly solving problems at a meta level. You’re building systems that must work across industries, use cases, and data models you’ll never see.

It forces you to:

• Think in abstractions
• Design for extensibility
• Care deeply about developer experience
• Handle complexity without exposing it
• Build resilient, adaptable systems

It’s challenging, sometimes unpredictable, and occasionally mind-bending.

But it’s never boring.

And that’s the rewarding part.

Closing Thoughts

Building SaaS products is about delivering a specific solution. Building a CMS is about delivering a system for creating solutions.

One is about defining the shape of an application. The other is about enabling infinite shapes.

That difference makes CMS engineering uniquely dynamic — and uniquely interesting.

If you enjoy working with abstractions, building flexible systems, and designing platforms that empower others, it’s one of the most engaging spaces you can work in as an engineer.

Because in a CMS, nothing is ever truly fixed.

And that’s the point.