Three products, one platform.

A portfolio with three products can run them three different ways — three stacks, three on-call rotations, three flavors of the same incident. That is the default. It is also the mistake.

RUBIKLABS chose the opposite. One platform underneath. One rollout engine, one observability surface, one pager. Each product ships its own logic, its own UX, its own domain model — but not its own infrastructure. The platform is a product too, just not one any external customer sees.

The boundary is a rule written down and referred to. Anything truly specific to a domain lives in the product. Anything reusable across domains lives in the platform. In practice, "truly specific" is a much smaller set than it first appears. Rate limiters are not product-specific. Auth is not product-specific. Deploy pipelines, secret rotation, log aggregation — none of these are product-specific.

What is product-specific: the business logic, the UX, the domain model. Everything else goes downstairs.

Enforcement is by review, not by policy. If a PR opens against a product but the change rightfully belongs in the platform, it gets redirected. The cost is slower merges. The payoff is that every new product onboarding onto the platform inherits a stack that is already hardened.

The failure mode that matters: a product decision blocked because a platform change is not moving fast enough. The rule is simple. Platform changes have a self-imposed SLA; when it cannot be met, the product gets an escape hatch — fork the platform module locally, with a written reconciliation plan. It is a safety valve, not a habit.

One platform beneath multiple products is not the only way to run a portfolio. For one of our size, with three products and more on the way, it is by far the cheapest way to carry infrastructure forward.