I heard this constantly while founding my previous startup Trieve, and I bought into it. You can find old TikTok posts from August 2023, four months before we raised funding or got into YC. Then, ironically, some switch flipped once we became venture backed. The posting stopped. We turned inward and focused on product. It saddens me in hindsight, because our product was getting a whole lot better at exactly the moment we went quiet.

What Changed?

Startup media and accelerator programs create an expectation of a “launch” event, think of TechCrunch Disrupt in the Silicon Valley TV show, Supabase’s infamous “launch week”, and of course the OG themselves - ProductHunt.

I’m kind of an idiot and let being “post-fundraise” change my mindset. We felt like we had the capital to just burn money on ads when it made sense and therefore went heads down building in silence for some number of weeks to then pop our heads out once or twice a month and do a big launch event. That was, without question, horrendous strategy and terrible CEOing on my part.

The best comparison I can think of is composing a song out of nothing but thirty-second rests and cymbal crashes. People tune you out. Good marketing should feel more like an EDM track: a steady beat with the occasional drop. You want consistent content that people can engage with, punctuated every so often by a big announcement that gets them excited.

Executing the Slow Drip Launch

You can post and launch all of the small things you ship along the way to the final product. Get the login page working? Post about it. Add the ability to invite users into your org? Post about it. Put new actionable insights in the dashboard? Post about it.

Each of these is a chance to build awareness and improve your yapping abilities, so once your product is finally stable and working, you have the skillset and audience necessary to get a base of people familiar with it and excited to share.

The alternative is to put all your eggs in one basket and wait until you have a big announcement to make. This is the strategy that most startups follow, and it is a high-risk, low-reward play. If your launch goes viral, you can get a huge boost in awareness and users, but content on social media is rarely evergreen and gets buried in feeds quickly.

Your best case scenario is a couple days of electricity in return for weeks or months’ worth of work. And, worst case, your launch falls flat and you get literally nothing out of it.

Tactic #1: Personal Brands

I hate to quote Roy Lee, but he’s not wrong when he says “most of u tech ppl are doomed to be ngmi forever on x. ur just not funny or sarcastic or arrogant enough for this place”. Founders, including myself, are typically nerdy software-engineer type folks who are boring to the extent that building a personal brand on X or elsewhere is going to be a struggle.

However, I’m here to tell you that with enough failure, any skill issue can be overcome. It takes a lot more effort than being naturally interesting, but you absolutely can activitymax your way into an audience by posting a lot, replying, and engaging with people active in your niche online.

That’s not to say you can post terrible content nobody likes and succeed, you definitely do still have to aim to entertain, but you can pick that up as a skill over time. You just have to be comfortable posting into the void for a while until you start to figure it out. Failure is part of the process with marketing the same way it is with everything else.

The light at the end of the tunnel is that success on social media tends to compound. While it’s true that social media feeds are more competitive than ever and no longer show your content consistently to followers, there will be some people who consistently engage with your content and see it day after day.

Their engagement kind of serves as a core that makes your content count as a live shot on goal, so the platform you’re posting on at least tests if your content resonates with a wider audience. The size of that “test group” gets bigger as your following grows, and you therefore start to more consistently go viral over time.

Finally, I want to note that you should endeavor to not do this alone. Ideally you hire people or have co-founders and you all have different angles and audiences, so you can test different messaging and content styles to see what resonates as you build.

Imagine you have a classical cast - engineer, designer, and businessperson. Engineer can post knee-high sock photos about how you’re using Rust btw, the designer can share overdone figmas nobody’s ever going to build, and the businessperson can complain about how they were rejected by 67 VCs before getting their mom to finally write the first check.

Over time each person’s social graph will grow in different directions and you’ll be able to test product marketing messaging with different hooks and audiences to see what resonates the most so you can double down on the best possible angle for the big launch. Think jackass for startup marketing.

Tactic #2: Field Marketing

Host an event once you know what you’re building. If you put some money behind an open bar and a DJ and message some people an invite, you can usually get a pretty good turnout. You want to do your best to get people who you think have the problem your product solves to show up, but even if you just get a bunch of friends, it’s usually worth it.

At some point, probably about a third of the way through the event, grab a mic and talk for a few minutes about what you’re building. Don’t bother with a demo or presentation or video, just talk naturally about why you decided to nuke your future career prospects and work 996 for a 1% shot at building something people want. If you can get a few laughs and make it feel like a fun story, people will be more likely to remember it and share it with their friends.

Use something like Partiful to manage RSVPs and send reminders, and make sure to collect contact information from attendees so you can follow up with them after the event. Auto-enroll people who show up in your product newsletter and send them once a week updates about your progress. If you have a launch date, make sure to send them a reminder a few days before so they can be ready to support you on launch day.

I like this one because it’s pretty earnest and doesn’t require being funny or clever to execute well. If you can throw a good party and tell a good story, you can get a lot of mileage out of this tactic. Hosting “VIP Dinners” also tends to be a pretty good lead funnel and functions in the same way.

Tactic #3: Capitalizing on Trends

I think founders, including myself, are often stubborn when it comes to trend-driven marketing. We tend to feel like adding product features purely for the sake of “going viral” is a sellout move, and that we should only build things that are directly related to our product vision. While I do think it’s important to stay true to your vision, I also think it’s important to be flexible and adapt to trends when they make sense.

On that note, I think competitive surfing rounds are a reasonable proxy metaphor for how to think about this. When you’re in a surf competition, you’re only going to be allowed to be out in the water for a certain amount of time, so you have to be strategic about which waves you choose to ride. You want to pick the waves that are going to get you the most points, but you also want to make sure you’re not hesitating too long and missing out on rides that could be good but aren’t perfect.

You’re always under similar time pressure in startups, if you miss a growth goal for a single quarter or sometimes even month then it can be a huge problem for your employee retention and fundraising prospects. Therefore, you can’t afford to be too picky about which trends you choose to ride. If there’s a meme or topic that’s relevant to your product and has the potential to get you a lot of attention, you should probably jump on it and ship even if it’s not perfectly aligned with your vision.

On a lower level, my recommendation to get started on this is turning on post notifications for accounts in your niche that are good at this and more or less copying what they do. Reply to the same things they reply to, post about the same topics, and use the same formats. You can add your own twist to it and actually make product changes over time as you get more comfortable with the format and start to understand what resonates with your audience.

I’m Begging You to Post

If you take nothing else away from this, please for all that’s holy, just post. It increases your odds of getting lucky and making it by orders of magnitude. And, odds are nobody’s even going to see your content anyways, so stop worrying about embarrassing yourself.

Note: You can watch me write this blog post on video here on x.com!

Standups create anxiety. You hoard updates during the day because you need content for the meeting. You forget your blockers. You adjust your schedule to be in early, even if you work better at night.

I ran into this when I started my company. People join startups to escape corporate bureaucracy. When I tried to introduce morning standups, the early hires pushed back hard. It didn't feel like a startup move to them.

Given that, I went back to the drawing board to break down the actual utility of the meeting. A standup exists to distribute context so a team can parallelize work and maintain synchronization.

If that's the goal, you don't need a meeting.

The Process

1. Post your task list in a channel like #standup first thing in the morning

2. Edit the message to cross off tasks as you complete them throughout the day

Here's what one of those messages looks like.

- Fix login bug on staging
- Review Sarah's PR #234
- Write API docs for /users endpoint
- Sync with design on checkout flow

As you work, you come back and edit the message to cross things off.

- ~~Fix login bug on staging~~
- ~~Review Sarah's PR #234~~
- Write API docs for /users endpoint
- Sync with design on checkout flow

Advanced Version

Add timestamps if you want to track how long things are taking you or otherwise provide more context.

Today:
- [9:15-10:30] ~~Fix login bug on staging~~
- [10:30-11:00] ~~Review Sarah's PR #234~~
- [11:00-?] Write API docs for /users endpoint
- (no start time since previus task is unfinished) Sync with design on checkout flow

That's it. Everyone sees what you're working on. No meeting required.

We launched new community discord and slack bots recently at Mintlify and needed to do some customer marketing to let users who had large communities know about them.

Our goal was to send an email sequence to the ~3-10 people from each organization who we identified as being able to get value from the feature. Understand that the nature of this product is that once one person from an organization enables the bot, the task is complete, and we don't want to keep emailing everyone else from the org.

I thought this would be easy using any of the email marketing tools out there like Resend or Loops, but this was not the case. All of the available tools shockingly handle campaigns at a user instead of organization level.

None of them have the concept of "stop emailing this group when any member takes action." They're all built for individual drip campaigns, not org-level outreach.

Tool Selection

Claude Code has made me quite lazy insofar as I try to get everything I can done using it instead of doing things myself manually. Therefore my number one criteria when picking a tool to solve the above problem with was a large API surface that claude could work with.

Instantly was my final selection given its API was the most robust and well documented. It gave claude full access to campaigns, leads, and sequences while also being capable of sending webhooks on reply and unsubscribe events.

Kind of random aside but JAMstack architecture patterns are probably going to make a comeback with AI. I think tools like trpc are going to fall out of favor relative to openapi driven patterns that AI agents can better understand. Seperation of UI and business logic is the way forward if we want our apps to be accessible by AI.

Solution Architecture

The Instantly campaign holds the multi-email sequence and is configured to stop on reply. A lead upload script reads a CSV of contacts, groups them by company, and uploads them to Instantly with a companyName custom variable.

Then a webhook server listens for reply events, finds all leads from the same company, and marks them as "not interested" to stop their sequences.

CSV (company, email)
    → Upload Script
    → Instantly (leads with companyName)

Reply received
    → Instantly webhook
    → Webhook server
    → Find leads by companyName
    → Update lead status
    → Sequence stops for whole company

Creating the Campaign

The campaign itself is straightforward. Set stop_on_reply to true so Instantly stops the sequence for whoever replies, then define your email steps with delays between them.

curl -X POST https://api.instantly.ai/api/v2/campaigns \
  -H "Authorization: Bearer $INSTANTLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Feature Launch Outreach",
    "stop_on_reply": true,
    "stop_on_auto_reply": true,
    "sequences": [{
      "steps": [
        {"type": "email", "delay": 0, "variants": [{"subject": "...", "body": "..."}]},
        {"type": "email", "delay": 3, "variants": [{"subject": "...", "body": "..."}]}
      ]
    }]
  }'

Uploading Leads

The important bit is to include a companyName custom variable with every lead. Our webhook server uses that to find all leads from the same company and unsubscribe them on relevant events.

import csv
import requests

API_KEY = "your-api-key"
CAMPAIGN_ID = "your-campaign-id"

with open("contacts.csv") as f:
    reader = csv.DictReader(f)
    for row in reader:
        emails = row["emails"].split(";")
        company = row["company_name"]

        for email in emails:
            requests.post(
                "https://api.instantly.ai/api/v2/leads",
                headers={"Authorization": f"Bearer {API_KEY}"},
                json={
                    "email": email.strip(),
                    "company_name": company,
                    "custom_variables": {"companyName": company},
                    "campaign": CAMPAIGN_ID
                }
            )

Registering the Webhook

Tell Instantly to POST to your server whenever someone replies. You'll need the campaign ID from earlier.

curl -X POST https://api.instantly.ai/api/v2/webhooks \
  -H "Authorization: Bearer $INSTANTLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_hook_url": "https://your-server.com/webhook/reply",
    "event_type": "reply_received",
    "campaign_id": "your-campaign-id"
  }'

Webhook Server

This is the part that makes it all work. When anyone replies, the webhook server extracts the company name, queries Instantly for all leads with that company name, and updates each lead's status to stop their sequence.

const express = require('express');
const app = express();
app.use(express.json());

const API_KEY = process.env.INSTANTLY_API_KEY;
const CAMPAIGN_ID = process.env.CAMPAIGN_ID;

app.post('/webhook/reply', async (req, res) => {
  const event = req.body;

  if (event.event_type !== 'reply_received') {
    return res.json({ status: 'ignored' });
  }

  const leadEmail = event.lead_email;
  const companyName = event.lead?.company_name;

  if (!companyName) {
    return res.json({ status: 'ignored', reason: 'no company' });
  }

  // Find all leads from this company
  const leads = await findLeadsByCompany(companyName);

  // Stop all of them (except the one who replied, they're already stopped)
  for (const lead of leads) {
    if (lead.email !== leadEmail) {
      await stopLead(lead.email);
    }
  }

  res.json({ status: 'ok', stopped: leads.length - 1 });
});

// Instantly's API doesn't let you filter by company_name server-side.
// The search param only works on name/email. So we fetch all leads
// and filter client-side. For large campaigns, you'd want to cache
// this or build your own company->leads index.
async function findLeadsByCompany(companyName) {
  const leads = [];
  let cursor = null;

  do {
    const resp = await fetch('https://api.instantly.ai/api/v2/leads/list', {
      method: 'POST',
      headers: { 'Authorization': `Bearer ${API_KEY}`, 'Content-Type': 'application/json' },
      body: JSON.stringify({ campaign: CAMPAIGN_ID, starting_after: cursor })
    });
    const data = await resp.json();
    leads.push(...data.items);
    cursor = data.next_starting_after;
  } while (cursor);

  return leads.filter(lead => lead.company_name === companyName);
}

async function stopLead(email) {
  await fetch('https://api.instantly.ai/api/v2/leads/update-interest-status', {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${API_KEY}`, 'Content-Type': 'application/json' },
    body: JSON.stringify({ lead_email: email, interest_value: -1 })
  });
}

app.listen(3000);

You can host this anywhere that can receive HTTP requests. I used a cheap VPS with Docker behind Caddy for SSL. Other options include Cloudflare Workers, Railway, Render, AWS Lambda, or Vercel. The server is stateless, so any hosting that can run Node.js will work.

Someone Please Build This

This solution works, but it's more complex than it should be. The fact that I had to build a webhook server to get org-level behavior is absurd. This should be a checkbox in every B2B email tool.

What I actually want is to define groups of contacts by company, toggle "stop group on reply" as a campaign setting, and have the email tool handle it without webhooks.

If you're building email tools, please add this.

How I Communicate

I will always provide you with a quick response or answer, but will often go back and edit the message to clarify or poke at the topic with further thoughts over the course of the next hour or so. I believe word economy is important and try to be quiet if I have nothing valuable to respond with.

How to Get My Attention

Call my cell phone if you have my number. Otherwise, @ me on Slack. I strongly prefer that you call me though. Most of my texts are voice transcriptions and I tend to add emojis to communicate my intended tone. It's easier to get all that right over a phone call when things are urgent. My written communication can often be read with a tone I didn't intend.

If you are messaging me on Slack, try to do it in a shared channel. DMs create communication silos and I think they are usually more harm than good. Very few things actually need to be private. If you send me a DM that I think should be in a channel I will often just forward it there myself and continue the conversation in that new location in front of a larger group.

Planning

Please never send me a planning document. Communicate your idea in 3 paragraphs or less and text it to me. I detest opening 3 pages of workslop full of theory about an unstarted task.

If you really can't get it to work in a single message, make a Slack canvas. Anything is better than a document which lives in another piece of software I have to sign into and open.

1:1s

I like recurring 1:1s when they are about moving towards goals. If we can set something up where one of us is working towards something and we decide on steps to get there, then a recurring meeting is useful to continuously sync on that.

Progression is fun, and even more so when you keep track of it with someone who's invested in holding you accountable.

Feedback

I try to only give unprompted feedback when it's extremely specific and easy to understand. My mindset is that high-level feedback about a general topic or performance is only something that should be shared on request.

Please send me any feedback you think would be useful. Specificity is always good. I will try to improve where I can at all times.

What I Value

Please try to do something and fail before asking me for help. I find it much easier to help when you are actively experiencing a problem and want to solve it rather than just wanting my thoughts. Speaking extensively about strategy before doing something is almost always a waste of time.

I prioritize failure. You are usually some number of failures away from success, and I think you should try to get those over with as fast as you can so you reach success earlier. I get frustrated seeing people play it safe, always doing what they're good at, or ponder endlessly before closing the loop by launching and getting feedback.

My Quirks

I tend to be skeptical, sarcastic, and kind of a curmudgeon. Complexity is something I avoid on principle, even when it will save me time. Newfangled toys are something I rarely find valuable.

UX is important to me, but not so much UI. I would rather something be functional and easy to use than pretty. I don't think design is particularly valuable. Just solve the problem.

Hours and Availability

I don't sleep all that much and am easily awoken. 3am–8am are the hours I am typically hard to reach, but if you call my cell phone I will usually pick up. Just call me!

Direct pings are something which I always try to respond to as fast as possible. If it's important enough that you're annoyed with my response time being slow, again, call my cell.

What I'm Working On Improving

Writing, making videos, and marketing are the core skills I want to improve in the upcoming year. I would appreciate any feedback or ideas you may have for me in those areas.

You can safely ignore advice about coding agents that doesn't mention loop structure.

"Agent" is an overloaded term, so I want to clarify that I'm using simonw's definition of "a language model which runs tools in a loop to achieve a goal" when I say "agent" throughout this post.

If that doesn't make sense to you then read fly.io's guide on writing agents or ampcode's guide and try building your own micro-agent first before continuing. I promise it's a worthwhile exercise.

What is This Loop You Speak Of?

Consider this example prompt asking claude code to write a generateSlug function.

add a new function to the @index.ts file called `generateSlug` which accepts a blog post title and returns a URL-friendly slug

Sounds clear and like it should work right? WRONG! Watch the output below.

We're missing unicode characters, special characters, multiple spaces, edge cases. Curse javascript all you want, but this is our fault, not Claude's.

Our prompt doesn't give the agent anything to test against. You want something more like

look at @index.ts and start by making sure you have a way to unit test functions which get added to that file. Add jest and new ts files if you need to, add a new script to @package.json. Then scaffold a new generateSlug function in @index.ts, write robust tests for it covering unicode, special chars, multiple spaces, edge cases, run them, watch them fail, implement the slug generator until they all pass. Unit tests should be in the same index.ts file as the function implementation.

Watch this baby run!

It's all the agent loop!

The key difference is this phrase from the second prompt:

"run them, watch them fail, implement the slug generator until they all pass"

This gives the agent a loop condition, a test to run repeatedly while iterating. Without it, the agent takes one shot and stops. With it, the agent keeps working until satisfied.

Common Loop Condition Patterns

The pattern is always the same. Describe the work, specify validation, then tell the agent to iterate until the validation passes. Here are three templates you can adapt.

For new features

[describe feature], write tests for [key behaviors], run them, fix until they all pass

For bug fixes

reproduce the bug in [file/test], fix the issue, verify the bug no longer occurs and all tests pass

For build/compile issues

[make changes], run the build, fix any errors or type issues until it compiles successfully

All of the above patterns include some kind of check; either tasts pass or fail, builds succeed or error, bugs reproduce or don't. Agents can take these abstract descriptions and turn them into concrete tools which they can run over and over until the condition is met.

Prompting outside of this pattern is the equivalent of grabbing a jr dev 3 shots past Ballmer's peak and asking them to fix a bug.

Conclusion

Senior developers know what loop conditions work for different tasks. If you're junior and not sure what's appropriate for a given task, use the planning mode offered by claude code, cursor, or your coding agent of choice to help you craft them.

Good luck out there!

Yesterday I posted about shipping a feature to this blog from the passenger seat while driving to Apple Hill, CA from San Francisco. I SSH'd into my office desktop from my phone, prompted Claude to make the changes, tested them on my phone's browser, and pushed to production in 10 minutes. That post got 130k impressions and dozens of people asked for the setup.

This article walks through doing SSH-based mobile development with Claude Code. If you have a desktop that stays on (or a cheap VPS), you can get full terminal access from your phone with session persistence, port forwarding, and the ability to test your code on your actual mobile browser. The initial setup takes about 20 minutes and just works once configured.

The Architecture

The setup uses five standard Unix tools that work together without custom integration. A desktop runs Claude Code, tailscale creates a private network between your devices, termux gives you a real terminal on Android, SSH handles the connection, and tmux keeps your sessions alive when you disconnect.

Step 1: Setup Your Desktop

You need a computer that stays on. This could be a desktop at home, a desktop at your office, a cloud VM, or a home server. It doesn't need to be powerful. Claude Code just makes API calls, the actual compute happens at Anthropic.

I keep a desktop at my office that stays on 24/7. It's running Ubuntu with Claude Code installed. The computer does nothing else. It just sits there waiting for me to SSH in and start coding.

First, install Claude Code globally using npm. This gives you the claude command that you'll use to start coding sessions.

npm install -g @anthropics/claude-code

Next, install tmux for session persistence. When you disconnect from SSH (phone locks, network drops, whatever), tmux keeps your Claude Code session running in the background. When you reconnect, you pick up exactly where you left off.

sudo apt install tmux  # Ubuntu/Debian
brew install tmux      # macOS

With Claude Code and tmux installed, your desktop is ready to host your development sessions.

Step 2: Install Tailscale Everywhere

Tailscale creates a private network between all your devices. Your phone gets a stable IP address that can reach your desktop, even when you're on different networks. It just works.

On your desktop, run the Tailscale installer. The script will detect your OS and install the right package. Then bring up the Tailscale connection, which will prompt you to authenticate in your browser.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Install Tailscale on your phone from the Play Store. Sign in with the same account. Your devices are now on the same network.

You'll need your desktop's Tailscale IP address to connect from your phone. Grab it with this command.

tailscale ip -4

You'll get something like 100.64.0.5. That's your desktop's address on the Tailscale network. It's stable, it's private, and it works from anywhere.

Step 3: Install Termux on Your Phone

Termux is a terminal emulator for Android that gives you a real Linux environment. Not a toy terminal. A real one with bash, ssh, and full package management.

Install Termux from F-Droid, not the Play Store. The Play Store version is outdated and broken. Get it from https://f-droid.org/en/packages/com.termux/.

Once installed, you'll need to update the package repositories and install the SSH client. Termux uses pkg as its package manager, which is basically a wrapper around apt.

pkg update
pkg install openssh

With OpenSSH installed, Termux can now connect to your desktop over SSH.

Step 4: SSH Into Your Desktop

Now for the moment of truth. Open Termux and SSH to your desktop using the Tailscale IP you grabbed earlier. Replace 100.64.0.5 with your actual IP and your-username with your desktop username.

ssh your-username@100.64.0.5

The first time you connect, SSH will ask you to verify the host fingerprint. Type yes. Then enter your password.

You're in. You're now running a shell on your desktop, from your phone, over a secure encrypted connection that works anywhere you have internet.

Step 5: Use tmux for Session Persistence

tmux is what makes this whole setup practical. When you disconnect from SSH, your tmux session keeps running on the desktop. When you reconnect, you attach to the same session and everything is exactly where you left it.

You're now connected to your desktop via SSH from your phone. Start a new tmux session with a name you'll remember. I usually name mine after the project I'm working on.

tmux new -s code

This creates a session named "code". You can name it anything. Inside the tmux session, launch Claude Code and start working.

claude

Now you're coding. On your phone. Using Claude Code. Running on your desktop.

When you need to disconnect, don't exit Claude Code. Don't exit tmux. Just close Termux or let your phone lock. The tmux session stays running on your desktop.

Later, when you want to code again, SSH back in and reattach to your session. Everything will be exactly where you left it.

ssh your-username@100.64.0.5
tmux attach -t code

Your conversation with Claude is still there. Your file context is still loaded. You can continue your previous task immediately.

In the Apple Hill example from the intro, this is exactly what I did. I SSH'd in, ran tmux attach -t personalsite to reconnect to my development session, and told Claude to add a section about the Public Suffix List and make headings into clickable anchor links. The session had been running for days. I just picked up exactly where I'd left off.

Why This Works Better Than Custom Apps

Every startup trying to solve "Claude Code on mobile" is building abstractions on top of these primitives. They're not giving you anything you can't already do with SSH and Termux. They're just wrapping it in a prettier UI and charging for hosting.

When you do it yourself, you get several advantages.

Port forwarding just works. With Tailscale, your desktop's ports are directly accessible from your phone. No configuration, no exposing services to the public internet, no proxies adding latency. Your phone and desktop are on the same private network, so anything listening on your desktop is one IP address away.

Full CLI access to configure your environment. Want to run your dev server with --host so you can test on your phone's browser? Just add the flag. Need to adjust firewall rules, modify server configs, or install system packages? You have root access. Native mobile coding apps can't offer this level of control because it's too niche for their target users, but for power users it's essential.

Session persistence that actually works. tmux was built for this. Your session survives network disconnections, phone reboots, and SSH reconnects. You never lose your place.

Your own hardware. Your desktop has your SSH keys, your git credentials, your environment exactly how you configured it. You're not coding in a disposable cloud container.

The Mobile Experience

I'm not going to pretend coding on a phone is as good as coding on a desktop. It's not. The screen is small. The keyboard is mediocre. You can't see multiple files at once.

But Claude Code is different from traditional coding. You're not typing out functions character by character. You're describing what you want, reviewing Claude's changes, and approving or rejecting them. That workflow actually works on mobile.

The Apple Hill example wasn't cherry-picked. I've shipped real features from my phone. I've fixed production bugs while getting coffee. I've reviewed pull requests from the back of an Uber. It's not my primary development environment, but it's shockingly capable when I need it.

The key is that Claude Code is conversational. You're having a back-and-forth with an AI that writes code for you. That interaction model translates to mobile better than traditional text editing. You're reading more than you're typing, and phones are great for reading.

Practical Tips

Once you have the basic setup running, there are a few tweaks that make the mobile coding experience dramatically better. These aren't strictly necessary, but they'll save you time and frustration.

Test Your Changes on Your Phone's Browser

This is the killer feature. You're not just editing code remotely, you can test it on your phone while the dev server runs on your desktop.

When I was working on the blog changes from Apple Hill, I wanted to see how the clickable anchor links looked on mobile. The trick is starting your dev server with the --host flag, which makes it accessible on your Tailscale network instead of just localhost.

yarn dev --host

For Vite (which Astro uses), this binds the dev server to 0.0.0.0 instead of 127.0.0.1. For other frameworks: npm start -- --host for React, next dev -H 0.0.0.0 for Next.js, python manage.py runserver 0.0.0.0:8000 for Django.

Grab your desktop's Tailscale IP again if you forgot it.

tailscale ip -4

Then on your phone's browser, navigate to http://100.64.0.5:4321 (replace with your Tailscale IP and port).

You're now viewing your local dev server, running on your desktop 2.5 hours away, in your phone's browser. I saw the anchor links were styled wrong, told Claude to fix them, refreshed, confirmed they looked good, and pushed. The whole workflow took maybe 10 minutes.

You're developing with the actual target device in your hand. You can test responsive layouts, check mobile interactions, and iterate immediately instead of deploying to staging or waiting until you're back at your desk.

Use SSH Keys

Don't type your password every time you SSH. Generate an SSH key on your phone and add it to your desktop's authorized keys.

Open Termux and generate an ed25519 key (the modern standard). Then use ssh-copy-id to automatically add it to your desktop's authorized keys file.

ssh-keygen -t ed25519
ssh-copy-id your-username@100.64.0.5

Now you can SSH without a password.

Create an SSH Config

Make connecting easier by adding your desktop to your SSH config. Instead of typing ssh your-username@100.64.0.5 every time, you can create an alias. Make a file at ~/.ssh/config in Termux with this content.

Host desktop
    HostName 100.64.0.5
    User your-username

Now you can just type ssh desktop instead of remembering the IP and username.

Use a Better Keyboard

Termux works with external keyboards. I keep a small Bluetooth keyboard in my bag. When I'm actually trying to get work done on my phone, I pull out the keyboard. It makes a massive difference.

The phone screen is fine for reading. The keyboard makes typing bearable.

Set Up tmux Keybindings

tmux's default keybindings are terrible on mobile. Remap them to something sensible. On your desktop, create or edit ~/.tmux.conf and add these bindings. They make tmux way easier to use on a phone keyboard.

# Use Ctrl-A instead of Ctrl-B (easier to type)
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# Split panes with | and -
bind | split-window -h
bind - split-window -v

Now you can manage tmux sessions without finger gymnastics.

Run Multiple Sessions

You can have multiple tmux sessions for different projects. I usually have one for each repo I'm actively working on. Start them with descriptive names so you remember what's what.

tmux new -s backend
tmux new -s frontend
tmux new -s experiments

When you SSH in and want to see what sessions are running, list them.

tmux ls

Then attach to whichever one you want to work on.

tmux attach -t frontend

This keeps your different projects isolated. You can switch contexts just by attaching to a different session.

Security Considerations

You're SSH'ing into your desktop over the internet. That's a potential security risk if you do it wrong. Do it right with a few precautions.

Use Tailscale. Never expose SSH to the public internet. Use Tailscale to create a private network between your devices. Your SSH traffic stays encrypted and never touches the public internet directly.

Use SSH keys. Disable password authentication entirely. Keys are longer, stronger, and can't be brute-forced. Edit /etc/ssh/sshd_config on your desktop and set these values, then restart sshd.

PasswordAuthentication no
PubkeyAuthentication yes

Keep your phone secure. Your phone now has SSH access to your development machine. If someone steals your phone, they can access your desktop. Use a strong PIN or biometric lock. Enable disk encryption. Consider using a password manager for your SSH key passphrase.

Monitor SSH access. Check who's connected to your machine with who or w. Check SSH logs with sudo tail -f /var/log/auth.log. If you see connections you don't recognize, revoke SSH keys and investigate.

The threat model here is pretty mild. Your SSH traffic is encrypted. Your Tailscale network is private. The main risk is losing your phone, which is why phone security matters.

When This Doesn't Work

This setup assumes you have a desktop that stays on. If you don't, you need a cloud VM or a home server. That's still not a reason to use a third-party service. Just rent a $5/month VPS from DigitalOcean or Hetzner, install Tailscale and Claude Code, and SSH into it the same way.

This also assumes you're on Android. If you're on iOS, Termux isn't available. You'll need to use a different SSH client like Blink or Prompt. The rest of the setup is the same.

If you're on unstable internet, SSH can be frustrating. Mosh (mobile shell) is designed for high-latency or unreliable connections. Install it on both your phone and desktop, then use mosh desktop instead of ssh desktop. It handles disconnections gracefully and keeps your terminal responsive even on bad networks.

The Bottom Line

Mobile development with Claude Code doesn't require new infrastructure or custom applications. The components you need are SSH, Tailscale, Termux, and a desktop that stays on. These are standard Unix tools that have been solving remote access problems for decades.

SSH has been the standard for secure remote access since 1995. Tmux has provided session management since 2007. Tailscale is newer, but it's built on WireGuard, which has undergone extensive security audits. These tools are mature, well-documented, and widely deployed in production environments.

The underlying problem, accessing a remote development environment from a mobile device, was solved long before mobile coding became a focus. This approach applies those established solutions to Claude Code without requiring custom middleware or managed services.

If you have a desktop or VPS and 20 minutes for setup, you can have this working today. Install termux, configure tailscale, and connect via SSH. The workflow is straightforward and the tools are reliable.

Glory be to the AI overlords, who grant us the grace to code at the bar without shame.

This pattern isn't new. Multi-tenant SaaS has used tenant-id.foo.com subdomains forever. But the explosion of AI builders that spin up hundreds of new subdomains daily makes the certificate management problem more visible. You can't provision individual certificates for every generated app, you need wildcard certificates.

I'd never set this up before, but at Mintlify we had an internal hackathon today and I built my own AI app builder. That meant I finally had a good excuse to figure out how wildcard TLS actually works. I'm sharing what I learned so you can implement it too.

The Problem: Per-Tenant Certificates Don't Scale

If you provision individual certificates for each tenant, you're running ACME challenges for every new tenant signup, managing certificate renewals for potentially tens of thousands of certificates, and hitting rate limits from Let's Encrypt (50 certificates per registered domain per week). You need a better approach.

Wildcard Certificates: One Cert, Infinite Tenants

A wildcard certificate for *.foo.com covers all first-level subdomains. This means any subdomain directly under your base domain gets automatic TLS coverage with a single certificate.

tenant-a.foo.com     ✓
tenant-b.foo.com     ✓
tenant-xyz.foo.com   ✓

The wildcard certificate doesn't extend to the apex domain or nested subdomains, though. Here's what's explicitly excluded from coverage.

foo.com                      ✗ (apex domain)
api.tenant-a.foo.com         ✗ (nested subdomain)

For most multi-tenant systems, this is exactly what you want. One certificate, provisioned once, renewed automatically, and it works for every tenant you'll ever onboard.

Why You Must Use DNS-01 Challenges

To get a wildcard certificate from Let's Encrypt (or any ACME-compliant CA), you must use the DNS-01 challenge type. The more common HTTP-01 challenge doesn't work for wildcards.

With HTTP-01, the CA verifies domain ownership by requesting a specific file at http://your-domain/.well-known/acme-challenge/token. But for *.foo.com, there's no single HTTP endpoint to verify; the wildcard represents infinite possible subdomains.

DNS-01 solves this by verifying ownership at the DNS level. Your ACME client requests a wildcard certificate for *.foo.com, Let's Encrypt generates a challenge token, and you create a TXT record at _acme-challenge.foo.com with that token as the value.

Let's Encrypt queries public DNS for that TXT record, and if the record exists with the correct value, Let's Encrypt knows you control the domain and issues the certificate. This means your certificate provisioning system needs programmatic access to your DNS provider's API to create and delete TXT records on demand.

How DNS-01 Automation Works

The key to wildcard certificates is automating the DNS-01 challenge. This requires your web server or load balancer to have API access to your DNS provider. When Let's Encrypt needs to verify domain ownership, your system creates a temporary TXT record, waits for DNS propagation, completes the challenge, and cleans up the record.

I'm using Caddy as my reverse proxy with Cloudflare as my DNS provider, but the architecture is the same regardless of your stack. Nginx with cert-manager on Kubernetes works the same way. HAProxy with acme.sh works the same way. The pattern is universally web server + DNS provider plugin + ACME client = automated wildcard certificates.

The Architecture (Cloudflare Example)

The system has three layers. Caddy is the web server that needs TLS certificates. The caddy-dns/cloudflare module is a thin adapter (only ~120 lines of Go) that sits between Caddy and the actual DNS API client. The libdns/cloudflare package handles the real work of talking to Cloudflare's API.

Caddy handles the web server and ACME logic, certmagic handles certificate management and renewal, libdns/cloudflare handles DNS API calls, and the plugin just connects them together.

This same pattern exists for every major DNS provider. There's caddy-dns/route53 for AWS, caddy-dns/googleclouddns for GCP, caddy-dns/azure for Azure, and plugins for dozens of other providers. The code structure is nearly identical, you just swap the API client.

Building Caddy with DNS Provider Support

Standard Caddy doesn't include DNS provider modules. You need to build a custom binary with the plugin compiled in. For Cloudflare we add some go modules and a community plugin.

# Install xcaddy (Caddy's build tool)
go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest

# Build Caddy with the Cloudflare DNS plugin
xcaddy build --with github.com/caddy-dns/cloudflare

This uses Caddy's module system to compile the plugin into a single binary. The result is a caddy executable that includes the DNS provider integration.

For other providers, just swap the module name --with github.com/caddy-dns/route53 for AWS, --with github.com/caddy-dns/googleclouddns for GCP, --with github.com/caddy-dns/azure for Azure. You can even include multiple providers if you manage domains across different DNS platforms.

Configuring Your Caddyfile

Once you've built Caddy with the DNS provider plugin, the actual configuration is remarkably simple. Here's the complete configuration for wildcard TLS with automatic provisioning and renewal.

*.foo.com {
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }

    # Your reverse proxy config
    reverse_proxy localhost:8000
}

Three lines of TLS configuration, and you get automatic wildcard certificate provisioning, automatic renewal 30 days before expiration, DNS-01 challenges handled transparently, and zero maintenance.

Getting DNS Provider Credentials

Your web server needs API credentials to manage DNS records. The specific permissions required are consistent across providers. You need read access to list zones/domains, and write access to create and delete TXT records.

For Cloudflare, create an API token at https://dash.cloudflare.com/profile/api-tokens with Zone.Zone:Read and Zone.DNS:Edit permissions. For AWS Route53, create an IAM user or role with route53:ListHostedZones, route53:GetChange, and route53:ChangeResourceRecordSets permissions. For GCP Cloud DNS, create a service account with the dns.admin role scoped to your DNS zone.

The key is following the principle of least privilege, grant only the permissions needed for DNS challenge automation, nothing more.

export CF_API_TOKEN="your_token_here"

The {env.CF_API_TOKEN} placeholder in the Caddyfile will be replaced with this value when Caddy starts.

What Happens Under the Hood

When you start Caddy, here's the complete flow.

1. Configuration Parsing

Caddy reads your Caddyfile and encounters the dns cloudflare directive. The plugin's UnmarshalCaddyfile() function extracts the token from {env.CF_API_TOKEN}.

2. Token Validation

The plugin validates the token format with a regex: ^[A-Za-z0-9_-]{35,50}$. This catches common mistakes like wrapping the token in quotes or braces, which would cause cryptic API errors later.

3. Module Provisioning

Caddy calls the plugin's Provision() function, which replaces environment variable placeholders with actual values and performs final validation.

4. Certificate Check

Caddy checks its certificate cache (default ~/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/) to see if a valid certificate for *.foo.com already exists. If so, it loads it and you're done.

5. ACME Challenge Request

If no valid certificate exists, Caddy's ACME client requests a certificate from Let's Encrypt. Let's Encrypt responds with a DNS-01 challenge of "Prove you control foo.com by creating a TXT record at _acme-challenge.foo.com with value xyz123_random_token."

6. DNS Record Creation

Here's where the magic happens. The plugin calls your DNS provider's API to create the challenge record. The specifics vary by provider, but the pattern is universally to find the zone ID, create a TXT record, and return success.

The Cloudflare implementation illustrates this pattern clearly. The libdns/cloudflare client makes two API requests. First, it queries for the zone ID.

GET https://api.cloudflare.com/client/v4/zones?name=foo.com
Authorization: Bearer your_token_here

Once the zone ID is retrieved, the client creates the TXT record with the challenge token.

POST https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records
Authorization: Bearer your_token_here
Content-Type: application/json

{
  "type": "TXT",
  "name": "_acme-challenge.foo.com",
  "content": "xyz123_random_token",
  "ttl": 120
}

This creates the challenge TXT record with a short TTL (2 minutes). AWS Route53 uses ChangeResourceRecordSets, GCP uses managedZones.changes.create, Azure uses their DNS REST API. Different endpoints, same result.

7. DNS Propagation Wait

Caddy polls public DNS servers to verify the TXT record has propagated. By default, it uses your system's DNS resolver, but you can configure a custom resolver.

*.foo.com {
    tls {
        dns cloudflare {env.CF_API_TOKEN}
        resolvers 1.1.1.1
    }
}

Using your DNS provider's public resolver (1.1.1.1 for Cloudflare, 8.8.8.8 for Google, 1.0.0.1 for general use) is often faster because DNS records propagate to the provider's own resolvers first. Caddy makes repeated queries until the record returns the expected value, then proceeds. This step is critical—if DNS propagation is incomplete when Let's Encrypt checks, the challenge fails.

8. Challenge Completion

Caddy tells Let's Encrypt "The TXT record is ready, check it." Let's Encrypt queries multiple DNS servers worldwide to verify the record exists. Once verified, Let's Encrypt issues the wildcard certificate.

9. Cleanup

Once the certificate is issued, the challenge TXT record is no longer needed. The plugin automatically deletes the temporary TXT record to keep your DNS zone clean.

DELETE https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}
Authorization: Bearer your_token_here

10. Certificate Storage

Caddy stores the certificate chain and private key in its certificate cache. The certificate is now ready to use for all *.foo.com traffic.

11. Automatic Renewal

Caddy automatically renews certificates 30 days before expiration. The entire DNS-01 challenge flow repeats automatically—create TXT record, wait for propagation, complete challenge, and finally delete TXT record. All with zero human intervention.

The Code: How the Plugin Works

The entire plugin is just ~120 lines of Go. Let's look at the key parts.

Module Registration

The first step is registering the plugin with Caddy's module system so it can be discovered and loaded at runtime. Here's how the Cloudflare provider registers itself.

type Provider struct{ *cloudflare.Provider }

func init() {
    caddy.RegisterModule(Provider{})
}

func (Provider) CaddyModule() caddy.ModuleInfo {
    return caddy.ModuleInfo{
        ID:  "dns.providers.cloudflare",
        New: func() caddy.Module { return &Provider{new(cloudflare.Provider)} },
    }
}

The plugin wraps github.com/libdns/cloudflare and registers itself as a Caddy module with the ID dns.providers.cloudflare. When you write dns cloudflare in your Caddyfile, Caddy loads this module.

Caddyfile Parsing

The parsing logic handles both inline and block configuration syntaxes, giving you flexibility in how you structure your Caddyfile. Here's how it works.

func (p *Provider) UnmarshalCaddyfile(d *caddyfile.Dispenser) error {
    d.Next() // consume directive name

    if d.NextArg() {
        // Single token syntax: cloudflare {env.CF_API_TOKEN}
        p.Provider.APIToken = d.Val()
    } else {
        // Block syntax: cloudflare { api_token ... }
        for nesting := d.Nesting(); d.NextBlock(nesting); {
            switch d.Val() {
            case "api_token":
                if d.NextArg() {
                    p.Provider.APIToken = d.Val()
                }
            case "zone_token":
                if d.NextArg() {
                    p.Provider.ZoneToken = d.Val()
                }
            }
        }
    }

    if p.Provider.APIToken == "" {
        return d.Err("missing API token")
    }
    return nil
}

This implementation supports both inline syntax for simple cases and block syntax when you need multiple configuration options. Here are the two supported formats.

# Inline syntax (recommended)
dns cloudflare {env.CF_API_TOKEN}

# Block syntax (for dual tokens)
dns cloudflare {
    api_token {env.CF_API_TOKEN}
}

Token Validation

Before making any API calls, the plugin validates that the token format is correct. This catches configuration errors early with clear error messages. Here's the validation logic.

var cloudflareTokenRegexp = regexp.MustCompile(`^[A-Za-z0-9_-]{35,50}$`)

func (p *Provider) Provision(ctx caddy.Context) error {
    // Replace placeholders like {env.CF_API_TOKEN} with actual values
    p.Provider.APIToken = caddy.NewReplacer().ReplaceAll(p.Provider.APIToken, "")

    if !cloudflareTokenRegexp.MatchString(p.Provider.APIToken) {
        return fmt.Errorf("API token '%s' appears invalid", p.Provider.APIToken)
    }
    return nil
}

This validates the token format before attempting any API calls. Cloudflare tokens are always 35-50 characters of alphanumerics, dashes, or underscores. If you accidentally wrap the token in quotes or the environment variable is unset, this catches it immediately with a clear error message instead of a cryptic "Invalid request headers" from Cloudflare later.

The Actual DNS Operations

The plugin doesn't implement DNS operations directly. It delegates to libdns/cloudflare, which implements the libdns interface.

type RecordSetter interface {
    SetRecords(ctx context.Context, zone string, records []Record) ([]Record, error)
}

type RecordDeleter interface {
    DeleteRecords(ctx context.Context, zone string, records []Record) ([]Record, error)
}

Caddy's ACME client calls these methods at the appropriate times during the DNS-01 challenge. The plugin is just the adapter that makes Caddy aware of the Cloudflare DNS provider.

Debugging and Common Issues

"Invalid request headers"

This error means your API token is malformed or the environment variable isn't set. The first step is to verify the token environment variable is properly configured.

echo $CF_API_TOKEN

If the output is empty, you've found the problem. When the environment variable isn't set, Caddy tries to use {env.CF_API_TOKEN} literally as the token, which results in authentication failures from your DNS provider's API.

"timed out waiting for record to fully propagate"

The DNS propagation check is timing out. This usually means DNS caching is happening—your local resolver is caching the old "record doesn't exist" response, so use a custom resolver like resolvers 1.1.1.1 in your TLS block. Or it's a private DNS issue where foo.com is defined in /etc/hosts or resolved by a private DNS server, causing the public DNS verification to fail. Use a public resolver or temporarily remove the private DNS entry. Finally, it could be zone access—the token doesn't have access to the zone, so verify the token has Zone:Read permission for foo.com.

"expected 1 zone, got 0"

The plugin can't find the zone for your domain. This happens if the domain isn't in Cloudflare DNS, the API token doesn't have Zone:Read permission, or the zone name doesn't match (e.g., you're requesting *.sub.foo.com but only foo.com is in Cloudflare).

Certificate Transparency Logs

All certificates issued by public CAs are logged to Certificate Transparency logs. You can see your wildcard cert at https://crt.sh. Search for %.foo.com to find wildcard certificates.

This is a feature, not a bug. It proves certificates were issued legitimately and helps detect mis-issuance. But it also means anyone can see that foo.com has a wildcard certificate, though they can't enumerate individual tenant subdomains.

Production Deployment Patterns

Docker Compose

For containerized deployments, Docker Compose provides a straightforward way to run Caddy with persistent certificate storage. Here's a complete configuration.

services:
  caddy:
    build:
      context: .
      dockerfile: Dockerfile.caddy
    ports:
      - "443:443"
      - "80:80"
    environment:
      - CF_API_TOKEN=${CF_API_TOKEN}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

The caddy_data volume persists certificates across container restarts. The caddy_config volume persists Caddy's runtime configuration.

Dockerfile with Cloudflare Plugin

FROM caddy:builder AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/cloudflare

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

This multi-stage build compiles Caddy with the Cloudflare plugin in the builder stage, then copies just the binary to the final image.

Kubernetes with Cert-Manager

If you're running Kubernetes, consider using cert-manager instead of running ACME clients on your web servers. Cert-manager is purpose-built for Kubernetes certificate lifecycle management and supports DNS-01 challenges with all major cloud providers.

Here's an example with Cloudflare, but cert-manager has built-in support for Route53, Cloud DNS, Azure DNS, and dozens of other providers.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-foo-com
spec:
  secretName: wildcard-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - "*.foo.com"
  - "foo.com"
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@foo.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - dns01:
        cloudflare:
          email: admin@foo.com
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token

Cert-manager provisions the certificate as a Kubernetes Secret, which your Ingress controller (nginx, Traefik, Envoy, etc.) can reference. The dns01 solver configuration changes based on your provider—swap cloudflare for route53, clouddns, or azuredns with the appropriate credential references.

Multi-Region Deployments

If you're running web servers in multiple regions, certificate storage becomes important. File-based storage works for single-server deployments, but multi-region requires shared certificate storage.

You have three options, mount the certificate directory from a network filesystem like NFS, EFS, or cloud-provider equivalents, use storage plugins for S3, Consul, Redis, or other distributed stores, or run certificate provisioning centrally and distribute via your secrets management system.

The simplest approach for most systems is to run certificate provisioning in one region, store certificates in your cloud provider's secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault), and distribute to all regions. This keeps the ACME logic centralized while making certificates available everywhere.

Security Considerations

The wildcard certificate's private key protects all your tenant subdomains. If it leaks, an attacker can impersonate any tenant. Protect it like you'd protect your database credentials.

Adding Your Domain to the Public Suffix List

If you're running a multi-tenant platform where each tenant gets a subdomain, you should submit your domain to the Public Suffix List. The PSL is a registry that browsers use to determine security boundaries between sites.

Without PSL registration, browsers treat tenant-a.foo.com and tenant-b.foo.com as the same site. This means one tenant could potentially set cookies readable by another tenant, creating security and privacy issues.

When you add foo.com to the PSL, browsers treat each tenant subdomain as an independent site. Cookies set by tenant-a.foo.com cannot be read by tenant-b.foo.com. This provides proper isolation between tenants at the browser level.

Major platforms like GitHub (github.io), Vercel (vercel.app), and Netlify (netlify.app) are all registered on the PSL. If you're building tenant infrastructure, you should be too. Submit via the PSL GitHub repository with documentation proving you control the domain and explaining your multi-tenant use case.

Token Scope Limiting

Your DNS provider credentials should have the minimum required permissions. For Cloudflare, scope tokens to specific zones with only Zone.Zone:Read and Zone.DNS:Edit. For AWS Route53, use IAM policies that grant access only to specific hosted zones, not all DNS resources in your account. For GCP Cloud DNS, create service accounts with the dns.admin role scoped to individual zones, not project-wide access.

Don't use global credentials. If your token leaks, the blast radius should be limited to DNS operations on specific zones, not your entire cloud account or DNS infrastructure.

Certificate Revocation

If you need to revoke a wildcard certificate, you can't selectively revoke it for one tenant, revocation affects all tenants. This is a fundamental tradeoff of wildcard certificates.

If you need per-tenant revocation capability, you need per-tenant certificates. For most systems, the operational simplicity of wildcards outweighs this limitation.

Rate Limits

Let's Encrypt rate limits are 50 certificates per registered domain per week, 5 failed validation attempts per account per hostname per hour, and 300 new orders per account per 3 hours. With a wildcard certificate, you're provisioning one certificate regardless of tenant count, so you'll never hit the 50 certificates per week limit. This is a massive advantage over per-tenant certificates.

When NOT to Use Wildcard Certificates

Skip wildcards if tenants bring their own domains. If tenants use tenant-a.com instead of tenant-a.foo.com, you need per-tenant certificates. You can still automate this with ACME HTTP-01 challenges, but you'll need per-tenant certificate management.

Skip them if you need deep subdomain nesting. Wildcards only cover one level—*.foo.com doesn't cover api.tenant-a.foo.com. If your architecture requires nested subdomains, you either need multiple wildcard certificates or per-tenant certificates.

Skip them if regulatory compliance requires certificate isolation. Some compliance frameworks require cryptographic isolation between tenants. If your wildcard private key is compromised, all tenants are affected. For these environments, per-tenant certificates provide isolation.

Skip them if you need per-tenant certificate revocation. If you might need to revoke access for individual tenants by revoking their certificate, wildcard certificates won't work.

The Bottom Line

For multi-tenant systems with tenant-id.foo.com subdomains, wildcard certificates are the right choice. The implementation pattern is the same regardless of your infrastructure, pick a web server (Caddy, Nginx, HAProxy), integrate with your DNS provider's API (Cloudflare, Route53, Cloud DNS, Azure DNS), and let ACME automation handle the rest.

The alternative, per-tenant certificates, is operationally complex, technically fragile, and doesn't scale past a few hundred tenants. Wildcard certificates are the pragmatic choice, and modern tooling makes them trivial to implement across any cloud platform.

If you're building tenant-id.foo.com infrastructure, this is the way.

I decided to make my Astro sites more accessible to LLMs by having them return Markdown versions of pages when the Accept header has text/plain or text/markdown preceding text/html. This was very heavily inspired by this post on X from bunjavascript.

Hopefully this helps SEO too, since agents are a big chunk of my traffic. The Bun team reported a 10x token drop for Markdown and frontier labs pay per token, so cheaper pages should get scraped more, be more likely to end up in training data, and give me a little extra lift from assistants and search.

Note: You can check out the feature live by running curl -H "Accept: text/markdown" https://www.skeptrune.com or curl -H "Accept: text/plain" https://www.skeptrune.com in your terminal.

Static Site Generators are already halfway there

Static site generators like Astro and Gatsby already generate a big folder of HTML files, typically in a dist or public folder through an npm run build command. The only thing missing is a way to convert those HTML files to markdown.

It turns out there's a great CLI tool for this called html-to-markdown that can be installed with npm install -D @wcj/html-to-markdown-cli and run during a build step using npx.

Here's a quick Bash script an LLM wrote to convert all HTML files in dist/html to Markdown files in dist/markdown, preserving the directory structure:

# convert-to-markdown.sh
mkdir -p dist/markdown

find dist/html -type f -name "*.html" | while read -r file; do
    relative_path="${file#dist/html/}"
    dest_path="dist/markdown/${relative_path%.html}.md"
    mkdir -p "$(dirname "$dest_path")"
    npx @wcj/html-to-markdown-cli "$file" --stdout > "$dest_path"
done

Once you have the conversion script in place, the next step is to make it run as a post-build action. Here's an example of how to modify your package.json scripts section:

"scripts": {
    "build": "astro build && yarn mv-html && yarn convert-to-markdown",
    "mv-html": "mkdir -p dist/html && find dist -type f -name '*.html' -not -path 'dist/html/*' -exec sh -c 'for f; do dest=\"dist/html/${f#dist/}\"; mkdir -p \"$(dirname \"$dest\")\"; mv -f \"$f\" \"$dest\"; done' sh {} +",
  "convert-to-markdown": "bash convert-to-markdown.sh"
}

Moving all HTML files to dist/html first is only necessary if you're using Cloudflare Workers, which will serve existing static assets before falling back to your Worker. If you're using a traditional reverse proxy, you can skip that step and just convert directly from dist to dist/markdown.

Note: I learned after I finished the project that I could have added run_worker_first = ["*"] to my wrangler.json so I didn't have to move any files around. That field forces the worker to always run frst. Shoutout to the kind folks on reddit for telling me.

Cloudflare Workers-specific configuration

I pushed myself to go out of my comfort zone and learn Cloudflare Workers for this project since my company uses them extensively. If you're using a traditional reverse proxy like Nginx or Caddy, you can skip this section (and honestly, you'll have a much easier time).

If you're coming from traditional reverse proxy servers, Cloudflare Workers force you into a different paradigm. What would normally be a simple Nginx or Caddy rule becomes custom wrangler.jsonc configuration, moving your entire site to a shadow directory so Cloudflare doesn't serve static assets by default, writing JavaScript to manually check headers and using env.ASSETS.fetch to serve files. SO MANY STEPS TO MAKE A SIMPLE FILE SERVER!

This experience finally made Next.js 'middleware' click for me. It's not actually middleware in the traditional sense of a REST API; it's more like 'use this where you would normally have a real reverse proxy.' Both Cloudflare Workers and Next.js Middleware are essentially JavaScript-based reverse proxies that intercept requests before they hit your application.

While I'd personally prefer Terraform with a hyperscaler or a VPS for a more traditional setup, new startups love this pattern, so it's worth understanding.

Here's an example of a working wrangler.jsonc file to refer to a new worker script and also bind your build output directory as a static asset namespace:

{
  "main": "worker.js",
  "assets": {
    "directory": "./dist",
    "binding": "ASSETS"
  }
}

Below is a minimal worker script that inspects the Accept header and serves markdown when requested, otherwise falls back to HTML:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const acceptHeader = request.headers.get("accept") || "";
    const acceptTypes = acceptHeader.split(",");

    const plainIndex = acceptTypes.findIndex(
      (t) => t.includes("text/plain") || t.includes("text/markdown")
    );
    const htmlIndex = acceptTypes.findIndex((t) => t.includes("text/html"));
    const prefersMarkdown =
      plainIndex !== -1 && (htmlIndex === -1 || plainIndex < htmlIndex);

    const tryServeContent = async (format) => {
      let contentType;
      if (format === "markdown") {
        if (url.pathname == "" || url.pathname == "/") {
          const sitemapResponse = await env.ASSETS.fetch(
            new Request(new URL("/sitemap-0.xml", request.url))
          );
          if (sitemapResponse.ok) {
            const content = await sitemapResponse.text();
            return new Response(content, {
              headers: {
                "Content-Type": "application/xml; charset=utf-8",
                "Cache-Control": "public, max-age=3600",
              },
            });
          }
        }

        contentType = "text/plain; charset=utf-8";
        let distPath = `/markdown${url.pathname}`;

        if (!distPath.endsWith(".md") && !distPath.endsWith("/")) {
          distPath += "/index.md";
        } else if (distPath.endsWith("/")) {
          distPath += "index.md";
        }

        if (url.pathname === "/") {
          distPath = "/markdown/index.md";
        }

        try {
          const response = await env.ASSETS.fetch(
            new Request(new URL(distPath, request.url))
          );
          if (response.ok) {
            const content = await response.text();
            return new Response(content, {
              headers: {
                "Content-Type": contentType,
                "Cache-Control": "public, max-age=3600",
              },
            });
          }
        } catch (error) {
          console.error(`Error fetching HTML file from ${distPath}:`, error);
        }
      } else {
        contentType = "text/html; charset=utf-8";
        let distPath = `/html${url.pathname}`;

        if (!distPath.endsWith(".html") && !distPath.endsWith("/")) {
          distPath += "/index.html";
        } else if (distPath.endsWith("/")) {
          distPath += "index.html";
        }

        // Handle root path
        if (url.pathname === "/") {
          distPath = "/html/index.html";
        }

        try {
          const response = await env.ASSETS.fetch(
            new Request(new URL(distPath, request.url))
          );
          if (response.ok) {
            const content = await response.text();
            return new Response(content, {
              headers: {
                "Content-Type": contentType,
                "Cache-Control": "public, max-age=3600",
              },
            });
          }
        } catch (error) {
          console.error(`Error fetching HTML file from ${distPath}:`, error);
        }
      }

      return null;
    };

    if (prefersMarkdown) {
      const markdownResponse = await tryServeContent("markdown");
      if (markdownResponse) return markdownResponse;

      const htmlResponse = await tryServeContent("html");
      if (htmlResponse) return htmlResponse;
    } else {
      const htmlResponse = await tryServeContent("html");
      if (htmlResponse) return htmlResponse;

      const markdownResponse = await tryServeContent("markdown");
      if (markdownResponse) return markdownResponse;
    }

    return await env.ASSETS.fetch(
      new Request(new URL("/html/404.html", request.url))
    );
  },
};

Pro tip: make the root path / serve your sitemap.xml instead of markdown content for your homepage such that an agent visiting your root URL can see all the links on your site.

Caddy configuration

It's likely much easier to set this system up with a traditional reverse proxy file server like Caddy or Nginx. Here's a simple Caddyfile configuration that does the same thing:

{
    your-personal-domain.com {
        root * /path/to/your/dist
        file_server

        @markdown {
            header Accept *text/markdown*
            header Accept *text/plain*
            not header Accept *text/html*
        }
        handle @markdown {
            rewrite * /markdown{path}/index.md
            try_files {path} {path}.md /markdown/index.md
            file_server
        }

        handle {
            rewrite * /html{path}/index.html
            try_files {path} {path}.html /html/index.html
            file_server
        }

        handle_errors {
            respond "404 Not Found" 404
            try_files /html/404.html
        }
    }
}

I will leave Nginx configuration as an exercise for the reader or perhaps the reader's LLM of choice.

Conclusion: A More Accessible Web for Agents

By serving lean, semantic Markdown to LLM agents, you can achieve a 10x reduction in token usage while making your content more accessible and efficient for the AI systems that increasingly browse the web. This optimization isn't just about saving money; it's about GEO (Generative Engine Optimization) for a changed world where millions of users discover content through AI assistants.

Astro's flexibility made this implementation surprisingly straightforward. It only took me a couple of hours to get both the personal blog you're reading now and patron.com to support this feature.

If you're ready to make your site agent-friendly, I encourage you to try this out. For a fun exercise, copy this article's URL and ask your favorite LLM to "Use the blog post to write a Cloudflare Worker for my own site." See how it does! You can also check out the source code for this feature at github.com/skeptrunedev/personal-site to get started.

I'm excited to see the impact of this change on my site's analytics and hope it inspires others. If you implement this on your own site, I'd love to hear about your experience! Connect with me on X or LinkedIn.

Being on the Struggle Bus Early

When I was starting out hacking as a kid, one of the first complete things I built was a weather reply bot for Twitter. It read from the firehouse API, monitored for mentions and city names, then replied with current weather conditions when it got @'ed. My parents got me a Raspberry Pi for Christmas and I found a tutorial online. I got it working locally and then got completely stuck on deployment.

The obvious next step was using my Pi as a server, but that was a disaster. My program had bugs and would crash while I was away. Then I couldn't SSH back in because my house didn't have a static IP and Tailscale wasn't a thing yet. It only worked on and off when I was home and could babysit it.

Skipping Straight to PaaS Hell

When I started building web applications, I somehow skipped VPS entirely and went straight to Platform as a Service Solutions like Vercel and Render. I have no idea why. I was googling "how do I deploy my create react app" and somehow the top answer was to deploy to some third-party service that handled build steps, managed SSL, and was incredibly complicated and time-consuming.

There was always some weird limitation: memory constraints during build, Puppeteer couldn't run because they didn't have the right apt packages. Then I was stuck configuring Docker images, and since AI wasn't a thing yet and I'd never used Docker at a real job, it was all a disaster. I wasted more time trying to deploy my crappy React slop than building it.

Getting Saved by a VPS Maximalist

During college, I got lucky and met a hacky startup entrepreneur who was hiring. I decided to take a chance and join, even though the whole operation seemed barely legitimate.

Going into the job, I had this assumption that the "right" way to deploy was on AWS or some other hyperscaler. But this guy's mindset was the complete opposite—he was a VPS maximalist with a beautifully simple philosophy: rent a VPS, SSH in, do the same thing you did locally (yarn dev or whatever), throw up a reverse proxy, and call it a day. I watched him deploy like this over and over, and eventually he walked me through it myself a few times.

It was all so small and easy to learn, but it made me exponentially more confident as a builder. I never directly thought, "I can't build this because I won't be able to deploy it," but the general insecurity definitely caused a hesitancy and procrastination that immediately went away.

Paying It Forward

I've become an evangelist for this approach and wanted to write about it for a long time, but didn't know how to frame it entertainingly. Then on X, I got inspiration when levelsio posted a tweet about deploying a DNS server on Hetzner that lets you talk to an LLM.

Want to see it in action? Try this:

dig @llm.skeptrune.com "what is the meaning of life?" TXT +short

Getting that setup is probably more interesting than my rambling, so here's how to deploy your own LLM-over-DNS proxy on a VPS in less than half an hour with nothing other than a rented server.

Step 1: Access Your VPS

After purchasing your VPS, you'll receive an IP address and login credentials (usually via email). Connect to your server:

ssh root@<your-vps-ip>

Replace <your-vps-ip> with your actual server IP address.

Step 2: Clear Existing DNS Services

Many VPS images come with systemd-resolved or bind9 pre-installed. To avoid conflicts, remove or disable them:

# Check for running DNS services
systemctl list-units --type=service | grep -E 'bind|dns|systemd-resolved'

# Stop and disable systemd-resolved (if present)
systemctl stop systemd-resolved
systemctl disable systemd-resolved

# Remove bind9 (if present)
apt-get remove --purge bind9 -y

Step 3: Install Python Dependencies

Install the required Python packages for our DNS server:

pip install dnslib requests

Step 4: Create the DNS-to-LLM Proxy Script

Create a Python script that listens for DNS queries, treats the question as a prompt, sends it to the OpenRouter LLM API, and returns the response in a TXT record:

from dnslib.server import DNSServer, BaseResolver
from dnslib import RR, QTYPE, TXT
import requests
import codecs

OPENROUTER_API_KEY = ""  # Add your OpenRouter API key here
LLM_API_URL = "https://openrouter.ai/api/v1/chat/completions"

class LLMResolver(BaseResolver):
    def resolve(self, request, handler):
        qname = request.q.qname
        qtype = QTYPE[request.q.qtype]
        prompt = str(qname).rstrip('.')
        
        # Forward prompt to LLM
        try:
            response = requests.post(
                LLM_API_URL,
                headers={
                    "Authorization": f"Bearer {OPENROUTER_API_KEY}",
                    "Content-Type": "application/json"
                },
                json={
                    "model": "openai/gpt-3.5-turbo",
                    "messages": [{"role": "user", "content": prompt}]
                },
                timeout=10
            )
            response.raise_for_status()
            raw_answer = response.json()["choices"][0]["message"]["content"]
        except Exception as e:
            raw_answer = f"Error: {str(e)}"
        
        try:
            answer = codecs.decode(raw_answer.encode('utf-8'), 'unicode_escape')
        except Exception:
            answer = raw_answer.replace('\\010', '\n').replace('\\n', '\n')
        
        reply = request.reply()
        if qtype == "TXT":
            # Split long responses into chunks of 200 chars (safe limit)
            chunk_size = 200
            if len(answer) > chunk_size:
                chunks = [answer[i:i+chunk_size] for i in range(0, len(answer), chunk_size)]
                for i, chunk in enumerate(chunks):
                    reply.add_answer(RR(qname, QTYPE.TXT, rdata=TXT(f"[{i+1}/{len(chunks)}] {chunk}")))
            else:
                reply.add_answer(RR(qname, QTYPE.TXT, rdata=TXT(answer)))
        return reply

if __name__ == "__main__":
    resolver = LLMResolver()
    server = DNSServer(resolver, port=53, address="0.0.0.0")
    server.start_thread()
    import time
    while True:
        time.sleep(1)

Save this as llm_dns.py on your VPS.

Before running, you need to set your OpenRouter API key. For this tutorial, you can paste it directly into the OPENROUTER_API_KEY variable. For anything more serious, you should use an environment variable to keep your key out of the code.

Security Note: This is a proof-of-concept. For production use, you'd want proper process management (systemd), logging, rate limiting, and to avoid storing API keys in plaintext.

Step 5: Run the DNS-LLM Proxy

Start the DNS server (port 53 requires root privileges):

sudo python3 llm_dns.py

Step 6: Test Your Service

From another machine, send a DNS TXT query to test your setup:

dig @<your-vps-ip> "what is the meaning of life" TXT +short

The LLM's response should appear in the output.

Troubleshooting

Common Issues:

• Permission denied: Make sure you're running with sudo (port 53 requires root)

• Connection timeout: Check your VPS firewall settings and ensure port 53 is open

• API errors: Verify your OpenRouter API key and check your account has credits

• No response: Try running systemctl status systemd-resolved to ensure it's actually disabled

Step 7: Secure Your Setup (Optional but Recommended)

To restrict access to your DNS-LLM proxy, use UFW (Uncomplicated Firewall) - and yes, it's literally called "uncomplicated" because that's what a VPS is, uncomplicated:

ufw allow ssh
ufw allow 53
ufw enable

This allows SSH access (so you don't lock yourself out) and DNS queries on port 53, while blocking everything else by default.

Important: This setup runs as root and stores your API key in plaintext. For anything beyond experimentation, consider using environment variables, proper user accounts, and process managers like systemd.

References

• dnslib documentation

• OpenRouter API docs

That's it! You now have your own LLM-over-DNS proxy running on a simple VPS. No complex infrastructure needed - just SSH, install dependencies, and run your code. This is the beauty of keeping things simple.

Here's the fun irony: I was the founder of Trieve, the company that powered search for their 30,000+ documentation sites, yet their debounced search queries weren't being aborted as you typed. Check out this delightful chaos:

I had brought this up in our shared Slack before when I was just a vendor to them us (weird), but it wasn't a priority and never got fixed. It was extra frustrating because the race condition on the query was apparent enough that search would sometimes feel low quality since it would return results for a query many characters before the user was done typing.

Even worse, as the founder of the search company powering this experience, it felt like a poor reflection on Trieve every time someone encountered these wonky results.

Fixed It

Now that I'm on the team, I was able to finally fix it. I added an AbortController to the debounced search function, so that it aborts any previous queries when a new one is made. This means that the search results are always relevant to what the user is currently typing.

There's something deeply satisfying about finally being able to fix the things that bug you. It made me feel a bit like George Hotz during his single week at Twitter in 2022, where he joined with overambitious plans to fix Twitter search, gave up due to hubris, and settled for fixing an annoying login popup before leaving.

I've always admired engineers who are part hacker, part entrepreneur - people who see a problem and just... fix it. Getting to do something similar here (minus the dramatic exit) felt like a small win in steering my career toward that kind of direct approach.

Open Source

I prefer building and using open source software whenever possible, and this whole situation is a great example of why.

With open source - when you encounter a bug or pain point, you can actually fix it yourself. Had this been an open source project during the year I was frustrated with the search race condition, I could have submitted a pull request with the AbortController fix and saved myself (and thousands of other users) the daily annoyance.

Instead, it remained a persistent irritation until I happened to join the company and gain access to the codebase. There's something to be said for the immediate empowerment that comes with open source - though I understand why many companies choose different models for various business reasons.

Self-Congratulation

If search feels just a bit crisper and more responsive on Mintlify, it’s because of me! I fixed a bug that bothered me for over a year, and it feels great to have made that little improvement to the product.

I can't wait to make more. Fixing small issues like this over and over again is how products become legendary. There's something deeply satisfying about finally having the power to fix the things that annoy you - even if they're tiny.

Especially if they're tiny.

Getting Your Ladder

I tried to use Midjourney unsuccessfully a few times before, but decided to give it one more try after reading a good tutorial thread on X by @kubadesign. His thread got me most of the way there, but I picked up an additional trick with Midjourney's describe feature that I think is worth sharing.

My initial plan was to use these images for uzi.sh, a tool for parallel LLM coding agents. While I ultimately chose a different final image for that project because I only needed one, the learning process was valuable. For this set, I aimed for a red color scheme to evoke action and speed, which you can see in the images below.

<MasonryImages />

Find a Base Image

Following Kuba's advice, I went to pinterest and found a cool base image that I liked. I went with something that had a lot of red, but also darker colors on the border since I knew that I would need space for text and other elements if I wanted to use these on an actual website.

Build a Style With Neutral Prompts

You can't just start by describing the specific kind of image you want and expect to get good results. Style reference images are needed to give Midjourney the boundaries it needs to stick to your desired aesthetic and theme once you get more specific with your exact asks.

It's unlikely that you'll be able to find multiple images on the internet which match your desired style exactly, so I recommend using neutral prompts to generate additional images in order to create a cohesive gallery.

My neutral prompt here was Portrait photography of a woman, glow behind, futuristic vibe, flash photography, color film, analog style, imperfect --ar 3:4 --v 7. Essentially, any prompt describing a general subject and its characteristics without getting too specific about style, camera angle, action, or other details should work well.

Using Describe to Get More Specific

One of the images I wanted was an eagle diving. However, eagle diving with red glowing background wasn't getting me the results I wanted. I accidentally discovered the describe feature dragging images around, and instantly realized that it was a cheat code for getting the images I wanted.

You can take any one of these and pair them with the style reference images you generated earlier to get the eagle or any other image you described into the style you want. I could not believe how well this worked.

Post Processing: Adding Film Grain for Web Design

Midjourney produces images which are too crisp to fit well as background images for the web. I recommend adding grain to them when you put them into your final site to create a more cohesive feel. If done correctly, you'll end up with a result that looks like the below. CSS is great for this! See a complete guide of how I applied the filter for the uzi.sh site below, full code on Github here.

You first need to add a svg filter definition to your HTML file such that the CSS can reference it later to put the grain on top of the background image. The filter uses feTurbulence to create a fractal noise pattern, and feColorMatrix to adjust the opacity. You can experiment with values like baseFrequency in feTurbulence or the alpha channel (the 0.8 in the feColorMatrix) to finetune the grain's intensity and texture.

<!-- SVG noise filter definition - this goes in your HTML -->
<svg style="display: none">
  <filter id="noiseFilter">
    <!-- Creates the fractal noise pattern -->
    <feTurbulence
      type="fractalNoise"
      baseFrequency="0.5"
      numOctaves="3"
      stitchTiles="stitch"
    />
    <!-- Converts noise to semi-transparent overlay -->
    <feColorMatrix
      type="matrix"
      values="0 0 0 0 0
              0 0 0 0 0
              0 0 0 0 0
              0 0 0 0.8 0"
    />
  </filter>
</svg>

Once you have the filter defined, you can apply it to a grain overlay element in your CSS. This element will cover the background image and apply the noise effect.

/* The grain overlay element that applies the filter */
.grain-overlay {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  z-index: 2; /* Above background image, below content */
  pointer-events: none; /* Allows clicks to pass through to elements below */
  filter: url(#noiseFilter); /* Applies the SVG filter defined above */
}

/* Background image styling for context */
.background-image {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background-image: url("./media/16x9steppecommander.png");
  background-size: cover;
  background-position: center;
  z-index: 1; /* Below grain overlay */
}

Finally, you need to structure your HTML to ensure the layering works correctly. The grain overlay should be positioned above the background image but below any content you want to display.

<!-- HTML structure showing the layering -->
<div class="hero">
  <!-- Layer 1: Background image (z-index: 1) -->
  <div class="background-image"></div>

  <!-- Layer 2: Grain overlay (z-index: 2) -->
  <div class="grain-overlay" style="filter: url(#noiseFilter)"></div>

  <!-- Layer 3: Content (z-index: 3) -->
  <div class="content-center">
    <!-- Your content here -->
  </div>
</div>

Be Creative!

While there's ongoing debate about AI generated art, I see Midjourney as just another tool in the toolkit. The key is using it to bring your vision to life, not to replace your creativity.

Take inspiration from what you see, but make it your own. Use AI to bridge the gap between the style you have in your head and what actually shows up on screen. The techniques I've shared here are all about developing your unique voice and letting AI help you express it better.

The goal isn't to generate something generic. It's to create images that actually work for your projects and feel intentional, not obviously AI generated.

This realization isn’t unique to me; the effectiveness of using Git worktrees for simultaneous execution is gaining broader recognition, as evidenced by mentions in Claude Code’s docs, discussion on Hacker News, projects like Claude Squad, and conversation on X.

Example use-case: adding a UI component

I'm building a component library called astrobits and wanted to add a Toggle. To tackle the task, I deployed two Claude Code agents and two Codex agents, all with the same prompt, running in parallel within their own git worktrees. Worktrees are essential because they provide each agent with an isolated directory, allowing them to execute simultaneously without overwriting each other's changes.

The number of agents I choose to rollout depends on the complexity of the task. Over time, you'll develop an intuition for estimating the right number based on the situation. Here, I felt 4 was appropriate.

<br></br> <ImageFourSquareWorktrees /> <br></br>

Voila, results! Only one of the four LLMs produced a solution that actually saved me time. This validates the necessity of rolling multiple agents: if each has a ~25% chance of producing something useful, then running four gives a 68% chance that at least one will succeed (1 - 0.75^4 ≈ 0.68). Four agents was essentially the bare minimum to have reasonable confidence in getting a workable solution.

With LLMs being so affordable, there's virtually no downside to running multiple agents. The cost difference between using one agent ($0.10) versus four ($0.40) is negligible compared to the 20 minutes of development time saved. Since the financial risk is minimal, you can afford to be aggressive with parallelization. If anything, I could have run even more agents to further increase the odds of getting a perfect solution on the first try.

And yet, the process of running them is still cumbersome and manual, it's more effort to setup 8 than 4, so I'm often lazy and opt to run the minimum number of agents I think will get the job done. This is where the problem comes in, and why I'm excited to share my proposed solution.

Current workflow pain points

Right now, I manually create git worktrees using git worktree add -b newbranch ../path, start a tmux session for each one, run Claude Code in the first pane, paste a prompt, leader+c into a new pane, run yarn dev to get a preview, switch to my browser to review, repeat if no agents succeed, then finally commit, push, and create a PR once I'm satisfied with an output.

Here are the top frustrations:

• I can't tell which branch a worktree was most recently rebased onto. For example, if agent-1 was rebased onto feature-x but agent-2 onto main, it's easy to lose track without manual notes.

• There is no easy way to send the same prompt to multiple agents at once. For instance, if all agents are stuck on the same misunderstanding of the requirements, I have to copy-paste the clarification into each session.

• I really wish I had a shortcut to open my IDE for a given worktree without having to tmux a, leader + c, and code . manually. I could use a long one-liner with tmux send-keys and xargs to automate this, but that still feels clunky.

• Web previewing is a pain. I have to run yarn dev in each worktree, and then hold the mental model of which port each worktree is on. Automating a reverse proxy to handle this with a decent naming scheme would be a game-changer.

• Committing and creating pull requests (PRs) is also more cumbersome than it should be. For example, after finding a solution in agent-3, I have to manually attach to that tmux session then commit, push, and gh pr.

I feel like I've been through the wringer enough times with this process that I can see a solution shape which would create a smoother experience.

Proposing a solution: uzi

To address these challenges head-on, the ideal developer experience (DX) would involve a lightweight CLI that wraps tmux, automating this complex orchestration. My co-founder Denzell and I felt these pain points acutely enough that we've begun developing such a tool, which we're calling uzi. The core idea behind uzi is to abstract away the manual, repetitive tasks involved in managing multiple AI agent worktrees.

See some of the uzi commands we are thinking to implement below. Our goal is to make the workflow more seamless while sticking closely to the existing mechanics of worktres and tmux. We want to make sure that we feel at home using uzi alongside standard unix tools like xargs, grep, and awk.

• uzi start --agents claude:3,codex:2 --prompt "Implement feature X" could initialize and prompt three Claude instances and two Codex instances, each in its own worktree.

• uzi ls would display all active agents, their target branches, and current statuses.

• uzi exec --all -- yarn dev could run a command like yarn dev across all agent worktrees.

• uzi broadcast -- "Refine the previous response by focusing on Y" would send a follow-up prompt to all active agents.

• uzi checkpoint --agent claude-1 --message "Implemented initial draft" could rebase the specified agent's worktree and commit the changes.

• uzi kill --agent codex-2 would clean up a specific agent's tmux session and optionally its worktree.

These commands would primarily operate via tmux send-keys instructions to the appropriate sessions. We don't want to reinvent the wheel; we just want to polish the existing process and make it more efficient.

The Future is Parallel: Beyond Code

While uzi focuses on software developers, its methodology isn't limited to tech; the principle of leveraging multiple agents running in parallel to increase the odds of finding an optimal solution applies universally.

Consider a company like versionstory, which is pioneering version control for transactional lawyers. An attorney could leverage their software to run multiple instances of an agent to redline a contract. After reviewing the outputs, they could select and merge the best components to finalize the document. This approach would provide additional confidence in the quality of the final review as it would be based on multiple independent analyses rather than a single agent's output.

Similarly, a marketing team could employ this parallel strategy to perform data analysis on ad performance. By prompting multiple AI instances, they could quickly gather a range of analyses, review them, and select the most insightful ones to inform their strategy. More coverage of the solution space leads to better decision-making and more effective campaigns.

This parallel paradigm isn't just a new technique for developers; it's a glimpse into a more efficient, robust, and powerful future for AI-assisted productivity across various fields. I expect to see existing software products start to gain more powerful version control and parallel execution capabilities which emulate the workflow enabled by git worktrees for software development.

My DMs are open if you want to chat about this topic or have any questions. I'm happy to discuss.