The Per-User Product: How LLMs Are Forcing a New SaaS Architecture

When Every User Can Get a Different Product

I’ve been thinking about where software architecture is headed in the context of LLMs, and I keep arriving at a conclusion that sounds almost absurd: we’re approaching an era where every user could run a slightly different version of your product.

LLMs are accelerating feature development to a pace that fundamentally changes what’s possible. When you can generate, test, and deploy a custom integration in hours instead of weeks, the old model of “one release for everyone” starts to feel like an artificial constraint. We’re not just shipping faster. We’re approaching the ability to ship differently for each customer.

This isn’t theoretical anymore. The tooling exists. The question is whether our architectures, our teams, and our operational models are ready for what comes next.

Why LLMs Change the Release Cadence (and the Blast Radius)

For most of SaaS history, the bottleneck was development time. You had a backlog, you prioritized ruthlessly, and you shipped what you could. Enterprise customers asked for custom features, and you either said no, charged them heavily for professional services, or added it to a roadmap that stretched into next year.

LLMs compress that timeline dramatically. What used to take a developer a week can now take an afternoon with the right prompts and review process. I’ve seen teams go from feature request to production deployment in under 48 hours for functionality that would have previously required a full sprint.

This acceleration creates a new problem: more experiments running simultaneously. When development is slow, you naturally limit how many things you’re testing at once. When it’s fast, the temptation is to try everything. Feature flags that once numbered in the dozens can balloon into hundreds.

The blast radius of each deployment also changes. Traditional feature flags assume a binary state: on or off, maybe with some percentage rollout. But when you can generate custom logic for specific customer segments, you’re no longer toggling features. You’re creating variants.

Consider the operational complexity this introduces. Your monitoring now needs to understand that User A’s dashboard behaves differently than User B’s. Your error tracking needs to correlate issues with specific feature combinations. Your on-call engineers need to know which variant a customer is running before they can even begin debugging.

Think about companies like Notion, which already offer custom integrations and workflows for their enterprise customers. Now imagine that at 100x scale with LLM-generated features. The integration a Fortune 500 company needs isn’t on a roadmap. It’s generated, sandboxed, and deployed within their tenant by end of week.

From Feature Flags to “Feature Portfolios”: The Per-User Deployment Model

Here’s where my thinking gets interesting. If you have a user base of 100,000 users, and some enterprise customers require custom functionality, you could potentially deploy features exclusively for them. Not a toggle. Not a setting. Actual different code paths, different UI components, different business logic.

I’m calling this the per-user deployment model, though “feature portfolios” might be more accurate. Each customer or tenant has their own collection of features, some standard, some customized, some entirely bespoke.

Picture this scenario: An enterprise CRM user says, “I need a button that scrapes LinkedIn and updates this contact field automatically.” In the traditional model, this goes into a backlog, gets deprioritized against broader customer needs, and maybe ships in 18 months if ever. In the per-user deployment model, the LLM generates a sandboxed serverless function and UI component just for that tenant. It’s deployed by Friday. That customer’s version of the product now has functionality nobody else has.

This isn’t science fiction. The architectural patterns exist. Serverless functions, edge computing, and containerization already support tenant-specific deployments. What’s new is the economics: LLMs make it financially viable to generate and maintain these customizations at scale.

The implications extend beyond enterprise customers. You could run personalization experiments where different user segments experience genuinely different product architectures. Not just different copy or button colors, but different features, different workflows, different capabilities.

Some teams are already experimenting with this approach. A user requests a specific automation, the system generates it, deploys it to their account, and monitors its performance. If it works well, maybe it gets promoted to the general product. If it doesn’t, it gets deprecated automatically. The user becomes, in a sense, a co-architect of their own product experience.

This raises a philosophical question about what “the product” even means. When every user runs something slightly different, version numbers become almost meaningless. You’re not on v2.3.1. You’re on a unique rolling hash of generated code that represents your specific feature portfolio.

The New Failure Modes: Combinatorial QA, Drift, and Support Chaos

Now, this brings some very interesting challenges. And by “interesting,” I mean the kind that keep architects up at night.

The testing nightmare is real. How do you QA 100,000 different feature combinations? Traditional testing assumes a finite set of states. When features can combine in arbitrary ways, the test matrix explodes exponentially. You can’t manually verify every path.

The answer, I believe, is that LLMs must generate the test suites as part of the deployment process. When a custom feature is created, the same system generates integration tests, edge case scenarios, and regression checks specific to that tenant’s configuration. Testing becomes a generated artifact, not a manually maintained one.

Observability gaps become critical. Your APM tools assume consistent code paths. When User A’s request hits different functions than User B’s, your flame graphs become meaningless aggregates. You need observability that’s tenant-aware, that can isolate metrics and traces by feature portfolio.

Reproducibility becomes nearly impossible for humans. When a customer reports a bug, your support team’s first question used to be “what version are you on?” Now it’s “what’s your feature hash?” And even with that information, reproducing the issue requires spinning up an environment with that exact combination of features.

This creates what I’d call the maintenance hell argument: if 100,000 users have different code paths, debugging a crash becomes impossible for humans alone. The system requires AI to debug, creating a dependency loop. Your LLM generates the feature, and your LLM helps diagnose when it breaks. There’s no going back to manual debugging at this scale.

Compliance and audit requirements get complicated. How do you demonstrate SOC 2 compliance when the code definition changes per user? Traditional audits assume you can point to a codebase and say “this is what runs.” Per-user deployments require what I’d call “real-time compliance AI,” systems that can verify security properties across all active variants simultaneously.

The support burden multiplies. Your customer success team used to learn one product. Now they’re supporting 100,000 slightly different products. The only viable path forward is LLM-powered support that understands each user’s specific feature set, that can answer questions in the context of that user’s unique configuration.

Security risks scale with customization. Every custom feature is a potential attack surface. When you allow dynamic code generation and deployment per user, you’re trusting that the LLM won’t hallucinate a vulnerability into User X’s custom module. Sandboxing becomes critical. Every generated function needs to run in isolation with minimal permissions, with automated security scanning before deployment.

Architecture Implications: Configuration as Code, Modularity, and Policy-Driven Rollout

So what does a system designed for per-user deployment actually look like? After thinking through the failure modes, I see several architectural building blocks emerging.

First, a Feature Registry becomes essential. This is a central system that tracks every feature variant, its dependencies, which users have it, and its lifecycle status. Think of it as a package manager for your product’s capabilities. When you need to deprecate a feature, you know exactly who’s affected. When you need to understand why two features conflict, you can trace their dependency graphs.

The registry also handles automated deprecation and consolidation. When a custom feature hasn’t been used in 90 days, flag it. When 50 customers have requested similar functionality, consolidate into a standard feature. Without this governance, you’re building toward unmaintainable spaghetti.

Second, strict modularity with contracts. Every feature, whether standard or custom, must implement defined interfaces. The LinkedIn scraper button for that enterprise customer can’t reach into core database tables. It communicates through APIs with versioned contracts. When the core product evolves, the contract tells you which custom features need updates.

This modularity also enables progressive delivery at the feature level. A new custom feature deploys to one user, monitors for errors, then gradually rolls out to similar tenants if successful. The system learns which feature combinations are stable and which create conflicts.

Third, policy-driven guardrails. Not everything should be customizable. Your LLM orchestration layer needs clear policies: what can be generated, what requires human review, what’s off-limits entirely. A request to add a button is probably safe. A request to modify authentication logic requires security review.

The orchestration layer also decides when to generate new code versus modify existing features versus recommend existing solutions. If a customer asks for something that already exists in another tenant’s portfolio, maybe the answer is promotion to standard feature, not generation of a duplicate.

Fourth, versioning shifts from releases to states. Instead of version numbers, you track configuration states. Each tenant has a reproducible definition of their feature portfolio. You can snapshot, diff, and rollback at the tenant level. Your deployment pipeline understands that “production” isn’t one thing. It’s thousands of slightly different things, each with their own state history.

How LLMs Help Manage the Complexity (Not Just Create It)

Here’s the part that gives me hope: the same LLMs creating this complexity can help manage it.

Configuration generation becomes intelligent. When a customer describes what they need, the LLM doesn’t just generate code. It generates the feature definition, the test suite, the monitoring dashboards, and the documentation. The entire deployment artifact is AI-generated, including the observability tooling needed to support it.

Risk scoring becomes automated. Before any custom feature deploys, an LLM evaluates it against known patterns. Does this code access sensitive data? Does it conflict with existing features in this tenant’s portfolio? Does it resemble any previously problematic deployments? The system flags high-risk changes for human review while auto-approving low-risk ones.

Incident triage becomes tenant-aware. When something breaks, the LLM can correlate the error with the specific feature combination, identify similar issues across other tenants, and suggest fixes. Your on-call engineer gets context that would have taken hours to assemble manually.

Documentation stays current automatically. Each tenant’s help center reflects their actual feature set. The LLM generates and updates documentation as features are added or modified. Support tickets get routed to answers that match the customer’s specific configuration.

Test synthesis scales with complexity. As new features deploy, the LLM generates integration tests that verify compatibility with existing features. The test suite grows organically with the product’s complexity, maintained by the same AI that creates the features.

This creates a new operational model where LLMs are embedded throughout the development and support lifecycle. They’re not just coding assistants. They’re the connective tissue that makes per-user deployment manageable.

A New SaaS Operating Model for Individualized Software

What I’m describing is essentially the return of bespoke software, but at scale. We spent decades moving from custom enterprise software to standardized SaaS. Now LLMs might enable a synthesis: the economics of SaaS with the customization of bespoke development.

This requires rethinking almost everything: how we architect systems, how we structure teams, how we think about product management, how we handle support and compliance.

The companies that figure this out will have a significant advantage. They’ll be able to serve enterprise customers with custom needs without the professional services overhead. They’ll run personalization experiments at the feature level, not just the UI level.

I don’t have all the answers yet. But I’m convinced this is where we’re headed. The architecture models we’ve relied on for the past decade assume a shared codebase with toggles. The next decade might assume individualized codebases with shared infrastructure.

If you’re thinking about this too, I’d love to hear how you’re approaching it. What failure modes am I missing? What architectural patterns have you found that work?

Dan Gurgui | A4G
AI Architect

Weekly Architecture Insights: architectureforgrowth.com/newsletter