AI-Native Architecture & Delivery

The Shift

In one case study discussed during the research, a senior engineer using AI agents produced a production SaaS product in roughly one month with about $11K in model/API spend. Treat this as a case study, not a planning baseline: scope, verification, infrastructure, support, and customer integration can dominate the economics.

This page is the playbook: the architecture patterns, tech stack, contract structure, and economics that can make this model viable.

Architecture: Designed for AI Codegen

Traditional enterprise architecture (hexagonal, onion, deep-abstraction-layered) was designed for human comprehension — so devs could hold the whole system in their head. AI agents don't have that constraint. They work best with flat, explicit, convention-driven codebases where the relationship between files is predictable.

Core Pattern: SaaS Core + Tenant Plugins

apps/
  core/                    # Single codebase, all tenants
    app/
      api/
        auth/
        billing/
        integrations/
      features/
        projects/          # Core feature — every tenant gets it
        time-tracking/     # Core feature
        documents/         # Core feature
    plugins/               # Tenant-specific overrides
      tenant-acme/
        features/
          qa-module/       # Only Acme has this
      tenant-bigco/
        features/
          uat-portal/      # Only BigCo has this

Rule: No forking, no branch-per-tenant. Plugins are just feature-flagged directories. The agent adds a plugin by creating a folder, not by rewriting architecture.

Row-Level Multi-Tenancy (one DB, safe)

Every query includes WHERE tenant_id = current_tenant. No per-client DB, no per-client deployment. RLS is the safety net.

table: projects
  id          uuid
  tenant_id   uuid    ← PK + RLS policy
  name        text
  created_at  timestamp

When clients need custom fields: use JSON columns with tenant-specific schemas (Drizzle supports this natively with jsonb + zoned validation), not separate tables.

Integration Adapter Pattern

Instead of hardcoding integrations (GitHub, GitLab, Bitbucket), define an interface — one file per provider:

interface GitProvider {
  getRepos(tenantId: string): Promise<Repo[]>;
  createPR(repoId: string, title: string, body: string): Promise<PR>;
  getPullRequests(repoId: string): Promise<PR[]>;
}

Adding GitLab is one file, zero changes to core.

Event-Driven Decoupling

user creates ticket
→ event: ticket.created
→ handler: notify.assignee (sync)
→ handler: update.analytics (async)
→ handler: agent.triage (AI agent picks this up)

Events are typed messages (Zod schema). Each handler is a single file with a single responsibility. An agent can write it without understanding the whole system.

BFF (Backend For Frontend) for Tenant Customization

frontend/
  app/
    [tenant]/              ← Dynamic tenant route
    core/                  ← Standard pages

Tenant-specific UI overrides live in app/[tenant]/. Base behavior in app/core/. No conditional rendering spaghetti.

Feature Flags as Product Boundaries

const features = getTenantFeatures(tenantId);
// returns { timeTracking: true, uatPortal: false, docuSign: true }

This is the critical pattern for "build once, sell many times":

• Client #1 pays for: { timeTracking: true, qaModule: true }
• Client #2 pays for: { timeTracking: true, reports: true, api: true }
• Codebase: one. Feature flags = product differentiation without architectural complexity.

Tech Stack

Every choice maximizes what the agent can infer from convention vs. what must be manually specified.

Anti-Patterns (kill AI-assisted velocity)

Delivery Discipline for AI-Assisted Engineering

AI changes the cost of implementation, not the cost of being wrong. Every material change should have:

1. A named owner and explicit acceptance criteria.
2. A small, convention-driven implementation that an agent can reason about locally.
3. Automated checks appropriate to the change.
4. An independent review pass that challenges assumptions and failure modes.
5. Proof of the real artifact: test output, build output, deployment evidence, or a measured result.
6. A short record of what was learned when the implementation or verification failed.

The operating unit is not "agent completed a task." It is verified change with a human accountable for the outcome.

Proportional verification and platform standards

• Establish a clean baseline before calling a failure a regression.
• Run the strongest affordable check; if a full build is resource-prohibitive, use targeted type, content, lint, or test checks and state the limitation explicitly.
• Verify the deployed or installed artifact where relevant, not only the source checkout.
• Store UTC instants at storage and API boundaries. Preserve a separate IANA timezone for recurring wall-clock intent, and recompute scheduled occurrences with DST handling.
• Expose new capabilities through structured, discoverable, schema-defined interfaces where possible. Keep read, propose, approve, and execute actions distinct and idempotent where possible.

Deal Structure: Client-Funded Product Development

The economics only work if you can resell. The deal structure enables it.

The Pitch

"You're paying $140K/yr for tools that don't quite fit. I'll build you a custom platform that does exactly what you need for $70K/yr — and you own the custom parts. I only reuse the engine."

Contract Layers

The Key Rider Clause

"Developer grants Client a non-exclusive, perpetual, worldwide license to the Platform Software. Developer retains all rights not expressly granted, including the right to license, sell, or otherwise distribute the Platform Software to third parties."

This clause is a starting point, not a complete contract. Ownership of pre-existing platform code, foreground/custom work, improvements, client data, open-source dependencies, confidentiality, security, warranties, indemnity, support, and jurisdiction-specific requirements must be defined explicitly and reviewed by qualified counsel.

Do not promise non-exclusive reuse until the IP boundary is clear and the customer has accepted it.

Target Buyer Profile

• Founder-led or SME owner-led companies (not F500 with procurement)
• Someone who can say "yes" to a one-pager, not a 40-page MSA
• Currently overpaying for an incumbent SaaS stack they don't love

Economics

The lower implementation cost can change the economics, but it is not itself a moat. The defensibility must come from customer insight, distribution, reusable product capability, trust, data boundaries, and operational reliability. The contract structure hasn't changed — the economics may make the model viable for smaller buyers.

When It Works vs. When It Doesn't

Related

• Build vs Buy — when to build vs buy
• Engineering — core engineering processes
• Product — positioning and product-market fit
• AI Integration — AI agent orchestration