A simple map of Cercly's SaaS architecture

When a platform starts stacking multiple interfaces, multiple APIs and multiple technical dependencies, the difficulty is not only making the whole thing work.

The real difficulty is deciding where each responsibility should live.

That is what this map tries to make readable: not an inventory of services, but an application split that lets you decide faster, build faster and keep the system defensible over time.

The real subject: role distribution

An architecture rarely holds because it has many boxes.

It usually holds because the boundaries between those boxes remain readable as the system grows.

In a platform like Cercly, the useful question is therefore not only “how many apps” or “how many APIs”.

The useful question is rather:

• what belongs to the interface;
• what belongs to adaptation;
• what belongs to the business layer;
• and what belongs to shared dependencies.

Separate interfaces because the usages are separate

The first structural choice is not forcing everything into a single frontend.

The member portal, the association dashboard, the operator workspace, the public portal and the mobile app do not share the same journeys, the same session constraints or the same pace of change.

Artificially grouping them into one surface often creates the illusion of simplicity. In practice, it tends to mix needs that do not age in the same way.

Separating interfaces here is not about multiplying projects for the sake of it. It is about preventing a need specific to one surface from becoming a global constraint for all the others.

A shared design system, but at the right level

The shared design system matters, but it does not replace application boundaries.

Its role is simpler and more useful: provide a common language across interfaces.

When that foundation is clean:

• components keep a coherent visual language;
• teams share the same base;
• duplication goes down.

But it should not be asked to solve problems that belong to the business layer or orchestration. Visual consistency is helpful. It is not an application architecture by itself.

BFFs as the adaptation layer

The most misunderstood part of this kind of map is often the role of BFFs.

They are not there to “add one more layer”. They are there to prevent adaptation complexity from spreading to the wrong place.

In this model:

• interfaces own the user experience;
• BFFs own client-specific needs;
• business APIs remain focused on their domain.

Without that layer, two common drifts appear quickly:

• either frontends absorb too much integration logic;
• or the central API becomes an accumulation point for needs that are highly specific to each surface.

BFFs exist precisely to avoid that double drift.

Two business APIs, not one large API

The other important choice is the clear separation between operator-api and platform-api.

This is not a minor organisational detail. It is a way to protect business responsibilities.

The operator plane does not carry the same rules, the same flows or the same constraints as the platform used daily by associations and members.

Bringing everything back into a single API can look simpler at first. In practice, it often makes business boundaries blurrier, which makes change more expensive over time.

A good split does not remove complexity. It simply decides where that complexity is allowed to live.

Shared infrastructure, but not the main subject

The database, Redis and RabbitMQ appear on the map, but they are not the core of the article.

Their role here is mostly to remind us that an application architecture never floats in the air. It relies on shared dependencies that need to be shared with discernment.

But the system’s real robustness does not come from simply having Redis or RabbitMQ.

It comes more from the fact that the layers above clearly know who depends on what, and for which reasons.

What this split changes when building with AI

One of the most useful effects of this kind of architecture appears when the goal is to build fast.

When boundaries are clear, AI can accelerate execution without accelerating disorder at the same pace:

• a frontend can evolve without rewriting the business core;
• a BFF can absorb a client-specific need without contaminating the whole API;
• a business API can stay readable even while multiple surfaces move in parallel.

In other words, AI helps most when the ground is already structured.

It accelerates code production. It does not replace the boundary work.

The clearer the responsibilities are, the more realistic it becomes to move fast without recoupling the system on the way.

What this architecture is trying to protect

The important point is not having multiple boxes.

The important point is keeping a readable split of responsibilities:

• interfaces own the experience;
• BFFs own adaptation;
• APIs own the business layer;
• infrastructure owns shared dependencies.

When that split stays clear, the system evolves with less unexpected coupling.

The needs of one client do not spill into all the others. Frontend changes do not force the business core to bend. And central APIs do not need to absorb every product exception on their own.

In one sentence

The real subject is therefore not the diagram. The real subject is the discipline of application boundaries that allows the system to grow without recoupling everything.