Why We’re Building a Family of Products

A product suite can either become a tangled monolith or a coherent system. Here’s how we’re choosing coherence.

Building a product suite is easy to describe and hard to do well.

If you’re not careful, “suite” becomes a single huge application where every new feature increases complexity for every user. We don’t want that.

Our approach is:

  • Separate apps for separate jobs. Taxes are not bookkeeping. Bookkeeping is not invoicing. Different tools should feel different.
  • Shared building blocks. A single UI package, a shared token system, and version alignment across repos.
  • Explicit service boundaries. Services expose metadata endpoints and OpenAPI, and MCP provides discovery and caching.

What does “coherent” mean in practice?

Coherence isn’t one thing. It’s many small alignments:

  • The same typography and spacing scale across apps
  • The same core navigation patterns
  • The same approach to errors and validation
  • The same language for the same concept

That’s why we publish @fluent-terrain/ui as a private package. If the design system isn’t centralized, it will drift.

A note on automation

In a multi-repo ecosystem, drift is inevitable unless you automate the “boring” parts:

  • snapshot OpenAPI schemas
  • track versions
  • regenerate clients when schemas change
  • expose a design-system manifest with ETag and caching

MCP is our integration point for this. It is not a marketing abstraction; it is plumbing that keeps the system maintainable.

The long-term bet

Our bet is that people will prefer tools that stay understandable over time. That means:

  • predictable contracts
  • careful upgrades
  • exports that don’t break
  • documentation that matches reality

If we can keep those promises, the family of products becomes an ecosystem you can rely on.