CorgiBOX only wanted to add login. It ended up building a CIAM.

To get the product to market quickly, the team chooses a modern stack and an integrated authentication service. Email. Google. Password recovery. Sessions. The requirement is covered, and it is probably the right decision. The problem starts later, when CorgiBOX continues to treat this layer as “login” while the business around it has changed.

The first version implicitly relies on a very simple model: one email address is one person, one person is one account, one account is one workspace, and the user has a few permissions.

Then CorgiBOX grows. An association wants a shared organisation. A veterinary clinic needs multiple users. A brand wants to separate its French and Belgian teams. A consultant belongs to several customer organisations. An administrator needs to invite colleagues without being able to access all of their data.

The user table is no longer enough. CorgiBOX adds organisations, memberships, invitations, roles, an active tenant and additional access rules. Every addition makes sense. But identity has already changed in nature.

Alice is no longer simply user_123. She is a person who may have several ways to sign in, belong to several organisations and hold different roles depending on the context. Disabling Alice for one customer must not necessarily delete Alice from CorgiBOX. An organisation is not merely an organization_id column.

The first large customer has a perfectly reasonable requirement: “We use Microsoft Entra. We need SSO. And when an employee leaves our company, their access must be removed automatically.”

CorgiBOX adds SAML or OIDC federation. Then SCIM provisioning. And new questions appear.

What happens to a user who already signed up with Google before SSO was enabled? Should the accounts be linked, based only on the email address? Which mechanism actually creates the membership: an invitation, first SSO login or SCIM? What happens when a group changes in the customer directory? How do we disable only this customer membership without deleting the global account? What should the customer's own IT administrator be allowed to configure?

Then a second enterprise customer arrives with another identity provider, another group model and different attributes. Then a third.

SSO is no longer a feature. It has become a customer onboarding and operations process.

As CorgiBOX succeeds, some operations become more sensitive. Changing professional account details. Exporting large volumes of data. Granting significant delegation. Changing billing information. Recovering an administrator account.

Successful authentication is no longer enough to answer: “Should this operation be allowed right now?”

CorgiBOX gradually adds device checks, risk signals, MFA, step-up authentication, an identity proofing provider, manual review and stronger account recovery controls.

The same user now has an identifier in the authentication platform, another inside CorgiBOX, a verification case with a specialist provider and several risk events. None of these products is necessarily the problem. The difficult part is deciding how their decisions fit together and which person, organisation and action they relate to.

The problem is no longer just authentication. It is identity orchestration.

Until now, CorgiBOX AI mostly assisted the user. Now it acts. One agent classifies content automatically. Another retrieves information from an external service. An assistant can prepare an action for the user to approve. Some workflows run asynchronously.

The old user_id + session model reaches another limit. The system must answer four different questions: who requested the action? Who actually executed it? For which organisation? Under which delegation and for how long?

The agent needs its own technical identity. But it must not become a super-user. Its actions need to remain attributable to a human, a tenant, a policy, a scope and a duration.

The audit trail should be able to explain that Alice requested an action, a CorgiBOX agent executed it, for Acme, within a defined scope, under an authorisation that was still valid at execution time. For an AI-backed company, this question can arrive much earlier than expected.

At every stage, building internally may have appeared cheaper. One more table. One webhook. One script. One administration component. One additional API check. One specialist provider connected in a few days. Taken individually, all of these developments may be reasonable.

Their real cost eventually appears elsewhere: webhooks that need replaying, account repair scripts, session incidents, duplicate accounts, customer-specific SSO mappings, support tickets, regression testing, security work, audits, and above all product engineers who are no longer building the product.

Build versus buy is therefore not really a comparison between a paid licence and a free solution. It often compares an identity platform industrialised by a vendor with a proprietary identity platform the company never intended to build, maintain and operate.

Moving to a CIAM platform from a vendor such as Ping Identity or Auth0/Okta does not make the project automatic. Design is still required. Sources of truth must be defined. People, accounts, organisations, memberships, roles and delegations need a model. Journeys must be designed. Federation must be configured. Account-linking rules must be defined. Migration must be prepared. Applications and APIs must be integrated. The result must be tested and operated.

The important difference is that the company progressively stops rebuilding generic identity-platform capabilities and relies on a vendor product designed to industrialise and evolve them.

Specialist fraud, identity-proofing or authorisation providers do not necessarily disappear. The CIAM can become the coherent point from which journeys, policies and assurance levels are orchestrated.

At Ariovis, the first step would not be to immediately replace everything CorgiBOX already has. It would be to understand what CorgiBOX has actually built: map identities, organisations, sessions, roles, events, delegations, providers, agents and journeys.

Then define a canonical model: Person, Identity, Account, Organization, Membership, Role, Delegation, Agent, Verification Case, Risk Decision. Then define an authority for each object and each decision.

Only after that should the target architecture be selected. Some existing components may remain. The business database can remain the business database. A specialist fraud engine can continue to serve its purpose. Microsoft Entra or Keycloak may remain relevant where they already solve a specific requirement. The CIAM becomes the coherent foundation that stops every new application and journey from reimplementing the same identity problems.

For Access Management and CIAM, Ping Identity is Ariovis' reference technology partner. But our role is not to drop a Ping licence into the customer environment. Ariovis scopes, designs, configures, integrates, migrates and tests the platform, then supports its production deployment in the customer's real environment.

The goal is to deliver a useful and operable first scope quickly, then extend it progressively rather than turning identity into a massive replacement programme. For a sufficiently defined scope, with explicit prerequisites and acceptance criteria, Ariovis can commit to the delivered outcome rather than simply selling a number of consulting days.

The vendor maintains and evolves its SaaS. Ariovis makes that SaaS fit the customer's product, business processes, risks and operating constraints. That is where the economics truly change: CorgiBOX engineers can go back to building CorgiBOX.

Continuing to develop identity piece by piece can then cost far more than the licence the company originally thought it was avoiding.

You do not move to CIAM because you have many users. You move when identity has become a shared product the company must operate, audit, evolve and contract around.