Architecting a Single-Backend SaaS: Gating features without infrastructure sprawl

When launching a SaaS product, it is tempting to separate user tiers by hosting separate code deployments or spawning dedicated databases. While this provides isolation, it multiplies maintenance overhead by ten.

While building a link-in-bio platform for local vendors, we opted for a single shared backend codebase. Access to premium tools-like customized designs or native payment collections-is feature-gated at the logical level rather than the infrastructure level. This is the breakdown of how to make multi-tenancy boring and clean.

1. Keep the data schema unified

Instead of isolating databases, we used a shared database model where every table includes a tenant ID or user owner ID. A global middleware layer automatically scopes SQL queries to the current authenticated tenant's ID.

This prevents data leaks at the application entrypoint, making it impossible for one vendor to query or modify another vendor's layout or payment credentials.

2. Gating features at the code level

We implemented a lightweight permission-check system. A user profile payload returned from the database includes a 'tier' field (e.g., 'free', 'pro', 'enterprise').

Every time an API route is requested, a middleware check queries the user's tier. If a free user attempts to enable custom CSS styling or configure a payment gateway, the server immediately rejects the request with an HTTP 403 Forbidden status.

function checkFeatureAccess(requiredTier) {
  return (req, res, next) => {
    const userTier = req.user.tier; // e.g. 'free'
    const tiers = { free: 0, pro: 1, enterprise: 2 };
    
    if (tiers[userTier] < tiers[requiredTier]) {
      return res.status(403).json({
        error: 'Feature locked. Upgrade required.'
      });
    }
    next();
  };
}

3. Enforcing limits and usage quotas

Gating isn't just about turning features on or off; it's also about managing quotas. For example, a free user might be limited to 5 links, whereas a pro user gets unlimited links. We implement this by running aggregation counts before inserting records.

By performing a count query in the active write transaction, we guarantee that users cannot bypass their tier limitations by firing concurrent API requests.

4. Handling upgrades and subscription lifecycles

When a subscription event triggers (e.g., user pays via payment gateway), we receive a secure webhook payload on the server. The webhook updates the tenant's tier column inside the users table.

Because the feature gates dynamically read the current database state, the tenant immediately gains access to their new features without needing any code redeployment or container restarts.

5. The benefits of single deployments

• Zero-downtime updates: A single code push updates the application for all users instantly.
• Lower hosting bills: You only pay for one web service and one central database cluster.
• Faster testing: You don't have to test cross-environment syncing or multi-deployment migrations.

A SaaS with 10 infrastructure instances is 10 times harder to keep secure. Keep it singular and gate access at the logical layer.

How do you gate premium features without running separate infrastructure per tier?

Keep one shared database and codebase, scope every query by tenant ID through a global middleware, and check the user's subscription tier at the API-route level rather than deploying separate environments per plan. Webhooks update the tier field on payment events, so upgrades take effect immediately with zero redeploys.