The starting point
You want to get ahead with AI and with your data. A new platform has to be multi-tenant, an existing one is hitting its limits, or your data has to become usable for AI. Decisions on isolation, identity and data flow are expensive to change later, so we look at them together early.
Who it's for
- CTOs and engineering leads of new SaaS and data platforms
- Software companies with their own product
- Industrial companies with a platform project
- Teams that want to make their data usable for AI
What we look at
Seven areas from our daily work on our own platform. For each one you see how we solved it at demi.
Isolation
Multi-tenancy
Silo, pool or bridge. Isolation in the database, services and storage.
At demi
Postgres row-level security with a tenant context per transaction, also behind a transaction pooler.
Access
Identity, permissions and security
SSO, one organization per tenant, roles and relationships, permissions for agents. The AI model never decides on permissions.
At demi
SSO through the customer's IdP, RBAC and ReBAC as a dedicated service.
Data layer
Data and data access
Write paths, a gateway for data access, customer variants as configuration instead of forks.
At demi
Central API gateway for data access, enforced by a lint rule. Features, plans and per-tenant overrides are data.
AI-ready
Making data AI-ready
Which data a model may see, in what form and with what provenance. Preparation, a permission check on retrieval, sourced answers.
At demi
demi builds a knowledge twin from documents and systems. Every retrieval runs through the same permission check as the data itself.
Events
Events and workflows
Outbox, event streaming, durable workflows, agents with clear permissions.
At demi
Transactional outbox, Kafka API, delegated tokens for agents.
Operations
Operations as code
Infrastructure as code, GitOps, architecture rules in CI, rollback.
At demi
Pulumi, GitOps with ArgoCD, canary gate and rollback. Architecture rules as CI checks.
Cloud
Multi-cloud and target cloud
Infrastructure as code, abstracted from the cloud: AWS, Azure, Google Cloud or European providers. Silo, pool or bridge per layer, connection pooling, fair queues per tenant.
At demi
We run several clouds and describe them as code. In production we use AWS among other clouds. Managed building blocks such as proxy pooling or fair queues we do not run ourselves; we design them for your target cloud.
How we work
- 1
Capture
Goals, quality requirements and your guidelines. We work with your domain experts and your team.
- 2
Model
Domain boundaries, data model, tenancy model.
- 3
Design
Components, data flows, permissions, deployment as code on your target cloud.
- 4
Hand over
Walk through scenarios, review, handover to your teams. On request we stay with you through the build.
Every step ends with a review. How much time the steps take follows the scope: from a few days for a first look to several weeks for a full target picture.
Documented to common standards
- arc42
- C4 model
- Architecture decision records
- Domain-driven design
- Threat modeling
What you end up with
- A target picture of your platform that your team builds on
- A concept for the data layer and data access
- A concept for making your data AI-ready: preparation, permissions, provenance
- Tenant isolation, permissions and onboarding of new customers
- A target picture for your cloud: infrastructure as code, provider replaceable
- The decisions, the open questions and the next steps
The concept describes a target architecture based on documented requirements and assumptions. It does not replace implementation, load or penetration testing, or an audit or certification. Statements on performance, scale and cost are reasoned estimates, not guaranteed properties.
Review
A look at an existing platform
Before you scale or rebuild, we compare documentation, code and operations and tell you where it hurts.
Formats
- A compact look at the critical parts
- A full review of documentation, code and operations
Deliverables
- An assessment of tenant separation and data access
- The risks, ranked by weight
- Prioritized next steps
An expert assessment based on the documents, code excerpts and interviews provided within the agreed timeframe. Not an audit or an audit opinion. Passing results to third parties requires our consent in text form and creates no third-party claims.
Build on demi
demi is a data layer and an AI backend. If it fits your target picture, your team builds straight on it.
Data layer: Documents, products, customers and events live in one model, with permissions and tenant separation.
AI backend: Knowledge twin, agents and workflows are ready to use. Your team builds its own applications on them.
Not a prerequisite: An architecture project does not need demi. We tell you openly when we recommend it.
Frequently asked questions
How long does it take?
That follows the scope: from a few days for a first look to several weeks for a full target picture. We settle it in a call.
Which cloud do you assume?
None. We work with infrastructure as code, which keeps the target architecture cloud-agnostic: AWS, Azure, Google Cloud or European providers. We run demi itself across several clouds, and our lead architect has extensive AWS experience in design and operations.
Do you also deliver code?
In an architecture project we design. Open questions are captured as next steps, and we support the build with reviews on request. AI systems we build together with your team on demi.
How do you handle confidential material?
Before we start, we agree in writing which AI tools may process your material and where. We sign an NDA before the project starts.
Can we build on the demi platform?
Yes. demi is a data layer and an AI backend: your team can build its own applications and workflows on it. It is not a prerequisite for an architecture project.
Let's settle the scope.
30 minutes on goal and constraints. If it fits, you then get a proposal with a clear scope.
Talk to usOur services are offered to businesses only.