One platform, many products

Most software shops build their products as separate islands. Separate codebases, separate auth, separate billing, separate permissions, separate real-time pipelines. Each product is treated as its own startup-from-scratch.

That’s a strategy. It’s just a really expensive one.

What “one platform, many products” actually means

Underneath everything I run is a single Laravel + React stack. Auth, billing, permissions, real-time updates, integrations, the dashboard that shows what the system is doing — all of it lives at the platform layer, written once.

A “product” is a feature surface on top of the platform. Beacon’s monitoring system. Beacon’s WordPress plugin. Beacon’s browser extension. Beacon’s mobile and desktop apps. The Digital Royalty client dashboard. They all share the underlying scaffolding.

Adding a sixth product to that list isn’t building another app from scratch. It’s adding a feature module to a system that already knows how to authenticate users, charge them, route real-time events, send alerts, and track usage.

Why this isn’t normal

Most agencies — and most product companies — don’t do this. Two reasons:

They start with the product, not the platform. The first product gets built fast. Auth is “whatever’s quickest.” Billing is whatever Stripe code the developer wrote on day one. Permissions are hard-coded. When the second product comes along, the first product’s plumbing isn’t reusable, so the second product gets its own copy. Now there are two of everything to maintain.

Platforms feel slower. Building the platform first looks like overhead — “we could ship faster if we just built the product.” That’s true for product one. By product three, you’ve built three of everything and the team can’t keep up with maintenance, let alone new features.

The cost-benefit, plainly

The first product on a real platform is more expensive than building it standalone. Maybe 20-30% more, depending on how much you do up front.

The second product is significantly cheaper, because the auth, billing, permissions, and real-time infrastructure already exists. Maybe 40% the cost of building it standalone.

The third product is much cheaper. By that point the platform has been hardened by two products’ worth of real usage; you’re mostly writing the new product surface and a few new integrations.

By the fifth or sixth product, new products start to feel almost free — not because the work is trivial, but because the cost is concentrated where the cost is genuinely new. Actual new features. Not re-implementing user accounts.

When this matters

This isn’t a strategy for one-shot software. If you’re shipping a single product and you’re sure that’s all you’ll ever ship, build the product directly. The platform-first overhead is wasted.

It matters when:

• You’re building a SaaS that’s going to grow horizontally (multiple modules, multiple use cases inside one company).
• You’re an agency that wants to release product alongside services without doubling the maintenance bill.
• You expect the system to outlive any one product.

The thread

This is the same instinct that runs through the rest of the work I do. Encode the parts that repeat. Separate the parts that change from the parts that don’t. Spend the expensive engineering effort once, on the foundation, so that everything built on top inherits it.

Most “agency products” fail not because the product idea was bad, but because the agency couldn’t afford to maintain them alongside client work. The platform fixes that — not by reducing the work, but by making the unit cost of the work scale with what’s genuinely new about each product.

If your business has more than one piece of software running at any given time and they don’t share infrastructure, that’s where the maintenance cost is going to bite next.