Skip to main content

ADR-010: Module-Based Product Architecture (Traxs One Suite)

Date: 2026-07-07
Status: Accepted
Deciders: Pete Carroll

Context​

As Traxs Group expands to three products, a decision must be made about how those products are positioned and architected — as three separate standalone products, or as modules of a single unified platform.

This decision affects pricing, packaging, user experience, marketing positioning, and the long-term competitive moat of the company.

Decision​

Traxs Group products are architected and marketed as modules of the Traxs One Suite — a unified business operating platform — rather than as three entirely separate standalone products.

Each module is:

  • Independently purchasable — a customer can subscribe to RoundTrip only, Waypoint only, or Relay only
  • Independently deployable — each module is its own codebase, its own deployment, its own database
  • Deeply integrated — data flows between modules automatically when a customer subscribes to multiple
  • Part of a unified experience — shared login, shared navigation shell, shared client records
Traxs One Suite
├── Relay Module          — Revenue Operating System
├── RoundTrip Module      — Service Delivery Operating System  
└── Waypoint Module       — Business Operating System

Alternatives Considered​

Option A — Three Entirely Separate Products​

RoundTrip, Waypoint, and Relay are marketed and built as completely independent products with separate branding, separate logins, and no integration.

Rejected because:

  • Loses the compounding competitive advantage of the integrated suite
  • Each product must compete on its own against well-funded incumbents (HubSpot, ServiceTitan, NetSuite)
  • No cross-sell engine — acquiring customers for each product starts from zero
  • Three separate brands to build and market
  • The most compelling pitch ("one platform for your whole business") is impossible

Option B — One Monolithic Product​

All features (RoundTrip, Waypoint, Relay) live in a single codebase and are sold as one product.

Rejected because:

  • Scope is unmanageable for a solo founder
  • Customers who only need field service management don't want to pay for CRM features
  • Releases are blocked until all modules are ready
  • Impossible to price appropriately for different customer needs
  • A single product can't serve both "HVAC company with 3 techs" and "professional services firm"

Option C — Module-Based Suite (selected)​

Independently deployable products with deep integration and unified experience.

Selected because:

  • Each module can be built and shipped independently — RoundTrip ships without waiting for Waypoint
  • Customers pay for what they need — lower barrier to entry
  • Cross-sell is built into the product — "you're already on RoundTrip, add Waypoint for $79/month"
  • The integrated suite story is the long-term competitive moat — no single-product competitor can match it at the price point
  • Each new module is a marketing moment — a reason to announce and re-engage customers
  • This is the model used by successful SaaS ecosystems (Zoho, HubSpot, Atlassian)

The Integration Architecture​

Shared Components​

ComponentImplementation
AuthenticationShared Entra External ID tenant (see ADR-009)
Navigation shellShared React component library (private npm package)
Client recordsEvent-driven sync via Command Center API
BillingStripe customer shared across products — Command Center API as billing hub
SupportSingle Crisp workspace with product tags for routing

Data Flow Between Modules​

Relay converts a lead → publishes LeadConverted event
  → Command Center API routes to RoundTrip
  → RoundTrip creates Client record
  → RoundTrip returns clientId to Relay
  → Relay links opportunity to RoundTrip client

RoundTrip completes a job → publishes JobCompleted event  
  → Command Center API routes to Waypoint
  → Waypoint updates revenue snapshot
  → Command Center API routes to Relay
  → Relay triggers post-service follow-up campaign

Subscription Model​

Starter customers:       One module only
Growth customers:        Two modules (15% suite discount)
Full Suite customers:    All three modules (20% suite discount)

Consequences​

What becomes easier:

  • Shipping incrementally — each module ships when ready, not blocked by others
  • Pricing flexibility — customers start with one module and expand
  • Marketing — each new module release and each new integration is a story to tell
  • Competitive positioning — the integrated suite story is unique and defensible
  • Cross-sell revenue — existing customers are the warmest leads for new modules

What becomes harder:

  • The shared navigation shell must be maintained as a separate library
  • Integration events between modules add complexity — the Command Center API grows significantly
  • Testing cross-module integrations requires all products to be running
  • Versioning the integration API requires care — breaking changes affect multiple products

The release pattern: Every module follows the same versioning pattern:

v1 — Core (ship fast, get customers, validate)
v2 — Operations (build on validated foundation with customer feedback)
v3 — Intelligence (AI and analytics on top of rich data)

Each v-level release is a marketing moment. "Waypoint v2 — now with Project Portfolio Management and Workflow Automation" is a reason to post, announce, and re-engage.