Identity and tenancy
Authentication, workspace context, roles, permissions, and data isolation must remain coherent across application boundaries.
Owned product · Prelaunch
Designing applications around shared services.
CetaSpace is a separate TechnoConception product in development. This case presents its interfaces and architectural decisions through controlled QA examples. It does not present customer deployment or commercial results.
- Product in development
- Controlled QA examples
- Architecture decisions
Common functions across several applications.
CetaSpace is being developed as a unified SaaS platform for content, digital workflows, commerce, analytics and AI-assisted experiences.
The engineering scope spans applications and shared services: authentication, workspaces, permissions, billing, storage, analytics, content, forms, messaging, commerce and AI orchestration. The case describes product work and architectural concerns at this prelaunch stage. CetaSpace is separate from TechnoConception’s consulting services and Twenty CRM extension work.
Test interfaces
Three interfaces in development.
These captures show AI functions, operational monitoring and project coordination in a controlled test environment. Captions identify fictional data.
Shared foundations without turning every application into one deployment unit.
Several products and interfaces need consistent identity, data, platform capabilities, and operating rules while remaining independently evolvable.
Shared platform services
Billing, storage, analytics, content, forms, leads, messaging, commerce, and AI capabilities need reusable contracts.
Independent product evolution
Applications need clear ownership and deployment boundaries without duplicating critical platform behavior.
Simplified architecture
Connecting users, applications and services.
The diagram summarizes how responsibilities are divided between the main parts of the platform.
Boundary 01Users
Boundary 02Core identity & workspace
Boundary 03Product applications
Boundary 04Shared platform services
Boundary 05Data · storage · billing · AI
What the architecture needs to support.
An application needs to know who is acting, which data that person may access and which service performs the action. Those responsibilities must remain clear as the platform changes.
Tenant context is foundational
Workspace and permission boundaries belong in shared contracts so product applications do not invent incompatible access models.
Shared does not mean tightly coupled
Platform capabilities need clear interfaces, versioning, and ownership so applications can evolve without synchronized rewrites.
AI remains inside product boundaries
Agent actions need to follow application permissions. They need a reviewable record and a way for a person to intervene when the situation requires it.
Operations shape architecture
Releases, failures and data migrations need assigned owners and diagnostic tools planned during design.
Questions to examine in your own architecture.
These principles can guide a discussion of a platform with your team. Their application depends on the data, users and constraints of the engagement.
- Follow permissions. When a person’s access changes, which applications and copies of the data need to be updated?
- Assign shared services. Who maintains each interface, and who handles an incident affecting several applications?
- Verify AI actions. Which actions are allowed, how is their result confirmed, and when does a person need to intervene?
- Prepare for change. Can one application evolve without requiring every other application to update at the same time?
- Examine the evidence. Which tests, documented decisions and execution records support the proposed choices?
Complex platforms
Planning a complex software or AI platform?
Describe the applications involved, the data they need to share and the decision still open. We can discuss an architecture engagement suited to that situation.
