Multi-product SaaS on one platform core means several customer-facing products share identity, delivery, and observability infrastructure while keeping separate codebases, databases, and release cadences. DarDev runs DarDevLab, Hesabi, internal CRM and mailer stacks, and news properties on the same Kubernetes foundation—Workspace for access control, GitLab CI for builds, Prometheus and Grafana for metrics—without forcing every product into a single monolith repository.
The goal is one disciplined platform layer—not one giant app—so engineers stop rebuilding OAuth, deploy scripts, and alert routing for every SKU. Beta and waitlist products are labeled explicitly on dardev.net/solutions.
What belongs in the shared core vs each product?
Shared core services include cluster ingress and TLS, container registry, CI runners, centralized logging, metrics backends, secrets management, and Workspace IAM that gates who can deploy where. Product teams own application repos, business logic, Postgres schemas, feature flags, and customer-facing SLAs. Blurring that line—say, Hesabi invoice rules living in a generic platform repo—creates coupling that slows every release.
- Platform core: Kubernetes namespaces, NetworkPolicies, cert-manager, GitLab environments, Grafana folders
- Product boundary: own git repo, own database, own subdomain, own on-call runbook for app logic
- Integration surface: documented APIs and webhooks—not shared database tables between products
- Release independence: product A can ship Tuesday while product B stays on last week's image tag
Our Solutions vs platform products article explains the buyer journey: market-facing SaaS on dardev.net/solutions versus the internal pipeline that ships them. Customers buy Hesabi or DarDevLab; they do not buy raw cluster access unless engaged on a DarDev Services scoping call.
How does Authorize–Develop–Deploy–Observe map to products?
Authorize is Workspace—merge rights, namespace-scoped kubeconfig, service accounts. Develop is DarDevCDE and Compose. Deploy is DarDevOps: GitLab CI, immutable images, staging gates, guarded production. Observe ties Prometheus and Grafana to pipeline IDs so on-call correlates deploys with error spikes.
Each product reuses the same pipeline shape documented in our Kubernetes-native product pipeline guide. Differences live in Helm values or Compose overlays: Hesabi needs Tunisia fiscal integrations; DarDevLab needs course progress workers; the mailer stack needs Stalwart SMTP boundaries on send.dardev.net. The pipeline mechanics stay identical.
Subdomains, tenants, and security boundaries
One core stack still needs hard boundaries between public marketing, authenticated product apps, and internal ops tools. We run crm.dardev.net, mail.dardev.net, news.dardev.net, and product domains with separate ingress rules and TLS certificates. CRM data never shares a database with Listmonk subscribers; sync workers connect through explicit APIs. Security boundaries between CRM, mailer, and public site documents the pattern we use on dardev-vps and client engagements.
Multi-tenant identity lives in Workspace; products validate platform-issued JWTs instead of maintaining separate password stores. Organization scoping and audit logs are covered in our identity for multi-tenant platforms and Workspace Authorize step articles.
What we run on the shared core today
DarDev dogfoods this model. DarDevLab serves learners on dardevlab.com. Hesabi handles Tunisian SME invoicing and TTN workflows. The unified mailer stack—Twenty CRM, Listmonk, Stalwart MTA, sync worker—shares Compose for local dev and Kubernetes overlays in production. DarDev News publishes on news.dardev.net. None of these share a single application codebase, but all deploy through GitLab, land on the same cluster class, and export metrics to the same observability stack.
- Git monorepo or multi-repo—platform manifests can live centrally while apps stay separate
- Namespace per product plus staging twin; NetworkPolicies default deny east-west
- Shared Postgres operator or managed RDS per product—never one schema for unrelated domains
- Platform on-call for cluster and ingress; product on-call for business logic regressions
- Quarterly review: retire duplicate cron jobs, unused DNS records, orphaned secrets
Failure modes when sharing one core
- One cluster-admin token used by every CI job—compromise becomes company-wide
- Staging namespace that skips NetworkPolicies present in production
- Shared Redis or Postgres instance with no logical isolation between products
- Platform team becomes bottleneck for every DNS tweak and env var change
- Copy-pasting Helm charts without extracting a thin common library—drift within months
Start with two products and explicit runbooks. Extract shared Helm subcharts only after the third copy-paste of the same ingress pattern. Platform guidance lives on dardev.net/products.
Do all products have to live in one git monorepo?
No. DarDev uses separate application repositories per product. Platform manifests—ingress baselines, monitoring rules, IAM bindings—can centralize in an infra repo while DarDevLab, Hesabi, and internal services keep independent release tags and code review paths.
How is this different from microservices inside one product?
Multi-product architecture spans customer-facing SKUs with different buyers and SLAs. Microservices within Hesabi still belong to one product boundary. The shared core is below that: the Kubernetes cluster, CI, and observability that every SKU inherits.
When should we split clusters instead of namespaces?
Namespace isolation with quotas and RBAC is enough for many MENA scale-ups. Separate clusters add cost but reduce blast radius—common when a regulated client workload cannot share a control plane with internal tools, or when one product needs a different Kubernetes version.
Can Hesabi and DarDevLab share user accounts?
Workspace SSO roadmap work targets unified identity across learning and finance products. Today each product maintains its own signup and billing flows on dardevlab.com and Hesabi respectively; marketing email lists stay separate from product accounts on mail.dardev.net.
What is the first platform investment for a second SaaS product?
Document the Authorize–Develop–Deploy–Observe checklist for product one, then clone the pipeline—not the business logic—for product two. Add staging namespace, scoped CI token, and dashboards before writing feature code. Skipping that clone step is how teams inherit silent production deploy paths.
