01 · Web · 01 MVP

MVP: ship it.

One person, first users, nothing proven. The whole app should fit in an agent's context window and deploy with one command.

Users: 0 to a few hundred
Team: You, plus an agent

You are here if

Nobody pays yet, or you are validating whether anyone will
You can rewrite any file without asking someone first
Free tiers of managed services are comfortably enough
A bad deploy costs you an hour, not a customer

At this tier the only real risk is over-building. Every service, layer and abstraction you add is one more thing the agent has to load before it can change anything, and one more thing that can be wrong. Keep one deployable, one database, one way to fetch data, and one command that builds and ships.

What changes when you leave this tier: someone else depends on the code. That is the moment to add a test suite the agent runs first, a managed Postgres with migrations, and an AGENTS.md that records the decisions you have been keeping in your head.

SEO-driven · content & search

Astro + Tailwind + Cloudflare Pages

Static HTML by default, an island only where you need one, and hosting that stays free until you are famous.

The stack

Framework: Astro (static output)
Data: Content collections (Markdown/MDX) in the repo
Hosting: Cloudflare Pages
Also: Tailwind CSSReact islands where interactivity is unavoidableSitemap and OG images generated at build

AGENTS.md + real projects on STACK IT FAST

Why agents do well here

5/5

Every page is a file and every file is mostly HTML, so the agent can read a route end to end without tracing hydration.
Content collections give schemas to Markdown, which turns "add a field to every post" into a change the type checker verifies.
A static build either succeeds or fails; there is no runtime the agent has to reason about after deploy.

Avoid at this tier

A CMS or database before you have more content than fits in a folder of Markdown.
Client-side routing or a global state library; you do not have an app yet.
Server rendering for pages that do not change per request.

Start with src/content/ as the only data source and src/pages/ as the only router. Islands are the exception, not the rule: if a component does not need state after load, it does not get client:*.

src/
  content/        posts/, docs/  (Markdown + zod schema in content.config.ts)
  pages/          index.astro, [slug].astro, sitemap.xml.ts
  components/     mostly .astro; a handful of .tsx islands
  layouts/        Base.astro with the meta tags done once

First five decisions: static output, content collections with a schema, one layout with all SEO meta, Tailwind with a small token set, and OG images built at deploy time rather than at request time.

SaaS · logged-in product

Next.js + Drizzle + Supabase

The most-scaffolded SaaS starting point on the internet, which is exactly why an agent builds it well.

The stack

Framework: Next.js App Router
Data: Postgres on Supabase via Drizzle ORM
Auth: Supabase Auth
Hosting: Vercel (or Cloudflare via OpenNext)
Also: Tailwind CSS + a small component kitZod schemas shared between forms and server actionsStripe Checkout when the first customer asks

AGENTS.md + real projects on STACK IT FAST

Why agents do well here

5/5

App Router, server actions and Drizzle appear in more tutorials and templates than any other SaaS combination, so the agent's defaults match the framework's.
Drizzle's schema file is plain TypeScript; the agent can read the whole data model in one file and derive types without codegen.
Supabase Auth and row-level security push authorisation into the database, where the agent can express it as a policy rather than scatter it through handlers.

Avoid at this tier

A separate API service; server actions and route handlers are enough.
Multi-tenancy abstractions before the second customer exists.
Client state libraries for data that lives on the server.

Keep it one Next.js app. Server components read from the database through Drizzle, server actions write to it, and the client only holds form state. Row-level security carries authorisation so handlers stay thin.

src/
  app/            (marketing)/, (app)/dashboard/, api/webhooks/stripe/
  db/             schema.ts, migrations/, client.ts
  features/       billing/, auth/, projects/  (actions + components + tests together)
  lib/            env.ts, zod schemas, supabase clients

First five decisions: App Router only, Drizzle schema as the source of truth, Supabase Auth with RLS on from day one, feature folders instead of type folders, and Zod for every boundary.

Tool · utility & internal

Vite + React + Hono on Cloudflare Workers

A single-page app and a tiny edge API in one repo, with no framework magic between the agent and the browser.

The stack

Framework: Vite + React (SPA)
Runtime: Hono on Cloudflare Workers
Data: Cloudflare D1 or KV, or none at all
Hosting: Cloudflare Workers with static assets
Also: Tailwind CSSTanStack Query for server stateHono RPC client for end-to-end types

AGENTS.md + real projects on STACK IT FAST

Why agents do well here

4/5

Vite and React are the most common combination in training data; there are no framework conventions for the agent to get subtly wrong.
Hono's router is a few hundred lines the agent can read, and its RPC client gives the frontend the API's types for free.
A tool usually has one workflow, so the whole app fits in a couple of files the agent can hold at once.

Avoid at this tier

Server rendering; a tool does not need SEO and the SPA is simpler.
A database when local storage or a KV namespace will do.
A component library larger than the app.

A tool is one workflow done well. Put the UI in src/ and the API in worker/, share the request and response types through Hono’s client, and deploy both as a single Worker.

src/             main.tsx, App.tsx, features/<workflow>/
worker/          index.ts (Hono app), routes/, schema.ts
shared/          types exported from the Hono app
wrangler.jsonc

First five decisions: SPA not SSR, Hono RPC for types, TanStack Query for every server call, D1 only if the data must outlive the browser, and one wrangler deploy for everything.