One Platform, Many Clients: The Deployment Model That Scales

The most underused architecture in consulting work is this: build one platform, deploy it fresh for each client.

Not a multi-tenant SaaS where everyone shares infrastructure. Not a custom project rebuilt from scratch for each engagement. One well-built codebase, deployed as an isolated instance per client, configured through environment variables and a setup flow rather than custom code.

This model doesn't get talked about enough. It should.

The Problem with Custom Projects¶

The traditional consulting model — scope a project, build it, deliver it, move on — has a well-known problem: it doesn't compound. Every engagement starts from scratch. Your accumulated knowledge increases, but your ability to deliver doesn't accelerate proportionally. Billing is capped by hours.

There's also the maintenance tail. Every custom project becomes a unique snowflake that only you fully understand. Clients call you years later with bugs in code you barely remember writing. Your past work is an obligation, not an asset.

The Problem with Pure SaaS¶

The answer most developers reach for is SaaS: build once, sell subscriptions. The economics are theoretically great. The practical reality is that multi-tenant SaaS has its own problems.

Data isolation concerns are legitimate for many business clients. One client's data lives in the same database as another's — that's a harder conversation than it used to be. Customization is constrained by what you're willing to build for everyone. Pricing needs to work across customers with wildly different usage patterns.

And building a true SaaS product — with the authentication, billing, permissions, tenant management, and scalability requirements — is a significant undertaking before you've sold a single seat.

The Per-Client Deployment Model¶

The approach I've moved to for certain product categories sits between these two extremes.

The platform is built once with comprehensive functionality. Clients get their own isolated deployment — their own infrastructure, their own data, their own environment. Configuration happens through variables and a setup flow, not custom code. Updates to the platform flow to all client deployments when ready.

A new client can be fully deployed and operational in 30 minutes, not 30 days.

What this gets you:

Isolation without the SaaS complexity. Each client's data is genuinely separate. There are no cross-tenant concerns, no permissions matrix to manage, no risk of one client seeing another's data.

Customization without divergence. Because customization is configuration-based rather than code-based, clients can have different settings, different content, different workflows — but they're all running the same codebase. Updates to the platform benefit everyone.

Recurring revenue without a custom billing infrastructure. Each deployment has its own cost. The billing model can be simple because the service is simple: a monthly fee for a running instance.

A platform that gets better with every client. Every edge case you solve, every feature you add, every bug you fix benefits the entire client base. Your knowledge compounds into the product.

The Economics Are Different¶

In a custom project model, client #10 costs roughly the same as client #1. Maybe you're slightly faster, but you're still scoping, building, and deploying from scratch.

In the per-client deployment model, client #10 costs a fraction of client #1. You've already solved the hard problems. Deployment is a documented process. Setup is a guided flow. Your marginal cost per client decreases as your client base grows.

This is a fundamentally different relationship with your own work.

When This Works and When It Doesn't¶

This model works best when:

• The core problem is the same across clients, even if the specifics vary
• Clients don't need genuinely unique features — they need different configurations
• You want recurring revenue without building a full SaaS product
• Data isolation matters to your clients

It doesn't work when:

• Every client genuinely needs something architecturally different
• The customization required can't be captured in configuration
• You're building a consumer product where shared infrastructure is a feature, not a liability

For the right category of work, it's the best model I've used.

This is the model behind several of the platforms I've built at WebFace Media. If you're thinking about how to productize your consulting work, I'm happy to talk through whether this approach fits what you're building.