12 steps to a new project — and the 4 that are still mine.

I’ve stood up seven of these now — a domain, a server, a site, a mascot, a social account that posts itself. Somewhere around the fourth one it stopped feeling like a project and started feeling like a routine, the way assembling the same bookshelf twice turns a manual into muscle memory.

And once it’s muscle memory, you notice the shape of it. There are twelve steps. Nine and a half of them, I don’t do anymore — an agent does them, on the server, without me. But four of them I do every single time, by hand, and I’m never going to hand them off. Not because the agent can’t — because it shouldn’t.

That seam — the line between the four jobs that stay mine and everything downstream of them — is the actual skill. Anyone can write down twelve steps. Knowing which four don’t leave your hands is the part that took seven tries to see clearly.

The whole assembly line, and who does what

#	Step	Whose hands
1	Pick and buy the domain	Me
2	Point DNS at the server	Me
3	Prep the server — user, nginx vhost, mailbox	Agent
4	Register the social + video handles	Me
5	Wire up the auto-posting API	Split
6	Decide the branding — and train the mascot	Agent (I decide)
7	Build the site and deploy it	Agent
8	Approve it, push it live	Me
9	Submit the sitemap to Google	Me
10	Stand up analytics	Agent (I grant)
11	Write the first post → turn it into a reel → publish	Split
12	Write down the skills for next time	Agent

Read the “Me” rows top to bottom and a pattern falls out. Buy a domain: that’s my money. Point DNS, verify to Google: that’s control I don’t lend out. Register the accounts: those are my name, my legal identity. Approve the build, approve the post: that’s my judgment. Money, control, identity, judgment. Four things a machine shouldn’t be holding. Everything else on that list is construction — and I stopped doing construction a while ago.

Here’s the walk, in order.

1–2. The domain, and pointing it (mine)

I buy the domain myself, because it costs money and because the name is the one decision on this whole list I can’t cheaply undo. That’s a post of its own — how I make Claude check twenty domains and handles in four seconds, and why the RDAP trick is the easy part and the naming judgment is the part I keep.

Then I point it at the server: one A record in the registrar dashboard, apex and www, both aimed at the Linode. This one stays mine on purpose. The registrar login is the master key to the whole brand — if someone owns your DNS, they own your email, your certs, your identity. It’s the last door I hold the only key to, so I turn it myself.

3. Prep the server (agent)

Now the agent takes over, and it takes over on the server itself. It SSHes into the Linode, makes a dedicated Unix user for the project, writes an nginx vhost, gets the TLS cert, and provisions a mailbox — the full skeleton. That whole dance is its own war story: Day 0: standing up the site.

There’s one handoff baked into this step, and it’s the rhythm the rest of the setup keeps returning to: the agent generates DNS records and hands them to me to paste. Mail is where it shows up first — the agent gives me an SPF line, a DKIM key at mail._domainkey, and a DMARC record; I drop them into the registrar (the door only I open) and tell it they’re live. Why I don’t self-host the sending, and the one collision that crossed two brands’ mail, is the email post. The point here is just the shape: it builds, it hands me the keys-and-identity parts, I place them.

4. Register the handles (mine)

Instagram, YouTube, Pinterest — whatever the project needs. I register these by hand, using the inbox the agent just made me a step ago. They’re mine because they’re accounts in my name: someone has to click “I agree,” and legally, morally, and practically that someone is me, not a script. The agent inherits the keys to them afterward. It doesn’t get to be born as me.

5. Wire up the auto-posting API (split — the interesting one)

This is the step people actually get stuck on, so here’s the whole thing, using Instagram because I’ve now done it five times.

The seam runs right down the middle of it:

• I go to developers.facebook.com and create the app, then add the Instagram product — specifically “Instagram API with Instagram Login,” not the old Facebook-Login-plus-Pages flow that half the outdated tutorials still show. Under App settings → Basic I copy the App ID and App secret, and paste them into the .env file the agent has already left waiting for me (IG_APP_ID, IG_APP_SECRET).
• I add my own Instagram account as a tester on the app, accept the invite from the IG side, then use the API setup tool to generate a token — a short-lived one that starts with IGAA. That goes in the .env too.
• The agent takes it from there: it exchanges my short-lived token for a long-lived (60-day) one, calls the Graph API to look up the account’s user ID, writes that back into the .env (IG_USER_ID, IG_ACCESS_TOKEN), and runs a dry publish to confirm the whole chain works end to end.

Look at what stayed mine: creating the app under my developer identity, and granting the token. An authorization and a credential — money’s cousins. Look at what the agent did: every API call, the token exchange, the ID lookup, the verification. Plumbing. I hand it a key; it builds the lock the key fits.

6. Branding, and the mascot (I decide, agent builds)

We settle the look together — the color swatch, the basic feel of the site, and the big fork: is there a mascot or not? That’s a judgment call, so it’s mine. If the answer is yes, the agent trains the character model, which is a whole craft I don’t do by hand either: you don’t hand-train a LoRA, you direct an agent to. The green heckler in these margins is what that step produces.

7. Build and deploy — without me logging in (agent)

The agent builds the entire site and deploys it, and here’s the part that still feels slightly illicit to say out loud: I never log into the server to do it. I work here, on my workstation — the machine with the fast CPU and the GPU that trains the mascots. The agent does all the remoting. It SSHes in, writes files, restarts nginx, rsyncs the build, checks the cert, all of it, itself.

That’s only safe because of one deliberate setting: the server refuses password logins entirely. Key-only auth. Most people hear “the AI has SSH access to my production box” and reach for the smelling salts — but a key-only server is more locked down for an agent than a password one is for a human. There’s no password to phish, guess, or leak into a log. The agent holds a key that lets it do the construction, and the construction is all it can do. It can’t buy a domain, can’t be me on Instagram, can’t approve its own work. The blast radius is exactly “the thing it was going to build anyway.”

8. Approve, and push live (mine)

The agent shows me what it built. I look at it with the one pair of eyes on the whole project that isn’t a language model, and I say yes or I say fix it. Then we push. This is the smallest step and the least automatable: it’s just judgment, the thing I’m keeping precisely because everything else got handed off.

9–10. Google, and analytics (mine, then granted)

I submit the sitemap to Google Search Console, which means proving I own the domain — Google hands me a TXT record, and I paste it into DNS. Same rhythm as the mail records in step 3, same reason it’s my hands: it’s a claim of ownership, and ownership is the thing that stays human.

Then I create the analytics property, which is an account in my name (there’s that identity line again), and hand the agent the measurement ID. It drops it into the site and redeploys. I own the property; it does the wiring.

11. First post → reel → published (split)

We write the first real piece of content together — the memoir-and-field-guide thing this whole blog is — and I approve it. Then the agent turns it into something for social, almost always a reel, because that’s how discovery actually works right now. I approve that too. And then it publishes, on its own, through the API we wired back in step 5. The freq post you may have just read shipped exactly this way: I wrote it with the agent, it built the reel, I approved both, it posted.

12. Write down the skills (agent — this is the whole point)

Here’s the step that turns a one-time setup into a machine. Once we’ve walked all eleven steps once, the agent writes it all down — a per-project folder of skills and notes, scoped to that one brand: where its files live, how it deploys, what its voice is, how it posts.

So the next time, I don’t run twelve steps. I open that folder and say four words: “let’s do today’s post.” And because of where it’s standing, the agent already knows the domain, the server user, the deploy command, the caption voice, the hashtags, the reel template — everything. We do a blog post and its social cutdown in a single push, and I go back to being the four things I’m keeping: the money, the control, the name, and the yes.

The seam, one more time

If you take one thing from this, don’t take the checklist — take the seam. The four jobs I keep aren’t the hard ones. Prepping a mail server is harder than pasting a DNS record; training a LoRA is harder than clicking “I agree.” I didn’t keep the hard steps. I kept the ones that touch my money, my control, my identity, and my judgment — because those are the four things I don’t want a background process to have, no matter how good it gets at the other eight.

Get that line in the right place and the rest of this genuinely does run itself. Get it wrong, and you’ve either given a script your credit card and your name, or you’re still doing your own rsync at midnight like it’s 2015. The whole trick is the seam.