Guided build · an evening

Newsletter drafter

Turns your week's notes into a ready-to-send email to your audience.

No commands. No code. You're about to build this by SAYING what you want — in your own language. The only skill is describing the result well. Here's the whole thing, start to finish.

What you'll have at the end

Turns your week's notes into a ready-to-send email to your audience.

First, how to actually talk to the agent

  1. 1Describe the RESULT, not the tech: what's on screen, what each button does, what gets saved. The agent handles the 'how'.
  2. 2Be concrete about screens and fields — 'a form with amount, category and date' beats 'let me add expenses'.
  3. 3Ask for the smallest working version first. You grow it by talking afterwards — that's Step 2, not the first message.
  4. 4Decide what's YOURS, not the agent's: name the categories, colours, rules. Don't make it guess what only you know.

Step 1 — Build it live

Prompting for this kind of tool

  1. 1For a newsletter drafter, nail THREE things: your fixed sections (intro, main story, links, sign-off), that you drop notes as bullets into each section, and that a live preview shows the assembled issue exactly as it'll read.
  2. 2Decide the sections yourself — they're YOUR newsletter's spine, so list them in order instead of letting Claude guess a layout.
  3. 3Say 'everything saves on my device' and 'let me start a new issue from last week's as a template', so past issues stay listed and you're never starting from a blank page.
  4. 4Always end with the magic line: 'build the whole thing and tell me exactly how to open it; don't stop to ask questions.'
Start Claude
claude --dangerously-skip-permissions

Open the terminal and run this (if Claude is already running, type /exit first). Then ask it to make a folder for this project and work inside it.

The wrong ask vs. the right ask
✕ what most people type
you ▸ grow my audience

✓ what actually works — copy it, or better, say it in YOUR words
you ▸ Build me a newsletter drafter. A subject-line field sits at the
      top, then my fixed sections (intro, main story, links,
      sign-off); I drop this week's notes as bullets into each section
      and drag to reorder them. A live preview pane shows the
      assembled issue, and a 'copy email-ready text' button gives me
      clean plain text to paste into my email tool. I can start a new
      issue from last week's as a template, and past issues stay in a
      saved list on my device. Clean, editorial look. Build the whole
      thing and tell me exactly how to open it; don't stop to ask
      questions.

Say it in YOUR language — Russian, Spanish, anything. Claude understands.

Build it now — tick as you go

0/6

Step 2 — It's built. Now make it yours

Claude said 'open localhost…' — now what?

Don't panic at the techy link. Claude tells you one of two things. Either a file like index.html — find it in your project folder and double-click it; it opens in your browser. Or a web address starting with http://localhost — copy it into your browser's address bar and press Enter. 'localhost' just means 'this is running on your own computer right now'. That's your tool. It's real.

Now tweak it until YOU like it — just talk

This is the part that makes it YOURS. Don't accept the first version — change it by saying what you want, right there in the same chat. Claude rebuilds and you refresh. Keep going until it fits how you actually work. For this tool, try things like:

you ▸ add a subject-line field with three suggestions
you ▸ draft a one-line intro from this week's bullets
you ▸ let me reuse last issue as a starting template
How I (Evgenii) actually do this

I don't type long messages. I open voice-to-text (the mic in ChatGPT, or your phone keyboard), and just TALK through everything I think about what it built — what's wrong, what I want next — then select-all, copy, and paste the whole brain-dump into Claude Code. Messy spoken thoughts work fine; the agent sorts them out. It's several times faster than writing.

Step 2.5 — Test it like a real thing (it won't be perfect first try)

The truth no one tells beginners: the first build is a DRAFT. The agent makes something, you run it, you find what's off, you tell it — and THAT loop is the actual work. Don't read the code. Use the tool like a stranger would and watch where it lets you down. For this tool, check exactly this:

  1. 1Open it (Claude gives a localhost link or an index file — see Step 2), type a subject line, and drop a couple of bullets into each section.
  2. 2Watch the live preview — does the assembled issue update as you type, and does it actually read like a finished email?
  3. 3Drag a bullet to reorder it within a section — does the preview follow the new order?
  4. 4Hit 'copy email-ready text' and paste it into your email tool — did clean plain text come across, with no broken formatting?
  5. 5Refresh the page (F5 / Cmd-R), then check the saved list. Is this issue and any past one still there? If they vanish, 'saves on my device' isn't wired up — fix that next.

Found something wrong? Say it like this

You fix nothing yourself — you DESCRIBE what's wrong in plain words and the agent fixes it. Be specific: what you saw vs. what you expected. Real examples for this tool:

you ▸ 'the preview doesn't update when I edit a bullet — rebuild the assembled issue live every time I change anything'
you ▸ 'my past issues disappear when I refresh — save each finished issue to a list on my device so they stay'
you ▸ 'the copied text has weird symbols and breaks in my email tool — give me clean plain text that pastes cleanly'

Don't stop at v1 — grow it

A tool you built in ten minutes is a starting point, not the finish line. The people who get hooked keep saying 'now also…'. Each line below is one sentence you paste into the same chat to level this tool up:

you ▸ 'add a subject-line field that connects the Claude API to suggest three options from this issue's content' — the hardest line to write writes itself.
you ▸ 'connect an email service like Buttondown or Mailchimp so I can send the finished issue to my subscribers' — it stops being a draft tool and actually mails.
you ▸ 'draft a one-line intro from this week's bullets so I'm not staring at a blank intro' — the section that always stalls you gets a head start.
you ▸ 'show a simple count of issues sent and let me search past issues by subject' — your archive becomes something you can actually mine.

Step 3 — Connect it to the world (optional)

Free data & APIs for this one

An API is just how your tool pulls in outside data or sends things out — many are free. You rarely need to research them yourself; the move that works for ANY idea is to ask the agent to find them:

  1. 1To start you need NO external API — sections, the live preview and the copy-ready text all run locally on your device.
  2. 2To actually SEND, wire in an email service (Buttondown or Mailchimp both have free tiers) — and for subject-line and tightening help, an AI service (Claude API or OpenAI) on a separate pay-as-you-go account; that AI part is the only piece that costs per use.
  3. 3Reusable move for ANY idea: ask Claude — 'find free or open APIs for sending a newsletter and tell me which actually need a key.' It will list them; you pick.

About paying for the AI parts

  1. 1You don't pay for Claude twice. With a Claude subscription you create an API key right in the terminal and use it inside your projects — within your plan.
  2. 2From June 15 the rule splits: automation through that key gets its own monthly credit — about $20 on Pro, $100 or $200 on Max. Stay under it and it works as before.
  3. 3Run out and you pay per use (pay-as-you-go); unused credit doesn't roll over. So check your account and see whether the included credit already covers what you're building.

A tool gets superpowers when it can talk to other services — send you a message, read a sheet, pull live data. Each service hands out an 'API key' (a long password that says 'this is me'). For THIS tool, the useful ones are:

Which keys this tool can use

  1. 1An email service (Mailchimp / Buttondown) — actually send the finished issue to your subscribers
  2. 2Claude API — suggest subject lines and tighten the draft (separate pay-as-you-go account)

Getting any key is the same recipe: log into the service → find Settings → 'API' or 'Developers' → 'Create key' → copy it → paste it to Claude once ('here's my key: …'). Claude stores it and you never touch it again.

Step 4 — Put it online (only if someone else needs it)

Who'd want this one online

Yes — put it online so you can write from anywhere and wire it to your email service to send for real.

Buy a server and a domain — like ordering groceries

  1. 1Server: sign up at a host (Hetzner, DigitalOcean…), click 'Create Server', pick Ubuntu + the cheapest size + PASSWORD login. SAVE the IP address and password it gives you. (Don't be scared — it's a few dollars a month, cancel anytime.)
  2. 2Domain: buy a name at any registrar (Namecheap, Cloudflare…). Then add ONE 'A record': Type = A, Host = @, Value = your server's IP. That's the whole DNS part — ignore every other field.
  3. 3Hand it to Claude: back in your terminal, say — 'deploy my project to my server. IP: <the ip>, password: <the password>, domain: <yourname.com>. Set up HTTPS and basic security, do it all yourself.' Claude installs everything, secures it, and makes it live. You configure nothing.
  4. 4DNS can take minutes to a couple of hours to wake up — if Claude says the domain isn't answering yet, that's the wait, not a mistake. Come back later and say 'try again'.

Step 5 — Keep your keys (so you can come back)

Save the server's IP, the password (or SSH key), and your domain somewhere safe — a notes app, a password manager. Why it matters: any day later you can open the terminal, connect to the server, start Claude right there, and keep improving the live tool by talking — fix a bug, add a feature, change the look. Tip: tell Claude 'save the server details in a file in this project folder' so a future chat already knows them.

Step 6 — Stay safe (two easy habits)

  1. 1Back up anything you'd hate to lose. If the tool holds real data (your budget, health log, client list), ask Claude early: 'add an export/backup button' — one click saves your data to a file. Do it before you ever rebuild from scratch or move the folder.
  2. 2Don't hand Claude the keys to dangerous rooms. Keep it pointed at this project's own folder. Never connect a learning project to your bank, your crypto, or anything irreversible. Receipts and calendars — yes. Savings — no.
  3. 3Think before you ask. Claude does what you say in the folder you're in. 'Optimize my photos' optimizes them; it won't delete them — unless you ask for something reckless. Sane requests, clean workspace, and there's simply nothing scary left.

The mistakes that stop most people

  1. 1Asking for something vague ('make me an app') and getting something vague back. Name the screens, the buttons, what gets saved.
  2. 2Cramming in ten features at once. Ask for the tiniest working version first — then grow it with follow-up requests.
  3. 3Stopping at the first error. An error isn't failure — paste it to Claude or describe what you see, and it fixes it. That loop IS the work.
  4. 4Deciding you need to 'learn programming first'. You don't need to understand the code Claude writes. You need to describe the result.
  5. 5Forgetting the magic line — 'build the whole thing, don't stop to ask questions' — then wondering why it keeps pausing.
  6. 6Building for an imaginary audience. Build the version YOU will open tomorrow. Polish never; use immediately.
!If something breaks

Normal. Tell Claude what's wrong in plain words ('the button does nothing', 'the page is blank') or paste the red error text. It finds and fixes it. You check. Repeat until it works.

checkpoint

That's it. You built a real tool.

Notice what just happened: no commands, no code — words. This is the entire skill. The people who 'can build things' are just people who describe what they want and let Claude do the typing.