Building SaaS with AI? These 5 Architecture Decisions Can't Be Made by AI

AI coding agents have turned "build a SaaS over the weekend" from a joke into reality: the app runs, it demos, and you can even sell it to your first customer. But growth is never a linear function of lines of code. When a B2B invoicing tool lands its second customer—say the first is a bakery and the second is a plumbing company—a question AI won't answer for you lands on the table: where does each customer's data live? One shared app and one shared database, or a full copy for each?

According to a systematic analysis of SaaS building on a YouTube tech channel, there are five such decisions, and together they determine whether growth is "controlled expansion" or "rewrite from scratch." Below, we break them down one by one using the invoicing SaaS case from the video.

Decision 1: Tenant Model—Silo or Pool

In SaaS terms, each customer company is a tenant, with its own users and business data. The first fork in the road: give each new customer an independent app and database (Silo model), or let all tenants share a single app and database (Pool model).

The silo model offers excellent isolation, at the cost of one more environment to pay for and maintain per customer. The pool model is far cheaper to run and is where most SaaS products start. But sharing has a price: the bakery's invoices and the plumbing company's invoices sit in the same tables, and the only thing stopping the bakery from seeing the plumber's data is the code itself. One query that forgets to filter by customer, and the bakery owner is looking at someone else's bills.

Decision 2: Isolation—Don't Rely on Code Discipline Alone

This is exactly what the second decision addresses. The approach: every data row belonging to a tenant carries a tenant ID; after login, the token states who you are and which tenant you're currently working under; all tenant data queries are scoped to that tenant.

More critical is the database layer: row-level security. Code forgets; the database doesn't. When configured correctly, even if a query omits the filter, row-level security still holds the isolation boundary. This is the classic move of shifting "discipline" from the developer's brain into the infrastructure.

Row-Level Security (RLS) is an access control mechanism provided by databases: administrators define policies on tables specifying which rows are visible to the current execution context. In PostgreSQL, it is typically used with current_setting('app.tenant_id') or session variables—the application sets the current tenant ID before each query, and the database automatically appends the filter to all queries. RLS's advantage is that it is declarative and centrally managed; even if application code has gaps or injection risks, it cannot cross the policy boundary. Implementation notes: when reusing database connections from a pool, session variables must be reset to avoid tenant context bleed; superusers and table owners may bypass RLS by default, so FORCE ROW LEVEL SECURITY must be explicitly enabled.

Decision 3: Scaling—Beyond Servers, There's the "Noisy Neighbor"

Isolation is stable, word spreads, and the customer count reaches one hundred. One Monday at 9 a.m., a large number of customers open the app simultaneously, a single server can't keep up, and customers start complaining about slowness.

The usual scaling approach is to add servers behind a load balancer, or migrate to cloud functions that auto-scale per request. Either way, requests may land on any instance, so session state and uploaded files must go into shared storage. Pressure then shifts to the database: connection pooling limits the number of connections reaching the database, and caching absorbs repeated reads.

The problem doesn't end there. Ten minutes later, a printing company imports eight years of invoices in one go—two million rows—and the entire app slows down for everyone. This is the "noisy neighbor" problem, and simply adding servers won't solve it. Setting per-tenant limits on requests, storage, and concurrent heavy jobs based on the pricing tier is how SaaS keeps customers from hurting each other.

"Noisy Neighbor" is a classic anti-pattern in multi-tenant architectures: one tenant's burst load (mass imports, complex queries, high-frequency API calls) exhausts shared resources and degrades service quality for other tenants. In the pool model, this impact is especially direct because all tenants share the same database connection pool, CPU, and I/O bandwidth. Mitigation typically includes: per-tenant rate limiting and quotas; separate queues with limited concurrency for background batch jobs; resource groups or workload management at the database layer (e.g., PostgreSQL's statement_timeout, per-tenant max connections in the connection pool); and migrating high-value tenants to dedicated instances. Metering data is the prerequisite for identifying noisy neighbors.

Decision 4: Control Plane—Automate the Tenant Lifecycle

Customers are added daily. Who provisions them? Every signup needs an account, a plan, settings, and a first admin user; then there are upgrades, downgrades, cancellations, and customers who stop paying. Doing it all by hand, the founder will soon be overwhelmed.

The fourth decision is to split the system into two layers: the invoicing app itself is the application plane, serving customers; the control plane manages the tenants themselves—provisioning, plans, the entire lifecycle. When a new customer signs up, they automatically get a working tenant with no manual configuration.

The separation of control plane and application plane (data plane) is one of the core patterns of cloud-native architecture. The control plane is responsible for "managing the resources themselves"—tenant creation, configuration, plan changes, isolated environment provisioning, regional routing, billing association, and so on; the application plane is responsible for "handling business requests"—invoice CRUD, file uploads, AI analysis, etc. The benefits of separation: the control plane can evolve and scale independently, fault isolation is clearer, and tenants can be managed uniformly across regions and environments. In implementation, the control plane typically maintains a tenant registry recording each tenant's routing information (such as database connection strings, region, identity provider configuration), and the application plane queries this registry at the request entry point to perform routing.

Decision 5: Metering—Know Who's Spending the Money

At month's end, the cloud bill is 30% higher than last month. Which customer caused it? Without per-tenant data, no one can answer. The fifth decision is metering: tag all cost-driving usage—API calls, storage, background jobs—with the tenant, feed it into usage-based billing, and identify customers whose "cost to serve exceeds what they pay."

Once you add AI capabilities to the app—say an assistant or automated invoice analysis—metering becomes even more critical. Every answer consumes tokens, and without metering and limits, one heavy user can eat the entire plan's gross margin.

Usage metering and billing are two different layers: metering is collecting and aggregating each tenant's resource consumption data (API call counts, storage bytes, background job execution time, AI token counts, etc.), while billing converts usage into invoice amounts based on the pricing model. In AI feature scenarios, token metering is especially critical because LLM invocation costs are directly tied to input and output token counts, and the cost per request can be far higher than traditional APIs. Without metering, flat-rate pricing is easily eroded by heavy users. In practice, metering data should be tagged with tenant ID, timestamp, and resource type, written to an independent metering event stream, and then processed through aggregation pipelines to generate bills and cost analysis reports.

The Compound Interest of Five Decisions: No Rewrite When the Big Customer Arrives

A year later, the biggest project comes knocking: a large enterprise customer whose conditions are an isolated environment, data stored in Canada, and login through their own identity provider.

This is the moment the five decisions pay off. Give them a silo in the Canadian region, connect their identity provider, and everyone else stays in the existing pool. The application already routes each tenant to the corresponding environment, the control plane can provision new environments, and metering continues to track usage per tenant. The result is a new deployment, not a rewrite.

Tenant model, isolation, scaling, control plane, metering—AI can write most of the code for these, but the five decisions still belong to humans. And the cost of making them on day one is far lower than the cost of retrofitting them later.

One-line Summary

AI can write SaaS code, but five architecture decisions—tenant model, isolation, scaling, control plane, and metering—must be made by humans.

Paragraph Summary

The article uses an AI coding agent building a B2B invoicing SaaS as its backdrop, arguing that code generation capability is not the same as growth capability. When the second customer arrives, five architecture decisions determine whether the product can scale: whether the tenant model is silo or pool; isolation requiring both tenant IDs and database row-level security; scaling that must handle server bottlenecks and noisy neighbors with per-plan limits; a control plane that automates the tenant lifecycle and is separated from the application plane; and metering that tracks usage per tenant to support billing and cost analysis. Making these five decisions on day one is cheapest, while retrofitting them later is expensive; when a big customer demands isolation, region, and identity provider requirements, early decisions turn the response into a new deployment rather than a rewrite.