StudiodKP foundation
One operational platform for DKP staff, clients, and vendors.
This reset keeps the existing deployment contract while rebuilding the product around three clear portals, stronger access boundaries, and room for future D2 Next growth.
Admin Portal
DKP staff
Run design, project coordination, manufacturing handoffs, logistics, and client support from one internal command layer.
DKP staff can see across client and vendor workflows because they coordinate the full delivery lifecycle.
Client Portal
Client contacts
Give each client a clear view into project progress, approvals, milestones, and delivery status without exposing vendor or other client data.
Clients only see records for their own organization and approved project contacts.
Vendor Portal
Suppliers and vendors
Coordinate sourcing, procurement, timelines, and required documentation for each vendor relationship without leaking client-side context.
Vendors only see their own sourcing assignments, purchase context, and fulfillment tasks.
Isolation principles
Path-based portals are enough for phase 1. Actual separation still has to happen in APIs, broker calls, and database access rules.
Clients never see other clients.
Vendors never see other vendors.
Client-only and vendor-only data should be shaped separately even on shared projects.
Subdomains later, not required now
We can add portal-specific subdomains later for cleaner entry points. They are a UX and branding choice, not the core security mechanism.
Suggested future pattern: `admin.`, `client.`, and `vendor.` hostnames that route into this same app.
Review access model