Relativo: Building a Three-Tier Multi-Tenant CRM/ERP From First Principles

Relativo is our flagship CRM and ERP product. It's been in active development since the earliest days of Talivio, and it's the product that shaped most of our thinking about how to build multi-tenant SaaS at the architecture level. The core design decision — the one that makes Relativo different from a typical CRM — is the three-tier hierarchy.

Three Tiers, Three Completely Different Users

Most CRM software has two tiers: the vendor (the software company) and the customer (the business using the software). Relativo has three: the Talivio platform itself, vendor companies that deploy Relativo as part of their own service offering, and the end customers of those vendor companies.

In practice, this means a business can use Relativo to manage their own customer relationships, while simultaneously offering their clients access to a white-labeled version of Relativo under their own subdomain. Each vendor gets a dedicated subdomain — {vendor}.crm.talivio.com — and their customer companies operate in a completely isolated data environment within that vendor's instance.

This architecture required solving problems that don't exist in standard two-tier SaaS. Role validation can't just check whether a user has the right permission — it has to check whether the user is in the right company type. A user with admin role in a vendor company must never be able to access data in a customer company, even if both exist under the same vendor. Every controller validates both the role and the company type before touching data.

The Service Layer Discipline

Relativo's controllers are deliberately thin — typically 10 to 20 lines. All business logic lives in service classes: ProjectService, TaskService, InvoiceService, AnalyticsService, and about a dozen others. This isn't just a style preference — it's enforced through code review and CI checks. The services themselves can be complex (some run to several hundred lines), but the complexity is contained and testable independently of HTTP concerns.

Form request validation classes handle all input sanitisation before it reaches the controller. The controller receives already-validated data, calls the relevant service method, and returns a response. That's the entire pattern.

Three Stripe Integration Paths

Relativo has three completely separate Stripe integration paths, each serving a different part of the three-tier model. Talivio bills vendor companies for their Relativo subscriptions — this uses Laravel Cashier and standard Stripe subscription management. Vendor companies can bill their own end customers — this uses the vendor's own Stripe account, with credentials stored encrypted in the vendor settings table. And for vendors migrating from legacy systems, there's a data import path that reads historical Stripe data and maps it into Relativo's data model.

Each path uses a different Stripe client instance. The vendor billing path constructs its Stripe client dynamically at runtime using the decrypted vendor API key, completely separate from the platform-level Cashier integration. This separation is important — it means the platform never has meaningful access to a vendor's customer billing data.

Communications Layer

Relativo integrates with four notification channels: email (with vendor SMTP configuration support, falling back to platform SMTP for lower-tier plans), SMS via Twilio, WhatsApp via the WhatsApp Business API, and push notifications via Firebase Cloud Messaging. Template management is built into the admin interface, with variable substitution and preview rendering.

The AI layer — Google Gemini — is used for analytics insights and a code analysis service that can review workflow configurations and suggest improvements. This is advisory rather than automated: Gemini's output is surfaced to users as a suggestion, not acted on directly.

The Flutter App

The Relativo mobile app is built in Flutter with the Provider state management pattern. It covers the full CRM workflow: project and task management, customer records, lead tracking, invoice creation, and notification management. All API calls go through a Dio HTTP client with logging middleware, and authentication tokens are stored in flutter_secure_storage rather than shared preferences.

The UI is built on a centralized AppTheme class that defines all colors, spacing, border radii, and typography. No hardcoded styling appears anywhere in the component tree — every visual property traces back to a named constant in AppTheme. This discipline makes UI consistency across a 50+ screen app maintainable without a design system tool.

Status

Relativo is live at crm.talivio.com. It's the product with the longest development history in our portfolio and the one where most of our multi-tenant architecture patterns were first worked out. Features we've refined in Relativo — the service layer pattern, the encrypted credentials approach, the multi-channel notification system — have been carried forward into subsequent products.