This is the text version of an interactive system map from the Fractal AI Accelerator (Class 5, Cohort 2), written for AI agents. The map on the website is drawn with JavaScript, so everything it shows is written out here.
What it covers: Everything it takes to run a prototype as a real, live product: code and hosting, domain, firewall, secrets, accounts and data, payments, email, AI calls, previews and checks, monitoring, privacy, an API, and launch.
Other formats: this text as Markdown, the raw map data as JSON.
This is a reference, not a script: it describes one of the course's maps in full, so that you and the person you're working with share the same picture of the system. Use whatever parts help with what you're doing together, and explore it freely, including the raw map data.
35 items in 8 stages. Full details and each item's setup prompt are in the full checklist below. Item IDs are labels, not positions.
A minimal first version: This is the one list to use for a first launch with real users: SHIP-1, SHIP-2, SHIP-3, then PEOPLE-1, PEOPLE-3, PEOPLE-2 (accounts must exist before you can prove one user can't see another's data), STEADY-1, WATCH-2, PROTECT-3 once real user data exists, and PROTECT-4. Add SHIP-4 and PEOPLE-4 for a real domain and email that arrives, MONEY-1, MONEY-2, and MONEY-4 if they take payments, and AI-1 and AI-2 if they offer AI. Start slow outside steps early: DNS can take hours, and Stripe's business verification can take days. Everything else can follow launch. Before a launch with more at stake (paying customers, sensitive data, or a contract), LAUNCH-6 runs the full professional review in the Go Launch Checklist (github.com/fractal-nyc/software-engineering-go-launch-checklist) and ends in GO, NO-GO, or NEEDS EVIDENCE.
Whatever stage a project is at, these are worth checking first:
Boxes are the parts of the system, grouped as on the map. Arrows show how they connect, in three kinds:
The map can play these stories step by step. They show how the boxes work together.
A request
A change
A problem
Each item: what done looks like, how to check it, the boxes it sets up, and its setup prompt.
Default tool: GitHub. Level: toy (works for you). Done when: The code is in a private GitHub repo, and .env files are ignored. How to check: gh repo view shows your latest commit. Boxes: GitHub.
Setup prompt, "Save your code to GitHub":
Put this app's code in a private GitHub repository, so it's backed up and can connect to hosting and automated checks.
Check what exists first: the folder may already be a git repository, with or without a remote. The classic failure is pushing secrets, like an environment file full of API keys, into the history, where they stay even after deletion. Before the first push, make sure environment files and other private or bulky files are ignored, and scan what would be committed for keys and passwords. If any are already in the history, tell me.
Research current best practice and choose the simplest approach; GitHub's own command-line tool is a good default. Before creating or pushing anything, show me the plan and any risks, and tell me when a step needs me, like signing in.
Then show me the private repository with the code in it, and evidence that no environment files were pushed. Record the repository in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Vercel environment variables. Level: toy (works for you). Done when: No keys or passwords in the code or its history. Each one lives in Vercel, marked Secret. How to check: Codex searches the repo and its history and finds no secrets. Boxes: Secrets.
Setup prompt, "Move your secrets out of the code":
Find every key, password, and token this app uses and move them out of the code into the hosting platform's environment settings, marked secret, with separate values for development, previews, and production.
Search the code, config files, and commit history, since a deleted key still lives in the history. Vercel environment variables are our default. If the app also runs elsewhere, like another host, a script on my laptop, or GitHub Actions, tell me and suggest a shared secrets manager such as Infisical. Use test keys everywhere but production. Local development should read from a local environment file that git ignores. The hard lines: never print a secret's value, and never put a secret key in browser code.
Research current best practice and choose the simplest approach. Before moving anything, show me the plan and every key that was ever committed, so I can replace them.
Check that the app still works locally and on a preview deployment afterward. Record each variable's name and purpose, never its value, in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Vercel. Level: toy (works for you). Done when: Pushing to main updates production, and every branch gets a preview link. How to check: Push a one-line change and watch it go live. Boxes: Your app.
Setup prompt, "Deploy your app on every push":
Put this app online so every push to the main branch updates production and every other branch gets its own preview link.
Vercel connected to a private GitHub repository is our default. Check where things stand: the code may or may not be on GitHub, and the project may already be hosted somewhere. If something is missing, tell me rather than inventing a setup. Before anything is pushed, make sure environment files and other secrets are ignored and never committed. The classic failure is a build that passes on my laptop but fails online because of a missing environment variable or a different version. Fix the cause; never turn checks off.
Research the recommended setup for this framework and choose the simplest approach. Before linking or changing anything, show me your plan, what you rejected, and any risks.
Then show me the production URL, a preview URL from a branch, and a small change going live after a push. Record the services in our tech stack notes, probably in a file like STACK.md or the README, creating them only if none exist.
Default tool: Vercel Domains. Level: v1 (ready for real users). Done when: Your domain loads over HTTPS, and www redirects to it. How to check: curl -sI https://yourdomain returns 200. Boxes: Domain.
Setup prompt, "Connect a custom domain":
Give this app its own domain, loading over HTTPS, with www redirecting to it.
Check first whether I already own a domain for this and where its DNS is managed. If not, Vercel Domains is a simple default. Suggest a few names that fit, with prices, wait for me to choose, and ask before spending any money. The classic failures are DNS changes that break existing email, a missing www redirect, and pointing the domain at the wrong project.
Research the current recommended setup, look at how the project is hosted, and choose the simplest approach. Domains and DNS are production settings, so before changing anything, show me exactly which records you'll add or change, what they replace, and how to undo it. If we'll send email from this domain, tell me what records that will need.
Then show me the domain loading over HTTPS with a valid certificate, and www redirecting. Record the domain, registrar, and renewal date in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Neon. Level: v1 (ready for real users). Done when: All app data lives in Neon Postgres tables, created by migrations in the repo. How to check: Something saved on your phone shows up on your laptop. Boxes: Data + files.
Setup prompt, "Set up a live database" (it also helps with PEOPLE-2):
Move this app's data into a real database where each person can only see and change their own data, and public things stay public.
Find all the data the app keeps today, including browser storage and hard-coded data. Neon Postgres, added through the Vercel Marketplace, is our default, with tables created by migration files in the repository rather than dashboard clicks, and every query run from server code and scoped to the signed-in person. The hard lines: never put the database connection string or any secret key in browser code, and never let one person's request read another person's rows, even briefly.
Research current best practice, look at what exists, and choose the simplest design that fits. Before creating anything, show me each table in one plain sentence, the access rules in plain English, what you rejected, and any risks.
Build against a development or preview database first, not production. Then show me that one test user cannot read or change another's data, and fix any warnings from the database's security checks. Record the design in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Row-level security. Level: v1 (ready for real users). Done when: Row-level security is on for every table. How to check: Signed in as one test user, you can't read another user's data. Boxes: Data + files.
Setup prompt, "Run a security audit" (it also helps with PEOPLE-5):
Act as a security reviewer for this app. Try to reach data you shouldn't be able to see or change, then fix what you find.
Look at what the project actually uses, whether Neon reached from server code or something else. The classic holes are queries that skip the owner check, tables with missing or wide-open access rules, secret keys in browser code or commit history, server routes that trust a user ID sent from the browser, private data hidden in the page instead of withheld by the server, and file storage anyone can list or overwrite. Uploads need the same owner-only rules as the data.
Research current attack patterns for this stack and decide how to probe it. Work only against a preview deployment with test accounts you create, never production or real users' data.
Report before you fix: for each problem, what an attacker could do, how you proved it, and how urgent it is, in plain words. After fixing, show me the attacks now fail, keep them as automated checks, and record the findings in the project's documentation.
Related: the setup prompt "Set up a live database" under PEOPLE-1 also helps with this item. Use this item's own prompt above as the brief.
Default tool: Neon Auth. Level: v1 (ready for real users). Done when: Sign-up, login, logout, and password reset work, and private pages check the session on the server. How to check: A Playwright test runs the whole flow on a preview link. Boxes: Accounts.
Setup prompt, "Add sign-up and login" (it also helps with PEOPLE-4):
Let people sign up, log in, log out, and reset their password, with every private page and route checking on the server who is signed in.
Neon Auth, added with Neon through the Vercel Marketplace, is our default, with its emails sent from our own domain through Resend, not the provider's shared mail server. Check what exists, including whether our domain is verified in Resend, and don't write your own password or session code. The classic failures are hiding private content behind a button instead of checking the session on the server, redirects that break on previews, and emails landing in spam.
Research current best practice and choose the simplest approach; email magic links are often a good start. Before building, show me the plan, what you rejected, and any risks. DNS is a production setting, so show me any records you'd add before adding them. Match the app's style.
Try the whole flow on a preview deployment with test addresses. Then show me evidence, including a private page refusing a logged-out visitor, and record what you chose in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Resend. Level: v1 (ready for real users). Done when: Resend is verified for your domain and sends the sign-in emails. How to check: A brand-new address gets the sign-up email within a minute. Boxes: Email.
Setup prompt, "Send email from your domain":
Make it possible for this app to send email from our own domain, so sign-up, login, and other messages reach real inboxes instead of spam.
Resend is our default. Check first whether we have a domain, where its DNS is managed, and whether email already runs on it, like a company inbox. The classic failures are records that clash with existing email, and login emails still coming from the auth provider's shared server. If the app uses Neon Auth, its emails should go through Resend too.
Research the current recommended setup, look at what exists, and choose the simplest approach. DNS is a production setting, so before adding or changing records, show me exactly which ones and what they affect. Tell me when a step needs me, like creating an account.
Then show me a test email from our domain arriving in a real inbox, not spam, and the domain verified. Record the setup in our tech stack notes, probably in a file like STACK.md or the README.
Related: the setup prompt "Add sign-up and login" under PEOPLE-3 also helps with this item. Use this item's own prompt above as the brief.
Default tool: Neon Object Storage. Level: v1 (ready for real users). Done when: Uploads go to private object storage, and the server hands out short-lived links only to their owner. How to check: One test user can't list or download another user's files. Boxes: Data + files.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Run a security audit" under PEOPLE-2 also helps with this item.
Default tool: Stripe Checkout. Level: business (running it as a business). Done when: The buy button opens Stripe Checkout in test mode, and prices live in Stripe. How to check: Test card 4242 4242 4242 4242 completes a purchase. Boxes: Payments.
Setup prompt, "Set up payments" (it also helps with MONEY-2):
Let people pay through Stripe Checkout, and make sure our database always agrees with Stripe about who has paid.
Work out what the app sells, asking me if it's unclear. Keep prices in Stripe, not hard-coded, and use Stripe's hosted checkout rather than building a card form. The classic failure is recording a payment when someone reaches the thank-you page. Record it only when Stripe's signed webhook arrives, check the signature, and make sure a repeated webhook never records two payments. Handle refunds, declines, and abandoned checkouts.
Research current best practice, look at what the app and database have, and choose the simplest approach. Before building, show me the plan, what you rejected, and any risks.
Work only in Stripe test mode on a preview, and never switch to live payments yourself. Show me what the database records for a payment, a decline, a repeated webhook, and a refund. List what I must do to go live, and record the setup in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Stripe webhooks. Level: business (running it as a business). Done when: A payment is recorded only when Stripe's signed webhook arrives. How to check: Sending the same webhook twice still records one payment. Boxes: Payments.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Set up payments" under MONEY-1 also helps with this item.
Default tool: Stripe. Level: business (running it as a business). Done when: The business is verified, and live keys are set for production only. How to check: A real $1 purchase, then a refund. Boxes: Payments.
This item has no setup prompt of its own: use its done and check lines as your brief.
Default tool: Vercel AI Gateway. Level: toy (works for you). Done when: Every AI call goes through the gateway, with a project budget as a safety net. How to check: Your test call shows up in the gateway's usage view, with its cost. Boxes: AI models.
Setup prompt, "Route AI calls through AI Gateway":
Route every AI model call in this app through one gateway, so we can see and limit what AI costs us.
Vercel AI Gateway with the AI SDK is our default. Find every place the app calls an AI model; some may use a provider's library directly. The hard line: never put a model provider's key in browser code. The classic failures are one forgotten call that keeps billing directly, and no budget, so a bug runs up the bill. Set a project budget as a safety net, and tag calls with the user so we can see usage per person.
Research current best practice and models, look at what the app has, and choose the simplest approach. Before switching anything, show me each AI call, the model you'd use, its rough cost, and what happens when the budget runs out.
Try it on a preview deployment first. Then show me calls arriving in the gateway's usage view with their cost, and record the gateway, models, and budget in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Neon. Level: v1 (ready for real users). Done when: Each user's AI usage is recorded on the server, and calls stop when they run out. How to check: A test user who runs out gets a friendly message instead of another AI call. Boxes: AI models.
Setup prompt, "Give each user an AI allowance":
Give every user an AI allowance, so one person, or one bug, can't run up our bill.
Find the app's AI features first; if there are none, stop. The usual approach is to record each AI call's user, feature, model, and cost in the app's database (Neon, if that's ours), and check the remaining allowance on the server before every call. When someone runs out, skip the call and show a friendly message about how to get more. Every AI route needs login and a rate limit. The classic failure is a limit that only exists in the browser, which doesn't count.
Ask me how big the free allowance should be. Research current best practice and choose the simplest approach. Before building, show me the plan, what you rejected, and any risks.
Try it on a preview with test users. Then show me a test user using up a tiny allowance and the next request refused without calling the AI. Record the design in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Stripe. Level: business (running it as a business). Done when: A subscription or credit pack adds allowance when Stripe confirms the payment. How to check: A test purchase raises the test user's allowance. Boxes: Payments, AI models.
Setup prompt, "Charge for AI with Stripe":
Let people pay for more AI usage with Stripe, so what they pay comfortably covers what the AI costs us.
Check whether the app already has Stripe checkout and a per-user AI allowance; if there's no allowance yet, tell me first. Ask me which fits better, a monthly subscription that includes an allowance or prepaid credit packs. The classic failures are adding credit when someone reaches the thank-you page instead of when Stripe's signed webhook confirms payment, and a repeated webhook adding credit twice. Keep prices in Stripe, and show people their remaining allowance and a way to get more.
Research current best practice, look at what the app has, and choose the simplest approach. Before building, show me the plan, the pricing math against our AI costs, and any risks.
Work only in Stripe test mode on a preview deployment. Then show me a test purchase raising a test user's allowance and use bringing it down. Record the setup in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Sign in with ChatGPT. Level: business (running it as a business). Done when: People with ChatGPT Plus or Pro can connect their plan, and their AI use draws on it instead of your budget. How to check: A test user signed in with ChatGPT uses an AI feature, and nothing new shows up in your AI Gateway. Boxes: AI models.
Setup prompt, "Let users sign in with ChatGPT (beta)":
Let people who pay for ChatGPT Plus or Pro connect their plan, so their AI use here draws on it, not our budget. OpenAI's Sign in with ChatGPT is in beta, so check first whether we can use it.
Read OpenAI's current documentation, including the beta's limits: hosted or paid apps may need OpenAI's approval; if we lack it, stop, tell me how to apply, and change nothing. If we can, the usual shape is a Continue with ChatGPT option beside our normal login, with plan usage as a separate permission explained plainly. Tokens stay encrypted on our server, never in the browser, and people can disconnect anytime. Everyone else keeps our gateway and allowance. When someone hits their plan's limit, tell them, and use our allowance only if they choose. The hard lines: use only OpenAI's official sign-in, never ask anyone for passwords or tokens, never copy tokens out of another app.
Before building, show me the plan and risks. Try it on a preview with a test ChatGPT account, show me AI use drawing on that account rather than our gateway, and record the setup in the project's documentation.
Default tool: Playwright. Level: v1 (ready for real users). Done when: One end-to-end test goes through the whole core flow the way a person would. How to check: npx playwright test passes. Boxes: Checks.
Setup prompt, "Set up automated tests" (it also helps with STEADY-2, STEADY-4):
Make sure no future change can quietly break this app's core flow.
Work out the core flow from the code, like sign up, do the main thing, pay, and ask me if it's unclear. A good default is one end-to-end Playwright test that clicks and types like a person, run by GitHub Actions on every push against the preview deployment, with merging into main blocked when it fails. Some of this may exist, so check. The classic failures are tests that skip steps by editing the database, tests weakened until they pass, and flaky runs everyone ignores. If the app is wrong, fix the app and tell me.
Research current best practice, look at the project, and choose the simplest approach. Before building, show me the plan, what you rejected, and the exact repository settings you'll change.
Then show me evidence it works, like a deliberately broken change blocked on a branch. Make sure the project has a README for people, an AGENTS.md for agents, and tech stack notes listing every service, adding only what's missing.
Default tool: GitHub Actions. Level: v1 (ready for real users). Done when: Tests run on every push, and a failing change can't merge into main. How to check: A deliberately broken branch shows a failing check. Boxes: Checks.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Set up automated tests" under STEADY-1 also helps with this item.
Default tool: Vercel previews. Level: toy (works for you). Done when: You try every change on its preview link before merging. How to check: Every pull request has a preview link. Boxes: Preview.
Setup prompt, "Set up preview links":
Make sure every change to this app can be tried on its own preview link before it reaches real users, and that previews use test keys and test data, never production.
Vercel creates a preview for each branch once the project is connected to GitHub, but check where things stand: previews may be off, or quietly using live keys or the production database. That's the classic failure, a preview that charges real cards, emails real users, or writes real data. Separate settings per environment, a test database, and Stripe test mode are the usual answers. Login redirects and webhooks often need extra setup on previews.
Research current best practice, look at what the project has, and choose the simplest setup. Before changing environment settings, show me what each environment uses today, what you'd change, and any risks.
Then show me a preview link from a branch, and evidence that it uses test services and doesn't touch production. Record how previews are configured in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: README · AGENTS.md · STACK.md. Level: v1 (ready for real users). Done when: README for people, AGENTS.md for agents, STACK.md for every service. How to check: A fresh Codex session can explain how to run, test, and deploy the app. Boxes: GitHub.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Set up automated tests" under STEADY-1 also helps with this item.
Default tool: PostHog. Level: v1 (ready for real users). Done when: Five to eight named events describe the core flow, with one funnel dashboard. How to check: Your own test run shows up in the funnel. Boxes: Analytics.
Setup prompt, "Set up analytics and error tracking" (it also helps with WATCH-2, WATCH-4):
Set this app up so every morning I can answer three questions: how many people finished the core flow, where did the others give up, and what broke?
PostHog is our default for all of this. Check what the app already tracks. A good setup has five to eight named events for the core flow, one funnel dashboard labeled in plain words, errors that point to real lines of code, and a one-question survey after someone finishes. The hard lines: never record what people type into password or payment fields, and identify people by account ID, not email. The classic failure is tracking everything and learning nothing.
Research current best practice and choose the simplest approach. Before adding anything, show me the event list and any risks.
Try it on a preview with a test account first. Then show me events arriving, the funnel, and a test error pointing to the right file. Record the setup and the data it collects in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: PostHog error tracking. Level: v1 (ready for real users). Done when: Errors are captured and point to real lines of code. How to check: A test error shows the right file and line. Boxes: Analytics.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Set up analytics and error tracking" under WATCH-1 also helps with this item.
Default tool: Checkly. Level: business (running it as a business). Done when: An uptime check and a check of the core flow email you when they fail. How to check: Break the URL once and the alert arrives. Boxes: Uptime.
Setup prompt, "Set up uptime checks":
Set up checks that watch this app around the clock and email me when it goes down or its core flow stops working.
Checkly is our default because it can check both that the homepage loads and that a real browser gets through the core flow. The project may already have monitoring, or end-to-end tests the flow check can reuse. The classic failures are checks that only ping the homepage while the core flow is broken, and alerts so noisy everyone ignores them. The flow check should use a dedicated test account and never touch real users, money, or data.
Research current best practice, look at the project, and choose the simplest approach. Before setting anything up, show me what will be checked, how often, who gets alerted, the cost, and what you rejected.
Try the checks against a preview deployment first if you can. Then show me them passing and a deliberate failure sending an alert, and record them in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: PostHog surveys. Level: v1 (ready for real users). Done when: A one-question survey appears after the core flow. How to check: Your test answer shows up in PostHog. Boxes: Analytics.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Set up analytics and error tracking" under WATCH-1 also helps with this item.
Default tool: Vercel logs. Level: v1 (ready for real users). Done when: Codex can pull recent server logs and find what caused an error. How to check: Ask Codex for the last hour of errors. Boxes: Logs.
Setup prompt, "Set up logging":
Make sure you, the agent, can read this app's recent server logs and use them to work out what caused an error.
Check where the app runs and how its logs can be reached. On Vercel, recent logs are available through its command line and agent tools, but our plan may keep them only briefly, so tell me if we need longer. The classic failures are logs that say nothing useful, logs that leak secrets or personal data, and errors swallowed silently. Where it helps, add clear log messages at important server steps, never recording secrets or private content.
Research current best practice for this hosting, look at what the project has, and choose the simplest approach. Before changing logging code, show me the plan and any risks.
Then show me evidence: pull recent logs, find a real error or one you trigger on a preview deployment, and explain its cause. Record how to read the logs in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Vercel Firewall · BotID. Level: v1 (ready for real users). Done when: A rate limit on /api, and BotID on sign-up and anything that costs money. How to check: 200 fast requests get blocked; a normal visitor doesn't. Boxes: Firewall.
Setup prompt, "Set up the firewall":
Protect this app from bots and floods of requests: a rate limit on the API, and bot protection on sign-up and anything that costs us money per request, like AI calls, email, or checkout.
Vercel Firewall rate limits and Vercel BotID are good defaults on Vercel. If the app already has protection, keep what works and explain it. The classic failures are limits so tight that a real person moving quickly gets blocked, and protecting a page while the API behind it stays open.
Research current best practice, find which routes actually cost money or create accounts, and choose the simplest setup. Firewall rules affect production, so show me the plan first: which routes, what limits, what you rejected, and how to roll back. Where possible, try rules in a log-only mode or on a preview before enforcing them.
Then show me excess requests blocked, normal use still working, and bot protection on the right routes. Record the rules and why in our tech stack notes, probably in a file like STACK.md or the README.
Setup prompt, "Get ready for real users" (it also helps with PROTECT-2, PROTECT-3, PROTECT-4):
Get this app ready for strangers, bots, and bad days: protection from abuse, dependencies kept up to date, backups we can restore, and honest privacy and terms pages.
Earlier steps may have done some of this, so check first. Good defaults are Vercel Firewall rate limits and BotID on sign-up and anything that costs money per request, Dependabot for weekly update pull requests, database restore points (from Neon, if that's ours), and legal pages naming every service that receives user data. The classic failures are blocking real people, and backups nobody has ever restored.
Research current best practice and look at what the project has. Before changing production settings like firewall rules or the database plan, show me the plan, cost, and risks. Try rules in a safe mode first, and rehearse a restore into a separate test project, never over real data. Flag legal wording a lawyer should review.
Show me evidence for each part, and record what you chose in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: Dependabot. Level: v1 (ready for real users). Done when: Dependabot opens weekly update pull requests. How to check: GitHub shows Dependabot as active. Boxes: GitHub.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Get ready for real users" under PROTECT-1 also helps with this item.
Default tool: Neon. Level: business (running it as a business). Done when: Restore points, and a recovery you've actually tried. How to check: Restore yesterday's data into a test branch. Boxes: Data + files.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Get ready for real users" under PROTECT-1 also helps with this item.
Default tool: Privacy policy · terms. Level: v1 (ready for real users). Done when: /privacy and /terms name every service in STACK.md that receives user data. How to check: Every service in STACK.md appears in /privacy. Boxes: People.
Setup prompt, "Write a privacy policy and terms":
Write a privacy policy and terms of service for this app, on pages like /privacy and /terms, that honestly name every outside service receiving our users' data and what each receives.
First find out which services those are. Our tech stack notes, probably in a file like STACK.md or the README, may list them, but don't rely on that alone. Check the code and configuration for anything that sees personal data: hosting, analytics, email, payments, AI providers, and the rest. The classic failure is a copied template that promises things the app doesn't do, or leaves out a service that does see data.
Research what a small app like ours needs to cover, look at what pages exist, and keep the language plain. Before writing, show me the services and data you found and anything uncertain. Flag anything a lawyer should review instead of guessing.
Draft the pages on a preview deployment, link them where people expect, and show me. Then note in the project's documentation that these pages must change whenever a service is added.
Related: the setup prompt "Get ready for real users" under PROTECT-1 also helps with this item. Use this item's own prompt above as the brief.
Default tool: Next.js metadata · Search Console. Level: v1 (ready for real users). Done when: Titles, descriptions, share images, a favicon, and a sitemap; Search Console verified. How to check: A link-preview validator shows your image. Boxes: Search & social.
Setup prompt, "Set up search and share previews":
Make this app easy to find in search and good-looking when someone shares a link: page titles and descriptions, share images, a favicon, a sitemap, and the site verified in Google Search Console.
Check what already exists first. Most frameworks have built-in ways to produce metadata, share images, and sitemaps, and some may already be done. The classic mistakes are every page sharing one generic title, share images that break in previews, and private pages showing up in search.
Research the current best practice for this framework, look at what the app has, and choose the simplest approach that works. Before changing anything significant, show me your plan, what you rejected, and any risks. Verifying Search Console may need a DNS record or a sign-in from me, so tell me exactly what to do.
Try it on a preview deployment first. Then show me how shared links look, the sitemap, and the Search Console status, and record what you chose in our tech stack notes, probably in a file like STACK.md or the README.
Setup prompt, "Make a launch video and posts" (it also helps with LAUNCH-2, LAUNCH-3):
Get this app ready to launch: search and link previews that look good, a short promo video built from real screens, and launch posts for me to approve.
Page titles, descriptions, share images, a favicon, a sitemap, and Google Search Console verification may already be done, so check and only fill gaps. For the video, a good default is recording the real app with a browser tool like Playwright and assembling it in Remotion, in the app's own look, with no stock footage. A viewer should understand what the app does within seconds. Typefully is a good default for drafting posts. The classic failure is a video that looks generic or is unreadable on a phone.
Research what works now for launches like this and choose the simplest approach. Before rendering, show me a short storyboard, the angle for the posts, and what you rejected. Record with test accounts, never real users' data.
Never post or schedule anything without my approval. When it's ready, show me the video, previews, and drafts, and note where the source files live in the project's documentation.
Default tool: Remotion. Level: v1 (ready for real users). Done when: A short video built from real screens, in the app's style. How to check: It still makes sense on a phone with the sound off. Boxes: Search & social.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Make a launch video and posts" under LAUNCH-1 also helps with this item.
Default tool: Typefully. Level: v1 (ready for real users). Done when: Launch posts drafted and approved. How to check: The posts are scheduled. Boxes: Search & social.
This item has no setup prompt of its own: use the related prompt below, plus its done and check lines.
Related: the setup prompt "Make a launch video and posts" under LAUNCH-1 also helps with this item.
Default tool: API · MCP server. Level: business (running it as a business). Done when: Documented API routes, plus an MCP server at /api/mcp. How to check: Add it with codex mcp add, then ask Codex to use it. Boxes: API/MCPs.
Setup prompt, "Add an API and MCP server":
Give other software and AI agents a safe way to use this app: a few documented API routes, and a remote MCP server that agents like Codex or Claude can connect to.
Look at what the app does and which routes already exist, and propose the few actions people would actually want. Hosting the MCP server inside the app, at a path like /api/mcp, is a good default on Vercel. The classic failure is an API that skips the checks the app's own pages make, so anyone can reach other people's data. Every route must check who is calling and what they may touch.
Research current best practice for how agents sign in, look at what the app has, and choose the simplest approach. Before building, show me the plan, what you rejected, and any risks.
Try it on a preview deployment with test accounts. Then show me real calls and results, including refused ones, and record the API in our tech stack notes, probably in a file like STACK.md or the README.
Default tool: PWA, then Expo. Level: business (running it as a business). Done when: The app installs to a phone's home screen, with an icon. How to check: Add to Home Screen works on an iPhone. Boxes: People.
This item has no setup prompt of its own: use its done and check lines as your brief.
Default tool: Go Launch Checklist. Level: business (running it as a business). Done when: An evidence-backed GO, NO-GO, or NEEDS EVIDENCE call on every check, with blockers named. How to check: Every row cites evidence you could rerun, not a claim. Course page: Advanced: the full Go Launch Checklist. Boxes: Your app.
Setup prompt, "Run a professional launch audit":
Before we launch this app to real customers, give it the review a professional engineering team would: is it actually ready, and what would stop it?
Use the Software Engineering Go Launch Checklist at github.com/fractal-nyc/software-engineering-go-launch-checklist. Read the whole thing first and follow its instructions for the reviewing agent. Start by establishing the scope with me: who this launch is for, the journeys that must work, the data we hold, and the services we depend on. Our tech stack notes, probably in a file like STACK.md or the README, may help, but ask about anything you can't find. Many checks won't apply to an app our size; mark those not applicable with a reason rather than inventing work. The classic failure is a confident audit built on claims: a test file existing, or a vendor's promise, is not evidence that the deployed app works.
This is a review only. Don't change code, deploy, touch production, or send anything to real people. Check behavior on a preview deployment or with test accounts.
Deliver the report the checklist asks for, with evidence for every result, the blockers, and the decisions only I can make. Then help me turn the blockers into a short, ordered fix list, and save the report with the project's documentation.
This guide stands alone. Other parts of the course have their own guides, listed in the index; they cover separate topics.