Three Portals, One Truth: Designing Multi-Application Ecosystems
When clients, specialists, and administrators all need different interfaces but share the same underlying data, the architecture has to serve three distinct user experiences without three separate backends. Getting this wrong means data drift, permission gaps, and triple the maintenance burden.
Why this matters for your business: When clients, staff, and administrators all need different interfaces but share the same data, the wrong architecture triples your maintenance cost. This shared-backend approach gives each audience exactly what they need — from a single system of record.
Why do three user types break one interface?
A multi-service firm’s intake platform serves three fundamentally different users. A client needs a guided, low-friction experience that collects sensitive information without overwhelming them. A specialist needs a workflow-oriented interface for reviewing cases, capturing consent, scheduling consultations, and managing engagement documents. An administrator needs a command center for configuring intake logic, monitoring system health, managing tokens, and verifying CRM synchronization.
These aren’t three views of the same screen — they’re three applications with different interaction patterns, different permission models, and different performance requirements. But they operate on the same data: the same intake records, the same case scores, the same CRM sync status.
The temptation is to build three independent applications that each maintain their own data. The result is inevitable: data drift between systems, permission inconsistencies, and triple the surface area for bugs. The alternative — one monolithic application with role-based UI switching — creates a codebase where every change risks breaking an interface it wasn’t intended for. (The business version of this story: the multi-stakeholder intake problem.)
How does one backend serve three frontends?
We chose a middle path: a single backend with row-level security policies, shared edge functions, and one database schema — paired with independent frontend applications, each purpose-built for its audience.
The client portal is optimized for completion rate. Single-question focus mode, celebration effects on section completion, progress persistence across sessions, contextual help panels, and voice input. Every UX decision is tuned to reduce abandonment. An intake form that’s technically complete but abandoned partway is a failure.
The specialist portal is optimized for workflow throughput. Case documents arrive pre-organized. Consent capture is digital with audit logging. Consultation scheduling includes availability management. Engagement documents sync to the firm’s document management system. The specialist moves through cases in a linear flow without context-switching between tools.
The admin portal is optimized for operational control. Blueprint configuration for intake logic. Scoring matrix management for case routing. System health dashboards for CRM sync status. Token management for API credentials. Every operational question — 'Is the CRM sync working? How many intakes completed today? Which scoring rules are active?' — is answerable from one screen. The rules those screens edit are Blueprints — business logic as data, not code.
What security layer makes sharing safe?
Three portals sharing one database creates a permission surface that must be airtight. A client must never see another client’s intake data. A specialist must only see cases assigned to their service line. An administrator must have broad access for configuration but audited access for sensitive records.
Row-level security at the database level — not the application level — enforces these boundaries. Application-level access checks fail at 2 AM when a tired developer writes a query that skips the middleware. Database-level policies never sleep. Policies evaluate the authenticated user’s role and scope on every query. Even if a frontend bug exposes a query it shouldn’t, the database rejects unauthorized access. The security model is structural, not dependent on every frontend correctly implementing access checks.
Shared edge functions serve all three portals but enforce role-based access at the function level. The CRM sync function accepts requests from all portals but validates that the requesting user has permission for the specific operation — a client can trigger their own intake sync, but only an admin can trigger a bulk re-sync. One function, one security policy, three consuming applications.
Note: Row-level security at the database level is non-negotiable in multi-portal architectures. Application-level access checks are a convenience. Database-level policies are a guarantee. Build both, but trust only the database.
App Development
Focused applications, fixed scope, handed over clean — code, docs, infra all yours.
See how engagements workClient Intake Platform — Multi-Portal Intake System
Guided intake wizard, token-based reviewer portal, and an admin console with rules staff edit themselves — no deploy needed. Intake went from days to under 15 minutes, with zero lost forms.
Want to see more patterns from production?
See the past work where these patterns run in production, or browse the rest of the library.