Shared Platform
One of the most important architectural decisions for a multi-product company is identifying what is shared versus what is product-specific. Building shared components once means all three products inherit the capability — building them three times wastes months and creates divergent implementations that are painful to maintain.
Traxs Group is further along on shared platform than it might appear. Much of the foundation is already built as part of RoundTrip.
What Is Already Shared
These components were built for RoundTrip but are designed in a way that Waypoint and Relay can reuse immediately:
| Component | Status | How Others Use It |
|---|---|---|
| Authentication (Entra External ID) | ✅ Live | One Entra tenant, one login across all products. Add new apps to the same tenant. |
| Email delivery (SendGrid via Command Center API) | ✅ Live | All products call api.traxsgroup.com/v1/contact — no per-product SendGrid setup |
| Notification infrastructure (SignalR pattern) | ✅ Built | Pattern documented — Waypoint/Relay copy the same hub/service architecture |
| Multi-tenant data model | ✅ Built | TenantId scoping pattern is documented and replicable |
| Clean Architecture pattern | ✅ Documented | Every new product uses the same layer structure — any developer can navigate any codebase |
| ADO pipeline pattern | ✅ Built | Copy azure-pipelines.yml from RoundTrip — same build/deploy pattern |
| Cloudflare Pages deployment | ✅ Built | New Pages project per product, same Wrangler deploy command |
| Zero Trust Access (ops.traxsgroup.com) | ✅ Live | Add new internal tools to same Cloudflare Access policy |
| Crisp support platform | ✅ Live | One workspace, route tickets by product tag |
What Needs to Be Built for the Suite
These components don't exist yet and need to be built as part of the Waypoint/Relay build:
Shared Navigation Shell
A top-level navigation that lets users switch between RoundTrip, Waypoint, and Relay without logging in again. The user sees "Switch to Waypoint" in the nav and is taken directly to their Waypoint dashboard.
Implementation approach: Each product remains a separate Cloudflare Pages deployment. The shared nav is a small React component library published as a private npm package that each product imports. It reads the user's subscribed products from the Command Center API and shows/hides the appropriate switcher options.
Shared Client Records
A client created in any Traxs product appears in all products the customer subscribes to. No duplicate data entry.
Implementation approach: Client records live in each product's own database. The Command Center API provides a client sync service — when a client is created in RoundTrip, it publishes an event that Waypoint and Relay subscribe to. This is eventual consistency, not real-time sync.
Cross-Product Data API (Command Center API expansion)
The Command Center API grows to become the integration layer between products:
Current scope:
POST /v1/contact ← contact forms
POST /v1/support ← support requests
GET /health
Future scope (as products launch):
GET /v1/roundtrip/revenue-summary ← Waypoint Executive Dashboard
GET /v1/roundtrip/open-tickets ← Waypoint Dashboard widget
GET /v1/roundtrip/technician-util ← Waypoint resource planning
POST /v1/relay/lead ← RoundTrip → Relay lead creation
POST /v1/clients/sync ← Cross-product client sync
GET /v1/suite/subscription ← Which products does this tenant have?
Shared Subscription Management
Currently RoundTrip has its own Stripe subscription management. As Waypoint and Relay launch, customers need to subscribe to multiple products — ideally from a single billing interface.
Implementation approach: The Command Center API becomes the billing hub. Stripe customer IDs are shared across products. A "Traxs Account" concept holds the customer's subscription to multiple products.
Architecture Decision: Separate Databases Per Product
Decision: Each product gets its own Azure SQL database. Products do not share a database schema.
Rationale:
- Schema changes in one product cannot break another product
- Each product can scale its database independently
- Products can be sold, spun off, or deprecated independently
- Migrations run per-product — no coordination overhead
- Development teams (as they grow) work in independent codebases without stepping on each other
Integration pattern: Products share data through the Command Center API, not through direct database access. RoundTrip never reads from Waypoint's database directly. Waypoint calls RoundTrip's API to get revenue data.
What this means in practice:
Waypoint Executive Dashboard — Revenue Widget:
Waypoint API → GET /v1/roundtrip/revenue-summary
→ Command Center API
→ RoundTrip API (authenticated service-to-service call)
→ Returns revenue summary DTO
→ Waypoint caches for 15 minutes
→ Renders in dashboard
See [ADR-008: Separate Databases Per Product] for full decision record.
Architecture Decision: Shared Entra External ID Tenant
Decision: All three products use the same roundtripapp Entra External ID CIAM tenant. One login works across RoundTrip, Waypoint, and Relay.
Rationale:
- Customers use one set of credentials for the entire Traxs suite
- User provisioning happens once — adding Waypoint access is a role assignment, not a new account
- The b2c-extensions-app custom attributes (like
tid) work across all products - Significant reduction in auth infrastructure complexity
What this means in practice:
- New app registrations are added to the
roundtripapptenant for each product (Waypoint Web Client, Relay Web Client) - The same TenantId links a user to their data across all products
- App roles are product-specific:
Waypoint.Admin,Waypoint.Viewer,Relay.Adminetc.
See [ADR-009: Shared Entra Tenant Across Products] for full decision record.
The Command Center API Growth Path
The Command Center API started as a simple contact form handler. It is growing into the integration backbone of the entire Traxs platform:
Today:
Contact forms → SendGrid
6 months (Waypoint launch):
+ Cross-product data API (RoundTrip revenue → Waypoint dashboard)
+ Client sync service
+ Suite subscription management
12 months (Relay launch):
+ Lead sync (Relay → RoundTrip)
+ Campaign trigger events (RoundTrip job complete → Relay follow-up)
+ Unified billing hub
2028+:
+ AI inference gateway (routes to Anthropic API)
+ Webhook management (products publish events, others subscribe)
+ Platform analytics (cross-product usage data)
This is why the Command Center API needs proper BRD/PRD/SAD documentation — it is not a utility service, it is a strategic platform component.