Share the business context without sharing all access
A studio site and its internal workspace can use a common service catalogue and enquiry model. That helps a public request carry useful context into operations. It does not mean public visitors should have access to CRM tables.
The M48 platform is an evolving internal product. Its public experience includes multilingual services, case pages, a brief and interactive visual elements. Backend and operational features require their own deployment and acceptance checks; the portfolio entry does not imply that every live workflow has already passed them.
Reuse stable definitions
A central service registry can supply homepage cards, service routes, enquiry choices and related-case links. A central company configuration can supply public email, WhatsApp and Telegram references. This reduces contradictory facts across interfaces and metadata.
Keep content and operational state distinct. Published service descriptions can be public. Customer briefs, messages and staff roles require authenticated access and server-enforced permissions.
| Boundary | Useful shared element | Information to keep restricted |
|---|---|---|
| Website → lead | Service, source page and language | Staff-only qualification notes |
| Brief → project | Confirmed requirements and references | Other clients’ records |
| CRM → notification | Record identifier and minimal alert | Unnecessary private message content |
| Blog → static site | Published article snapshot | Drafts and editorial notes |
Test each handoff independently
A complete form receipt requires persistence, not only an interface animation. A notification requires delivery evidence. An admin role requires a server check. A static article requires its body in generated HTML. Keep these checks visible in the release record.
Supabase’s row-level security documentation explains database row policies; object grants and privileged server access also need explicit review. A hidden menu is not a database security boundary.
Release in verifiable increments
Preserve the approved visual direction while completing one end-to-end workflow at a time. Record what is implemented, what has been deployed and what has passed live acceptance separately. This is a more useful engineering case than claiming a finished ecosystem from screenshots alone.
Explore business systems and web applications as connected surfaces with distinct trust boundaries.
A practical question
How do we prove that the website-to-CRM handoff works?
Submit a labelled request from the deployed public page, inspect its durable CRM receipt and check the authorised notification. Keep the saved lead and notification evidence distinct from a successful build.