We run a payment system on Strapi, and chose Directus for our own site

At lunchtime in the muRata canteen, staff pay with their employee card. The amount comes off a top-up Rabbit card and they carry their tray to a table. Behind that till is an API we built on Strapi, and it is still running in production today (read about the project).

The site you are reading now does not run on Strapi. It runs on Directus.

The same team chose differently because the two jobs are hard in different places. This is not an argument that one is better. It is what the difference looks like from running both, so you can decide for your own project.

The real difference is who owns the data model

Strapi starts from code. Each content type is a schema.json file in the project, with its own controller, service and routes. Smart Canteen has six of them: canteen, shop, menu, menu group, dish and transaction. They live in git, go through code review, and ship with the rest of the code.

Directus starts from the database. A collection is a real SQL table. Add a field in the admin and the table changes, and the REST and GraphQL APIs expose the new field straight away. No build, no restart.

In one, the database is an output of the code. In the other, the API is an output of the database. That single difference leads to two quite different ways of working.

Strapi shines when you have logic to write

A canteen payment system is not just storage. Every transaction has to be checked before it is saved, and things have to happen once it is.

Strapi served us well here. It gives you places to run code before and after a write, so the custom validation and the post-transaction actions were plain JavaScript in the same project: testable, readable months later, and easy for a new developer to follow.

When logic is the heart of the system, keeping the model in the same codebase as that logic is an advantage, not a cost.

The price you pay each time the model changes

The same property has a price. In production, Strapi's Content-Type Builder is switched off; it only works in development. So when the client asks for one more field, the schema changes in code, and the app is rebuilt and redeployed.

We paid that price on Smart Canteen. Each change and deploy took roughly 10 to 30 minutes, and that was not the end of it. Because money moves through the system, every deploy was followed by a long round of testing before we trusted it again.

For a system whose shape has settled, that is fine. A handful of changes a year costs little. For a company website whose content and structure move almost every week, it becomes the bottleneck.

Why this site is on Directus

When we started this site in mid-August 2026, Strapi was the first thing we considered. We know it well and we know it is good. But looking at how the site would grow, we chose Directus because the data model can change without stopping the API or redeploying it.

The back office now holds 30 collections we created ourselves: posts, works and solutions, but also the welcome banner, the navigation, redirects from the old WordPress site, job applications and cookie consent records. Many of those were not in the plan on day one. They were added when the need appeared, and the site never had to stop for any of them.

Flows are the other part we have come to rely on. A flow called Revalidate the website tells the front end whenever content changes, and the update is live within about a minute. We never deploy to publish content. We deploy only when the front-end code changes.

"No developer needed" does not mean no code

This is the most common misunderstanding. When people hear that Directus lets you change the model without a developer, they picture everything being done by clicking around the admin.

In practice, this site has 54 scripts for Directus, and 21 of them create or change collections, fields and relations through the API. The reason is that we run two environments, UAT and production. Change both by hand and sooner or later they drift apart. Scripts make each change repeatable, reviewable and kept in git.

So the real line is not code versus no code. It is whether changing the model means stopping the system. With Directus we run those scripts against a live instance. And for small changes that do not need to cross environments, someone who does not write code really can make them in the admin.

Hidden costs worth knowing up front

Two things rarely show up in a feature comparison.

The first is version lifetime. Smart Canteen still runs on Strapi 4. Strapi stopped fixing bugs in it at the end of October 2025 and stopped shipping security fixes at the end of April 2026. Moving to Strapi 5 is not a button: there are breaking changes in server code and in the response format that client apps consume, so it has to be planned as a piece of work. Our own system is in exactly that position, and we would rather say so. Nor is this unique to Strapi. With any framework where the model lives in code, a major upgrade will touch your code.

The second is licensing. Strapi Community is MIT. Directus is under BSL 1.1: free in production for organisations with total finances under 5 million US dollars, with a commercial licence required above that. It does not affect us, but if you build for large organisations, check it before you quote.

How to choose

"It depends" is not much of an answer, so here are the questions we would ask.

If the complexity is in business logic, with calculations, checks and follow-on actions that must be tested hard, and the data model should settle once the system is live, Strapi fits. That is why Smart Canteen still runs well today.

If the complexity is in the data itself, with collections that keep arriving, content managed by people who are not developers, or an existing SQL database you want to wrap in an admin and an API without moving it, Directus fits better.

If your project has both, ask which will change more often over the next two years: the logic or the shape of the data. That answer usually points the way more clearly than any feature list.

For us the answer came out differently on two projects, and we still run both. If you are weighing the two for a system of your own, talk to us. We are happy to share what we have run into on each side.