Why we built our own headless CMS and backend platform

Building our own headless CMS was never the plan. Like most studios, we started each client project by picking a stack, wiring up authentication, choosing where files would live, writing a deployment pipeline and bolting on monitoring. Then the next project arrived and we did it all again, slightly differently. After enough repetitions, the repeated part was clearly the problem, so we built EasySiteControl: one backend platform that every build can stand on.

This post covers what kept getting rebuilt, what a shared backend actually gives you, and the honest trade-offs against adopting an open-source CMS like Strapi or Directus, which we still use where they fit.

The work we kept rebuilding

Most client websites and web apps differ in their front end and their business logic. Underneath, they need almost the same things:

• Authentication: sign-up, sign-in, OAuth, roles, password resets, session handling.
• Data storage: a database, a schema for content and records, an API in front of it, file and image storage, backups.
• Deployment: build pipelines, environments, container setup, a reverse proxy, TLS.
• Monitoring: logs, error tracking, performance data, alerts when something stops responding.

None of this is hard on its own. The cost is that each project's version is a little different, and every difference is something to remember, patch and secure separately. A security fix in one project's auth flow doesn't reach the other five. A backup script tested on one server was never tested on another. The work is boring, it isn't billable in any meaningful way, and it is exactly where production incidents come from.

What a shared backend gives you

EasySiteControl (ESC) is a complete Backend as a Service platform. It provides managed databases, file storage, REST and GraphQL APIs, serverless functions, CI/CD pipelines, container orchestration, WebSockets, push notifications and monitoring from one place. It is built on Node.js, PostgreSQL, Docker and NGINX, in TypeScript.

The practical effect on a new build:

The front end starts on day one

Because content models, APIs and auth already exist, front-end work doesn't wait on backend scaffolding. You define the content schema for the project and the API is there.

Fixes land everywhere

When we improve auth handling, file storage or monitoring in ESC, every project on the platform gets it. That is the single biggest reason to consolidate: it turns many small maintenance burdens into one.

Editing is consistent

ESC powers our own open-source packages, esc-editor (a WYSIWYG HTML editor for React) and the esc-json-form family (schema-driven JSON form editors for React and Angular). Editors on different client sites get the same content editing experience instead of a different admin panel per project.

It works with what you already have

Teams can bring their own services and connect existing MongoDB, Redis or MinIO instances alongside ESC's managed infrastructure. A migration doesn't have to be all-or-nothing.

ESC runs in production today. It is the platform AnixoCart, a mobile-first e-commerce storefront we built for a lifestyle brand, and our client sites run on, handling product and content management behind a server-rendered Next.js front end.

Build vs adopt: the honest trade-offs

We are not arguing that everyone should build their own CMS. Strapi and Directus are part of our own stack too, and we build headless CMS backends on them (and on PocketBase) when they suit the project. They are excellent tools. Here is how we think about the choice.

When to adopt

Choose Strapi or Directus when you are building one product, when your team already knows them, or when the client wants a widely used tool another agency could pick up later. Directus is particularly good when you already have a SQL database and want an admin layer and API over it. Strapi is a solid default for content-heavy sites where editors need a friendly interface.

When building makes sense

Building your own only pays off when three things are true:

1. You repeat the same backend many times. One project never justifies a platform.
2. You need more than a CMS. Our pain was not only content modelling; it was auth, storage, deployment and monitoring together. A CMS alone didn't remove most of the rebuilt work.
3. You can commit to maintaining it. A home-grown platform that stops getting security updates is worse than any open-source option.

If you can't say yes to all three, adopt.

What we'd tell anyone considering it

• Start by extracting, not designing. The useful shape of a platform comes from the second and third projects, not from a whiteboard. Pull the repeated parts out of real builds.
• Keep the front end independent. ESC is headless on purpose. Each site keeps its own front end (AnixoCart's is a server-rendered Next.js app), so nobody is locked into a templating system.
• Treat the platform as a product. It needs versioning, a changelog, backups that are actually restored in testing, and monitoring of its own.
• Leave escape hatches. Bring-your-own database and storage support exists because real clients arrive with existing systems.

Where this leaves a new project

For a new client build, the question is no longer "which backend this time?" ESC is the default starting point. Some projects are better served by Strapi or Directus, usually when the client's team already runs them or wants a tool they can hand to another vendor. Either way the decision is made on fit, not on what's quickest to scaffold.

You can see ESC alongside our other products on the projects page, and the backend and CMS work we do for clients is described under services. If you're weighing up a headless CMS for your own build, or want to stop rebuilding the same backend across projects, get in touch.