Build a modular app ecosystem that works as one
Each app should stand alone. Together they should feel like one product.
- Problem statement ID
- AS-06
- Organization
- ArchScale
- Category
- Web Application / Software Architecture / Platform Engineering / SaaS Ecosystem
- Theme
- Modular Monolith, Standalone Applications, Shared Services & Multi-App SaaS Architecture
Background
Architecture, interior design, construction and allied businesses often require several different software applications to manage their day-to-day operations: CRM, Projects, Tasks, Approvals, Documents, Accounts, HR, Vendor Management, Client Portal, Material Library, Site Management, Communication, Calendar, Support and Marketing Automation.
A business may want only one application, such as Projects. Another may want Projects + CRM + Tasks + Accounts. A larger organization may eventually use almost the entire ecosystem.
The applications should feel independent enough that a customer can purchase and use only one of them. At the same time, when several applications are purchased together, they should behave as one connected ecosystem, rather than several unrelated products.
Problem
How should a multi-application SaaS ecosystem be designed so that:
The challenge is to create the correct balance between standalone applications and shared platform services.
Expected solution
Participants should develop a prototype or technical demonstration of a Modular Multi-App SaaS Ecosystem.
Modular Application Architecture
Applications exist as clearly defined modules, each with its own responsibilities, UI, business logic, permissions and data ownership boundaries.
Standalone App Usage
A customer buying only Projects still receives login, organization, users, roles, permissions, notifications, basic contacts, files and audit.
Multi-App Usage
CRM lead won → project created → team assigned → tasks generated → expenses → accounts, experienced as one connected system.
Shared Services
Authentication, users, organizations, roles, permissions, contacts, notifications, files, search, audit logs, comments, activity history, integrations, billing and entitlements.
App Entitlements
The platform knows which applications each customer purchased, and controls navigation, routes, API access, features, permissions and data access accordingly.
One Identity Across Applications
A user has one identity across the ecosystem and does not require separate credentials for every application.
Shared Data Without Duplication
A client appearing in CRM, Projects, Accounts, Documents and the Client Portal remains linked to one common underlying record.
Application Boundaries
Decide what belongs to the shared platform and what belongs inside an application, avoiding one giant uncontrolled database model.
Communication Between Applications
APIs, events, shared services, message queues or domain events — for example CRM OPPORTUNITY_WON → Projects CREATE_PROJECT.
Flexible Deployment Architecture
Begin as a modular monolith and evolve selectively into independent services where required, without creating microservices unnecessarily.
Illustrative example — single app customer
A small architecture studio purchases only Projects.
The system still provides authentication, users, roles, contacts, files, notifications and audit.
The studio can operate Projects successfully without purchasing CRM, Accounts or HR.
Key requirements
The prototype should demonstrate:
- Modular application structure
- A standalone single-app customer
- A multi-app customer where apps work together
- Shared platform services consumed by apps
- App entitlements controlling access
- One identity across applications
- Shared data linked to one underlying record
- At least one cross-app event or integration
- A working demonstration of the architectural principle
Participants do not need to build complex infrastructure, but should demonstrate the architectural principle.
Expected outcome
The architecture should remain understandable and maintainable.