Lesson 17.1 taught you to split a product into capabilities and connect the solved ones. Now you need a map of *where* those connections go — one that survives renames, pricing changes, and dashboard redesigns.

The trick is to learn categories first, vendors second. Categories are durable. Individual services are illustrations of a category, not permanent answers.

The categories every small app draws from

Almost every small AI product needs some version of these: source control, deployment and hosting, database and authentication, file storage, domain and DNS, model routing, email, payments, and analytics with error tracking.

You will not need all nine on day one. But when a Lesson 17.1 capability says "connect," it lands in one of these buckets.

Illustrations, not shopping lists

What follows are recognizable examples. Read them as *"one current way to fill this category"* — and refresh details from official docs and pricing pages before you commit.

• GitHub — source control and collaboration. The shared home for a repository: history, branches, pull requests, issues, and review. Its gh CLI lets an authenticated agent inspect pull requests and issues, create a branch-based change, and work with project history from the terminal — the Class 6 branch workflow.

• Vercel — deployment and hosting. Turns a Git-connected web project into preview deployments (one URL per change) and a production deployment (the live URL), plus deployment-time environment variables. Its vercel CLI lets an authenticated agent inspect deployments and logs, manage environment variables, and deploy without opening the dashboard each time.

• Supabase — managed backend (Postgres, auth, storage, APIs). A managed backend built around a Postgres database, with authentication, file storage, and auto-generated APIs. Its supabase CLI supports local development, schema migrations, generated types, and controlled deployment work. Boundary to remember: Supabase *supplies* backend capabilities, but you still learn database design and SQL properly in Part VI — the service is not a substitute for understanding your data model.

• Neon — serverless Postgres alternative. A managed serverless Postgres option, especially useful for a focused hosted database with database branching — cheap copies of the database for preview environments and safe migration testing. Its neonctl CLI manages projects, databases, branches, and roles. Treat Neon as an *alternative* to Supabase for the database layer, not a second database alongside it.

• Cloudflare — domain, DNS, edge, and Workers. Manages DNS records, domains, edge delivery, security rules, and serverless execution via Workers. Its wrangler CLI lets an authenticated agent develop and deploy Workers and manage related configuration. Full treatment of serverless execution, DNS, and edge architecture arrives in Part VII.

• OpenRouter — model routing. The routing service from Part IV, reached through an API key, coding-agent configuration, or small project script rather than an account-management CLI. Here it is one example of an API-connected service whose model policy, data boundary, and usage must be deliberately controlled, exactly as Classes 13 and 14 taught.

• AWS — the broad cloud platform. Compute, storage, databases, networking, queues, AI services, and more; its aws CLI manages the same infrastructure the console manages. Recognize AWS early because it is everywhere — but it is usually not the first home for a small AI product. The surface area is huge, pricing is service-by-service and usage-based, and beginners face architectural choices they do not need yet. Start with focused managed services; bring in AWS when breadth, control, or scale genuinely require it.

Email, payments, and analytics providers follow the same pattern — one managed service per category, learned well enough to price and control. The category is the lesson; the vendor is the current illustration.

Pricing reality, in one box

The beginner failure is not month one's bill. It is five usage-metered services with no alerts, no caps, and an uncapped key — discovered after an agent looped all night.

Why Class 6 matters here

This is where your CLI lessons pay off. Every service above exposes a terminal interface, so an authenticated coding agent can inspect a Vercel deployment and its logs, create a Supabase migration or a Neon database branch, deploy a Cloudflare Worker, check GitHub pull-request status, or manage an AWS resource — without pretending the dashboard is the only interface.

That power travels with Class 14's boundaries. Installing a CLI and authenticating it gives the agent capability. Capability is not permission. It does not remove the need for scopes, test environments, budget limits, separate preview and production credentials, and human confirmation before a public, paid, or irreversible change.

Managed vs. self-hosted

Every category offers the same fork: use someone's managed service, or run the equivalent yourself. Managed means the provider handles patching, backups, scaling, and uptime — you pay money and accept their limits. Self-hosting means you handle all of it, on your own server or raw VMs.

For a first product, managed wins almost every time. Self-host when you have a specific reason from Lesson 17.1 — regulation, cost at proven scale, control the managed tier cannot give — and the skill to carry it.

Four checks before you adopt anything

Run every candidate service through four questions. If you cannot answer all four, read the docs page, fill the gaps, then decide.

1. Fit. Does it do the job you need, at your current scale, without forcing a rewrite of everything around it? 2. Pricing model. How does it meter — seats, requests, rows, bandwidth, build minutes? What do month one and a 10× spike cost? Where are the alerts and caps? 3. Data and access boundary. What data crosses the boundary, whose credentials carry it, and with what scopes? Where are keys stored? What happens on revoke? 4. Exit path. How do you leave? Can you export data in an open format? A service with no export story is a landlord, not a service.

If you cannot answer all four, you are not ready to connect.

Check your understanding

1. Why learn categories before vendors? 2. What is the difference between Supabase and Neon on this map — and why should a beginner pick one, not both? 3. What does a CLI give an agent, and what does it *not* give? 4. Name the four adoption checks and apply one to a service you already use.

Exercise: make a stack card

Create a one-page stack card for a small app — your research app is ideal. Cover GitHub, Vercel, Supabase *or* Neon, Cloudflare, OpenRouter, and AWS only where relevant, plus one email and one payments entry. For each row record: job, account owner, credential location, CLI or API path, starter-cost assumption, and whether the agent may inspect, test, or change it.

Finish line: a single page you could hand to a collaborator — or paste to an agent — stating every service, its cost assumption, and its permission level. Lesson 17.3 builds on it: what makes this stack *yours*?

What comes next

Services are ingredients. A product is a recipe. Next: the thin custom layer — the workflow, rules, and experience no individual service provides alone.