A native, customer-scoped whitelabel portal with data isolation enforced at the database row level. Built for the parent logistics hubs that run hundreds of independent downstream sub-brands.
The parent-hub problem
A high-capacity hub serving hundreds of downstream sub-brands needs each one to see its own inventory, its own orders, and its own invoices, and nothing else. Most software answers that with a separate instance per customer to maintain, or a shared screen with an application-level filter that one bug can leak straight through. Both break at scale. Neither was built for an ecosystem.
Kitstak treats multi-tenancy as the default, with isolation enforced in the database and branding rendered per tenant at runtime, all on one chassis.
The guarantees below are row-level security policies and triggers inside the database. Not application filters that a bug can bypass. Not a separate copy of the app per customer.
Every tenant's data is fenced by row-level security in the database. A sub-brand cannot see another sub-brand's inventory, orders, or invoices, even if the application has a bug. The boundary lives in the database.
Each downstream brand gets a read-only portal showing only their inventory, their orders, their invoices. Joined to the parent by row-level security, so the parent sees everything and each tenant sees only itself.
The portal renders each sub-brand's branding at runtime. One deployment, hundreds of branded experiences. No per-tenant builds, no separate instances to keep patched.
Onboard a new sub-brand as a record, not a migration. No new database, no new server, no per-tenant copy of the app to maintain. The parent's whole network runs on one chassis.
Invoice each sub-brand on its own terms, with statements and payment allocations scoped to that tenant. The parent sees the consolidated roll-up; each brand sees only its own ledger.
Every action across every tenant lands in the same tamper-evident, hash-chained audit log. Forensic-grade across the whole network, queryable by parent or by tenant.
The network effect
When a parent hub adopts Kitstak, every brand it serves comes with it. One enterprise relationship becomes a doorway to hundreds.
A high-capacity logistics hub adopts Kitstak as its operating chassis: receiving, inventory, billing, and accounting in one place.
Every downstream brand the hub serves gets a customer-scoped portal on day one. No contract to negotiate brand-by-brand, no separate system to deploy.
Each sub-brand experiences Kitstak directly through its own branded portal. One enterprise win seeds hundreds of downstream relationships, and some graduate to full accounts of their own.
Questions
Row-level security in the database. Every row is fenced to its tenant and joined to the parent, so a sub-brand can only ever read its own records. The isolation is a database rule, not an application filter that a bug could leak around.
No. One chassis serves every tenant. A new sub-brand is a record, not a new database or server. There is nothing per-tenant to deploy, patch, or migrate.
Yes. The whitelabel portal renders each tenant's branding at runtime from a single deployment. Hundreds of branded experiences, one codebase to maintain.
The parent sees the consolidated view across every tenant it manages. Each sub-brand sees only itself: its inventory, its orders, its invoices, its ledger. The boundary is enforced below the application.
Minutes to a record, not a migration. Because tenants are rows on a shared chassis, adding the next downstream brand does not require new infrastructure. Ask the founder for a walk-through with your numbers.
Running a 3PL operation under the hood? See the 3PL Operations module.
If you are a parent hub managing dozens or hundreds of downstream brands, this is the conversation to have. Talk to the operator who built the multi-tenant chassis.