Reusable platforms: the engine behind 5 different verticals (and how to design them right)

When you’re building your second or third product in the same family, you hit a inflection point. You started with a CRM for event venues. Then came a real estate platform that needed something similar but tailored. Then an auto shop system. Then a clinic. Each seemed "completely different," yet 70% of the code was identical.

That’s when reusable platform thinking becomes relevant. And there’s a right way to do it—and a wrong way. Let’s start with the wrong way, since it’s the most common.

The wrong approach: early abstraction overload

The classic mistake is generalizing too soon. After the first product launch, someone says, "This could work for any business." You spend months building an abstracted, infinitely configurable codebase—one meant to handle everything. And inevitably, one of two things happens:

• The platform becomes so configurable that using it for a new vertical feels like learning a new programming language.

• The "configurations" cover 80% of use cases, but the remaining 20% requires breaking the platform core—which, in turn, breaks every other client relying on it.

The rule: abstract after you’ve built at least three real-world products, not before. The first product solves a specific problem. The second teaches you what’s actually common. The third confirms the pattern. Anything abstracted earlier is just speculation.

The winning pattern: core engine + vertical adapters

A well-designed reusable platform has two layers:

1. Core Engine: the shared foundation across all verticals. Think state pipelines with transitions, versioned proposals, contact management, calendars, payments, automated notifications, audit trails, multi-user role management, and isolated multi-tenancy.

2. Vertical Adapter: the business-specific layer. This includes state definitions (e.g., a venue uses "scheduled visit", an auto shop uses "car received"), transition rules (e.g., "no invoice without approved estimate"), custom fields, and vertical-specific reports.

The core engine should be opinionated about the shared structure (to avoid breaking across verticals) and flexible in vertical configuration (to accommodate differences).

Real-world example: La Carolina

La Carolina began as a CRM for event venues. The engine we built there now powers:

• Catering platforms: same order/proposal/event/payment pipeline.

• Real estate leasing: same structure, but states change (e.g., "visit", "offer", "contract").

• Professional services with proposals: accounting firms, agencies, consulting firms.

• B2B events: trade shows, conferences, training programs.

The engine already handles configurable states, versioned proposals, Google Calendar sync, partial payments with deposits, and automatic notifications based on state transitions. Adapting to a new vertical takes weeks—not months.

Multi-tenancy: the architectural make-or-break decision

If you’re selling the platform to multiple clients (not just different departments within the same company), you need true data isolation. That’s where multi-tenancy comes in. There are three main approaches:

1. Database per tenant: A full database per client. Maximum isolation, maximum cost and complexity. Best for highly regulated industries (healthcare, finance) with a small number of large clients.

2. Schema per tenant: One database, schemas separated per client. A middle ground: decent isolation, reasonable costs, but more operational complexity than a single schema.

3. Shared schema with tenant_id: One database, one schema, one column to identify clients. Cheaper and simpler, but isolation must be enforced at the database level—not just in code. This is where Row Level Security (RLS) becomes critical.

For B2B SaaS serving many mid-sized clients, shared schema + RLS offers the best cost-to-value ratio. But remember: isolation cannot rely solely on application code—it must be baked into the database itself.

The product-plus-platform trade-off

When building this way, you’ll attract two types of customers:

• Those who use the standardized vertical product (lower cost, limited configuration).
• Those who need deep customizations (higher cost, full platform access).

The mistake? Treating both the same. The solution: separate offerings. Offer a standardized SaaS plan for the first group, and custom implementation projects + licenses for the second. Different pricing, different contracts, different teams serving each.

When not to build a reusable platform

Not every product benefits from being a platform. Don’t go down this road if:

• Each client is wildly different: If "configurations" end up making up 80% of the work per client, you’re not building a platform—you’re disguising custom products.

• Your market is tiny: If you’ll only ever have three clients, a platform is overkill. Build three tailored products instead.

• Support and implementation are the real products: If your value comes from consulting wrapped around software, you’re not a SaaS platform—you’re a services firm.

Bottom line

Reusable platforms are beautiful when done right—and a nightmare when done wrong. The difference lies in waiting for at least three real verticals before abstracting, clearly separating the core engine from vertical adapters, and building multi-tenancy in from day one with database-level security.

If you’re considering building your own reusable engine—or already sell a vertical product and want to expand into similar verticals—reach out to us. We’ll help you design the architecture before writing code you’ll later regret undoing.

---

By Esteban Aleart, Founder & Lead Engineer at Pair Programming.