Client Sites: Individual Repos vs. Multi-Tenant Architecture

The dream of building one master Next.js application to power twenty small-business client sites lasts right until your first client asks for their Git repository.

Every solo developer goes through a phase of wanting to build a custom mini-platform. You see the Vercel Platforms starter kit, you realize you can route custom hostnames dynamically in middleware, and you think: Why deploy twenty distinct websites when I can deploy one codebase and feed it from a central database? You imagine fixing a bug once and watching all twenty client sites update simultaneously. You imagine paying one hosting bill.

Then real-world client work happens.

Handoff friction turns departing clients into hostage situations

When a business owner pays you to build a website, they expect to own what you made. Even if you maintain it on a monthly care plan, circumstances change. A client hires an in-house developer, sells their business, or decides to move to another agency.

If that site lives in an isolated Git repository, handoff takes ten minutes. You transfer the GitHub repository, transfer the hosting project, and hand over the keys. You walk away cleanly with zero lingering obligations.

If that client's site is a tenant row inside your custom multi-tenant engine, handoff is a technical nightmare. You cannot give them access to the repository because it contains proprietary code and layout logic for nineteen other paying clients. You cannot hand over database credentials because their contact entries share tables with everyone else.

You are forced into one of two bad options: spend hours manually carving their pages out into a standalone codebase for free, or tell the client they cannot have their code. The first burns unbillable hours; the second destroys your reputation.

The blast radius of a single bad deploy

When every client runs on a single deployment, their uptime is pooled together.

If you push an update to tweak a styling issue for a local landscaping company and accidentally introduce a regression in your shared edge middleware, you didn't just break the landscaper's site. You broke the bakery, the accounting firm, and the plumbing supplier at the exact same moment.

Small-business sites do not need high-frequency code changes. Most brochure sites sit untouched for weeks or months after launch. With isolated repositories, a site running stable code continues to run untouched. You do not risk breaking a client's lead generation form just because you were updating dependencies for someone else.

Isolating repos also preserves clean environment boundaries. If you manage credentials using proper Next.js environment variable hygiene, each client project holds only its own API tokens for form processors or map embeds. A compromised key or misconfigured route in one project cannot expose another client's configuration.

Shared databases create custom-feature quicksand

Multi-tenant setups assume every tenant wants roughly the same thing with minor branding tweaks. Small businesses never stay inside that box for long.

The moment you launch, the accountant wants a custom financial calculator widget. The restaurant wants an interactive weekly specials board pulling from an airtable feed. The gym wants custom member login redirects.

In a standalone repository, you add the custom component, wire up whatever library they need, and move on.

In a multi-tenant setup, every unique request requires a architectural decision. Do you add conditional logic to your shared layout? Do you create another boolean column in your database schema? Over twelve months, your clean multi-tenant engine degrades into an unreadable tangle of feature flags and tenant-specific branching. You spend more time making sure Client A's custom widget doesn't render on Client B's homepage than you spent building the feature itself.

The client's credit card should pay the infrastructure bill

Pooling everyone onto a single hosting account looks like a cost-saver on paper. In practice, it turns you into an unpaid utility company.

If you host everyone on one shared account, you absorb the risk of traffic spikes, bot attacks, and database connection limits. When an image heavy post goes viral or a scraper hammers a client's catalog, your shared database pool can choke, dragging down other tenants. Figuring out which client consumed what percentage of your monthly bandwidth or serverless compute is tedious math nobody wants to do.

With isolated projects, cost allocation is dead simple. You set up the hosting project under the client's own team account or invite them as the billing owner. If their site gets hammered with traffic, their card handles the tier upgrade. When setting up custom domains and configuring DNS records, point their records directly to their dedicated project.

Treating hosting as a passthrough expense keeps your books simple and separates platform costs from your ongoing website maintenance services.

The honest trade-off: maintenance repetition

Isolated repositories have an undeniable downside: updating dependencies is repetitive.

When a major Next.js release arrives or a security patch drops for a common package, you do not update one codebase. You have to bump dependencies across fifteen different repositories, test them individually, and deploy fifteen times. It feels inefficient, and your inner engineer will rebel against the repetition.

That repetition, however, is a deliberate safety valve. It allows you to upgrade clients gradually on your own schedule. You can test new framework versions on low-risk sites first. If a breaking change appears, it affects exactly one site while the rest remain stable.

The solo builder rule of thumb

Multi-tenant architectures make sense when you are building a product (a true SaaS where users sign up for a fixed software service).

When you are building custom websites for distinct businesses, isolated repositories beat multi-tenancy every time:

1. One Git repo per client, cleanly named and isolated.
2. One dedicated deployment per client, connected to their own domain.
3. A repeatable starter template so you start from a battle-tested foundation without sharing a runtime.

Accepting the slight chore of updating individual repositories buys you total architectural freedom, frictionless client handoffs, and peaceful nights where one broken deployment cannot ruin twenty businesses at once.