Build your own vibes site

Static page

A page that is the same for everyone: files that a host hands out. No server of your own.

Served app

A thing with a computer of its own behind it, so it can remember who you are, keep live state, take uploads.

The agent

An AI that can read and write files and run commands on your PC, not just chat. Here: Claude Code.

Repository (repo)

A folder of code with its whole history kept. Lives on GitHub.

Deploy

Putting a new version of a thing on the internet.

Terminal

The black window where you type commands. On Windows, PowerShell; on a Mac, Terminal.

You describe what you want in ordinary sentences. The agent builds it: writes the code, runs the tests, opens the pull requests (a proposed change, with a description, that you can read before it goes live). You look at the result in your browser and say what is off. It fixes it. Repeat. Over time you will start to say things like "make that a dropdown" and "no, warmer" and it will know what you mean, because it reads the notes it wrote last time.

The agent owns the code. You own the accounts and the money. Every service on this page is signed up for by you, in your browser, with your card if one is needed. The agent tells you when it needs one and what to click.

Never paste a password, an API key or a token into the chat. Not once, not "just this time". The chat is stored as a transcript; anything in it is written down somewhere you do not control. A good agent will refuse to use a key you pasted and tell you to revoke it and make a new one. If yours does not, tell it to (the skills further down include that rule).

What happens instead: the agent asks you to run one short command in your own terminal that stores the secret straight where it is needed, so it never appears in the chat. See Keys and secrets.

• Sign in to a service in a browser window it opens (Fly, Cloudflare, Neon, GitHub).
• Add a card where one is required (Fly, and Cloudflare for storage).
• Run a one-line command that stores a secret (it will give you the exact line).
• Look at the thing it built and say what you think.
• Approve a pull request when you are happy with it.

A monorepo is one repository holding all of your projects, so they can share code and the agent can see everything at once. A folder per app: apps/home for the home page, apps/<your-app>/web for the part people see and apps/<your-app>/server for the part that remembers things. Shared code in packages/. Your notes and decisions in notes/, which the agent reads and writes too.

Front end: what runs in the visitor's browser: the pages, the buttons, the animation. It is files, and files can be hosted for free. Back end: what runs on a computer you rent: it holds the accounts, the saved data, the live state several people share. Only some apps need one.

Pull request: a proposed change with a description, which you or the agent can review before it is merged into the real thing. CI (continuous integration): every change is checked by a robot before it goes live; the tests run, the code is checked, and a red result stops the merge.

DNS is the internet's phone book: it turns a name like game.yourname.com into the address of the computer that answers for it. Cloudflare keeps your page of the book, and you (or the agent, with you watching) add lines to it.

A served app on Fly needs two lines: an A record (the computer's IPv4 address) and an AAAA record (its IPv6 address). Fly prints both when the agent asks it for a certificate for the name; you paste them into Cloudflare.

The gotcha: in Cloudflare each record has a cloud icon. Orange means Cloudflare sits in front of the address and rewrites traffic; that breaks Fly's certificate and its live connections. For a Fly app, click the cloud so it is grey: "DNS only". The home page on Cloudflare's own hosting does not need this; Cloudflare manages that record itself.

Your home page, a portfolio, a game's showcase, anything that is the same for every visitor. These are files, and Cloudflare Workers hands them out from servers all over the world for free. The agent deploys from the command line, and your domain attaches from one small config file in the folder. No card, no monthly bill, no server to look after.

pnpm --filter @<repo>/home build
cd apps/home; wrangler deploy

Anything with accounts, live state that several people watch at once, or uploads, needs a computer of its own. Fly.io rents you one small machine that is always on, handles the secure connection, and gives you a command-line tool the agent drives. You sign up, put a card on file, and the agent does the rest: it writes the config, and once GitHub is connected the app deploys itself every time a pull request is merged.

An app that can tolerate a few seconds' wake-up (a chat, a form) can be set to stop when idle and costs a fraction of that; one that keeps a live session open (a game, a video call) stays on.

• Does it need to remember who someone is? Served.
• Do several people see the same thing change live? Served.
• Do people upload things? Served.
• Otherwise: static, and free. Start there. You can always add a server later, on its own subdomain, without touching the home page.

Neon hosts a Postgres database (the standard, boring, excellent kind) on a free tier that is plenty for a personal site, and it keeps a history so a mistake can be rewound. It lives apart from your Fly machine, so if the machine is ever lost the data is not. One project, one database per app.

R2 is a bucket (a big folder on the internet) for images, video and anything people upload. Free to 10 GB, and no charge for people downloading from it, which is the cost that bites elsewhere. It needs a card on file at Cloudflare even on the free tier.

The one gotcha we hit: if a page draws an image from the bucket onto a canvas (a map, an editor, a game board), the bucket needs a CORS rule naming your app's address, or the browser refuses the image while plain pictures on the page still work. It is one command; the platform skill below has it. Ask the agent for it the first time a canvas stays blank.

If you already have something (a spreadsheet, an old database, a folder of pictures), the agent writes a small one-off importer, runs it once against the new database or bucket, and deletes it, or keeps it in scripts/ if you might need it again. You never hand-enter anything twice.

Someone types their email address. They get an email with one link. They click it and they are signed in for a month. That is the whole thing. No password to invent, forget, reuse or leak; nothing for you to store that could be stolen; and one sign-in works for every app under your domain, because the browser keeps one small note (a cookie) for the whole domain. Visitors who only look never sign in at all.

On Fly, secrets are stored with the app and handed to it when it starts; nobody can read them back, only see their names. You set one from your own terminal, never from the chat:

flyctl secrets set RESEND_API_KEY=<paste the key here, in your terminal> --app <fly-app>

Better still, for a secret nobody needs to see, the agent gives you a line that makes it and stores it in one go, so it never appears anywhere:

flyctl secrets set MASTER_KEY=$(openssl rand -base64 32) --app <fly-app>

The rule, again: nothing goes through the chat. If a key ends up in a transcript, treat it as public: revoke it and make a new one.

If your app uses AI (a copilot, generated images, a chatty coach), the question is who pays for it. The answer here is: the site never pays for AI. Two ways to do that.

The station. A small program a signed-in person runs on their own PC. It connects out to your app and offers to do the AI work there, under their own Claude subscription and their own accounts. Your server only coordinates; it never sees their login. Free for you, free on top of what they already pay, and it can use their graphics card for the heavy things.

A stored key. For someone without a PC to leave on, your app can hold an API key they paste into a settings page. It is encrypted before it is saved (with a master key that lives only in Fly's secrets), decrypted only for the moment it is used, and never sent back to a browser. They pay their vendor directly.

The app tries the station first, then a stored key, then a harmless offline stand-in, so it always runs. The platform skill below carries the detail.

Save as .claude/skills/repo-engineering/SKILL.md. It assumes a TypeScript monorepo with pnpm; if yours is different, tell the agent to rewrite the map and commands and keep the standards.

Save as .claude/skills/platform/SKILL.md. Replace <you>, <your-domain>, <repo>, <fly-app>, <bucket> and <account-id> as each account is made; the agent can do it when you tell it the name.

1. Frontmatter at the top: a name and a one-paragraph description that says when to read it. The agent uses the description to decide.
2. The map: a table of folders, what lives in each, and what each depends on.
3. The data flow: how one feature moves through the code, step by step, so a new one copies the shape.
4. The commands: how to run, test, lint and build, and the one line that means "done" (the gate).
5. The standards, each with its why. A rule without a reason gets argued with; a rule with one gets followed.
6. The done checklist: what the agent runs before it says it has finished.

Keep it under a few hundred lines; a skill the agent cannot hold in its head is not read. Put the long worked examples in a references/ folder beside it and link them. Update it when the agent gets something wrong twice; the second time is the rule.