01 · Web · 02 Growth

Growth: charge for it.

Paying users and a small team. Managed services, real auth and billing, and a test suite the agent runs before every change.

Users: Hundreds to tens of thousands
Team: Two to five engineers, each with agents

You are here if

Customers notice when something breaks
More than one person merges to main in a week
You have a billing provider and a support inbox
You need to know what changed and why, weeks later

Growth is where most products live longest, and where agent workflows pay off most. The codebase is still one app, but it now needs the guardrails that let several people and their agents change it in parallel: strict types end to end, a schema that generates both the migrations and the validation, feature folders so a change stays in one place, and CI that is fast enough to run on every push.

What changes when you leave this tier: teams, regions or compliance force boundaries you can no longer keep implicit. Until then, resist splitting the app. A well-organised monolith is the most agent-friendly architecture there is.

SEO-driven · content & search

Astro SSR + Postgres on Cloudflare

Thousands of dynamic, indexable pages from a database, rendered at the edge, with islands only where users act.

The stack

Framework: Astro (server output, Cloudflare adapter)
Data: Postgres (Supabase or Neon) via Drizzle
Auth: Supabase Auth or Lucia, only where pages need it
Hosting: Cloudflare Pages / Workers
Also: Tailwind CSSStatic pre-rendering for pages that rarely changeProgrammatic sitemap and JSON-LD per route

AGENTS.md + real projects on STACK IT FAST

Why agents do well here

5/5

Astro's per-route choice between static and server rendering is one line, so the agent can reason about caching without a CDN configuration.
Directory and marketplace pages are templates over rows; the agent handles "one query, one template" patterns reliably.
The rendering model stays HTML-first, which keeps SEO regressions visible in the page source instead of hidden in hydration.

Avoid at this tier

Moving to a full app framework because a few pages need state; use islands.
Client-side data fetching for anything that should be indexed.
Bespoke caching layers before you have measured a slow route.

This is the same Astro you started with, now with a database behind the templates. Pre-render what rarely changes, server-render what depends on data, and keep both in src/pages/ so the agent sees the whole site map.

src/
  pages/          [category]/[slug].astro, sitemap.xml.ts, api/
  db/             schema.ts, migrations/, queries/
  components/     .astro by default; islands in components/islands/
  lib/            seo.ts (meta + JSON-LD helpers), env.ts

First five decisions: server output with per-route prerender, Drizzle queries in one folder, SEO helpers in one file, islands in one folder, and a build-time check that every indexable route has a canonical URL.

SaaS · logged-in product

Next.js + Prisma + Postgres

The well-trodden SaaS monolith, organised by feature, with a schema the agent and the migration tool both read.

The stack

Framework: Next.js App Router
Data: Managed Postgres (Neon, Supabase or RDS) via Prisma
Auth: Auth.js or Clerk
Hosting: Vercel, or a container on Fly / Railway
Also: Tailwind CSS + shadcn/uiStripe Billing with webhook handlers as jobsInngest or a Postgres-backed queue for side effectsPlaywright smoke tests in CI

AGENTS.md + real projects on STACK IT FAST

Why agents do well here

5/5

Prisma's schema file is the most widely documented ORM format in existence; agents generate correct migrations and queries from it with very few misses.
Feature folders keep a billing change inside `features/billing/`, so the agent's diff stays local and reviewable.
Next.js conventions are strong enough that generated code matches the surrounding code, which is what keeps a growing codebase consistent.

Avoid at this tier

Splitting into services because the app "feels big"; split modules, not deployables.
Custom auth; the failure modes are exactly the ones an agent does not see.
Handling webhooks synchronously; every side effect becomes a job.

Still one Next.js app, now with the guardrails a team needs. Prisma owns the schema and migrations, every feature folder owns its actions, components and tests, and a queue owns everything that is not a request.

src/
  app/            (marketing)/, (app)/, api/webhooks/
  features/       auth/, billing/, workspaces/, <feature>/ {actions, components, tests}
  server/         db.ts, queue.ts, email.ts
  prisma/         schema.prisma, migrations/
AGENTS.md         conventions, commands, and the decisions above

First five decisions: feature folders over type folders, Prisma migrations committed and reviewed, a queue for every side effect, Playwright on the three flows that make money, and an AGENTS.md that says all of this.

Tool · utility & internal

SvelteKit + Drizzle + Postgres

Less code per screen than any React stack, with server loaders and form actions the agent can follow top to bottom.

The stack

Framework: SvelteKit
Data: Postgres via Drizzle
Auth: Lucia or Auth.js, only if the tool has users
Hosting: Cloudflare, Vercel, or a container
Also: Tailwind CSSSuperforms + Zod for every formVitest for loaders and actions

AGENTS.md + real projects on STACK IT FAST

Why agents do well here

4/5

Load functions and form actions put data in and data out next to the page, which is the locality that keeps an agent's change in one file.
Svelte components are shorter than the React equivalent, so more of the tool fits in context at once.
Drizzle keeps the schema as readable TypeScript, so the agent sees the data model without opening a database client.

Avoid at this tier

Reaching for a client store when a load function would do.
A separate API when actions already are the API.
React because the team knows it; a tool is small enough to learn on.

A tool at growth has real users and a real database, but still one workflow. SvelteKit’s routes folder is the whole application: each route loads its data, handles its forms, and renders its page in three files sitting together.

src/
  routes/         (app)/<workflow>/+page.svelte, +page.server.ts, +page.test.ts
  lib/server/     db.ts, schema.ts, auth.ts
  lib/components/ small, named primitives
drizzle/          migrations/

First five decisions: server loaders for every read, form actions for every write, Superforms with Zod for validation, Drizzle migrations in the repo, and Vitest on the server files.