DEV Community: David Bos

Ship on a free link first, buy the domain when it has visitors

David Bos — Wed, 30 Sep 2026 10:57:53 +0000

Disclosure: I'm behind DropTheHassle.

In September someone posted this on Hacker News: "I'm addicted to buying domains for my vibe-coded apps that get 0 visitors". The post had no text, just the title. It didn't need any. The comments read like a support group.

"I feel so bad when I look at my domains after few months lol." (arpanghoshal, the poster)

"It's not you, it's all of us" (wakaru44)

"I have porkbun open in another tab." (jtap)

"I'm nearly up to 100" (alexnewman)

I build a tool that sells domains, so I have an obvious interest here. But I think the thread gets to something real about how side projects are built now, and the advice in it was better than "just stop".

Why we buy the domain first

When an AI can build a working app in an afternoon, the domain becomes the most "real" thing you can do next. It costs money, it has your idea's name on it, and it feels like commitment.

One commenter named it:

"Buying a domain is pretend work. It feels like progress, but doesn't make a project/product better…" (brudgers)

Another, more fun, version:

"buying domains that just seem fun or cool" [...] "What have I done with it? Nothing." (davidsojevic)

The problem isn't the one-time cost. It's the renewals. A year later the project is dead, the domain is still charging you, and every renewal email is a small reminder.

Camp 1: use the free link

The most common advice was to not buy anything until you have to:

"Get a single domain and use subdomains till one of your projects pop off. Or use the cloudflare worker/vercel domain that is by-default provided" (datron)

"someshit.vercel.app bridges the gap." (nsnsnsnsjsj)

"If you get one good domain, subdomains work really well" (toast0)

That's sound. A free platform link (*.vercel.app, *.pages.dev, *.netlify.app, *.github.io) is plenty to find out whether anyone cares.

Camp 2: keep it clean from day one

One comment pushed back, and it's worth reading in full:

"if one of the side-projects takes off, it's a real pain to disentangle… migrating a project to its own domain all to save less than $100… keep your projects clean from the get go" (takinola)

This is the part people forget. If project #7 lives at project7.yourname.com, then its links, its search history, its users' bookmarks, maybe its cookies and its email all hang off your personal domain. Moving it later is a migration, not a rename.

Both camps are right, so combine them

The rule I use, and the one I'd suggest:

Ship on a free link first. Buy the domain when it has visitors. But give every project its own free link, not a subdomain of your personal domain.

That keeps the cost at zero while you find out whether it matters, and it avoids the takinola problem: each project is already its own site. When one earns a name, you point a domain at that site. You don't untangle it from everything else.

What counts as "has visitors" is up to you. Mine is roughly: someone I didn't send it to used it, or I'm about to put the link somewhere permanent (a bio, a client proposal, a launch post). Before that, the free link is enough.

Make the free link a real deploy

The failure mode isn't only buying domains too early. It's also never shipping at all, because "I'll deploy it properly once I have the domain."

Whatever host you use, get it on a public URL the day you build it. Open it on your phone and send it to one person. That's the test that matters.

If you build with Claude Code, Cursor, Codex or Windsurf, here's the version I built, which needs no account:

npx -y dropthehassle deploy

It uploads the built folder and prints a live name.dropthehassle.app link with HTTPS, plus a claim link. Your agent can also do it through an MCP server (https://dropthehassle.com/mcp) with no token. The honest details:

the claim link works for 7 days; an unclaimed site is removed after that;
until you claim it, the site is served with noindex and shows a small, dismissible "Claim this site" bar, so it's a preview, not a launch;
static sites only (HTML or a build output), no server code.

When it does earn a domain

Two things to check before you buy, wherever you buy:

The renewal price, not the first-year price. Plenty of registrars discount the first year. The renewal is what you'll actually live with, and it's the number behind the guilt in that thread.
Whether you'll need to touch DNS. If you buy the domain where the site already lives, you often don't. If you buy it elsewhere, you're adding records at the registrar.

For what it's worth, on DropTheHassle a .com is €19 a year including VAT in the EU, or $19 elsewhere, and it's the same every year. If you buy it for a site that's already there, it goes live on that site after payment, with no DNS records to edit. A domain you already own needs one A record. And if you let your AI handle it: it can search for names and publish the site, but it can never pay. The checkout is always your click.

The short version

Build it, deploy it the same day, on a free link.
Give each side project its own link, not a subdomain you'll have to untangle.
Buy the domain when the project has visitors, and check the renewal price when you do.

And if you already have a drawer of domains with nothing on them: as one commenter put it: "ARE U ME" (wompapumpum). You're not the only one.

If you want the step-by-step for a specific tool: guides for Claude Code, Cursor, Lovable and more.

Disclosure: I'm behind DropTheHassle.

Deploy from Cursor or Windsurf with a remote MCP server (no account, no token)

David Bos — Wed, 30 Sep 2026 10:49:11 +0000

Disclosure: I'm behind DropTheHassle.

If you build in Cursor or Windsurf, the agent already writes the code, runs the build and fixes the errors. The one thing it usually can't do is put the result online. It hands you a dist/ folder and a list of hosting options.

MCP fixes that. You add a server, and the agent gets tools it can call. This post sets up a deploy server that needs no account and no token for the first publish. I build it, so here's the setup, what you get back, and where it stops.

Why MCP instead of a terminal command

You can deploy from a terminal with npx -y dropthehassle deploy, and in Cursor the agent can run that for you. MCP is nicer in three cases:

You want the agent to decide when to deploy ("put it online when the build passes").
You want structured results: the tool returns the live URL and the claim link as data, not as terminal text the model has to parse.
You want the agent to check a domain name without leaving the chat.

Setup in Cursor

Cursor reads .cursor/mcp.json in the project, or ~/.cursor/mcp.json for all projects. Remote servers use a url key:

{
  "mcpServers": {
    "dropthehassle": {
      "url": "https://dropthehassle.com/mcp"
    }
  }
}

No headers block is needed for the first deploy. Open the MCP section in Cursor's settings to check it connected; you should see tools like deploy_site and search_domain.

Setup in Windsurf

It depends on which agent you use.

Cascade (the older agent) uses mcp_config.json, and remote servers take a serverUrl key:

{
  "mcpServers": {
    "dropthehassle": {
      "serverUrl": "https://dropthehassle.com/mcp"
    }
  }
}

Devin Local (the default for new tabs) configures servers through the Devin CLI config instead. There, use the local stdio server, which also works without a token:

{
  "mcpServers": {
    "dropthehassle": {
      "command": "npx",
      "args": ["-y", "dropthehassle-mcp"]
    }
  }
}

Put that in .devin/mcp_config.local.json, or run devin mcp add dropthehassle -- npx -y dropthehassle-mcp.

What works without an account

With no token, the server exposes three tools:

deploy_site: publishes a static site to a free name.dropthehassle.app link with HTTPS, and returns a claim link.
search_domain: checks whether a domain is free and what it costs.
whoami: confirms the connection and lists what works.

The other tools (listing your sites, renaming the free link, pointing a domain, linking a backend, getting a checkout link) need a token from an account.

Deploying

Ask the agent something like:

Build the site and publish the dist folder with DropTheHassle. Give me the live link and the claim link.

Cursor asks for approval before it runs an MCP tool by default, and you can expand the call to see the arguments. The server's own instructions tell the agent it must pass the claim link on to you, so you should see both links in the chat.

This is what the tool returned when I called it with a one-file test site (claim link removed):

Live at https://warm-finch-339.dropthehassle.app […]. Give the human this claim link
(it expires in 7 days): https://dropthehassle.com/claim#… This site is not on an account until they claim it.

One detail matters here. The remote server can't read your disk. Over the URL, deploy_site receives the files inline: each file as a path plus its content, as UTF-8 text or base64. The agent reads the built files and sends them. That works well for a normal static site. For a folder with lots of images or video it's a lot of data to push through a tool call. For those, use the local server (npx -y dropthehassle-mcp), which uploads the folder itself as a zip of at most 100 MB, or run the CLI.

Checking a domain

This is a real response from search_domain for a made-up name:

push100testsite.com: AVAILABLE (EUR 19/yr incl. VAT in the EU, USD 19 elsewhere, the same every year). […]
Buying is a human step in the dashboard; I can search and suggest, not spend.

That second line is the design: your AI can publish, but it can never spend your money. No tool buys anything. With an account, the agent can fetch a checkout link for a domain on your site; you open it and pay yourself. After payment the domain goes live on that site, with no DNS records to edit. A .com is €19 a year including VAT in the EU, or $19 elsewhere, and it's the same every year. If you already own a domain, you point it with one A record instead.

After you claim

The claim link is valid for 7 days. Until you claim the site:

it's served with noindex, nofollow, so search engines are asked to skip it;
visitors see a small, dismissible bar: "Made with DropTheHassle · Claim this site · Report abuse";
after 7 days an unclaimed site is removed.

Once it's claimed and you want the account tools, create a token in the dashboard (it starts with dth_). For the local server, put it in the env block as DTH_TOKEN. For the remote URL, send it as an Authorization: Bearer header. Never commit it to the repo, and don't paste a placeholder value; leave it unset until you have the real one.

Limits

Static only. A folder that still needs a build is refused, and so is anything that needs a server to run (PHP, Node, Python). If you have a backend, host it elsewhere; with an account, set_backend can put it behind your name under a path such as /api.
Remote means inline files. See above. Big assets go through the local server or the CLI.
Client-side routes survive a refresh: a path that isn't a real file (say /about) gets your index.html, while a missing file such as /missing.png still returns a 404.
Team policies can block it. Cursor lets enterprise admins restrict which MCP URLs and commands may run. If the server doesn't show up, check with your admin.
Cloud agents are a different environment. Background or cloud agents run elsewhere, with their own network rules. I've written this for the local editor.

The point

The nice thing about an agent-driven deploy isn't saving 30 seconds. It's that the loop closes: the agent builds, publishes, and hands you a URL you can open on your phone. That's the moment a side project becomes real enough to show someone.

Setup details and more examples: Deploy with your AI (MCP guide). Cursor-specific steps, including the domain: Cursor site on your own domain. Windsurf: Windsurf deploy to a custom domain.

If something in the setup didn't work for you, post the error in the comments. I'd rather fix the rough edges than have you guess.

Disclosure: I'm behind DropTheHassle.

Deploy a Claude Code site in one command, no account

David Bos — Wed, 30 Sep 2026 10:47:36 +0000

Disclosure: I'm behind DropTheHassle.

Claude Code is very good at the first 95%. You describe a landing page, a portfolio or a small tool, and a few minutes later there's a folder with an index.html or a dist/ directory and a dev server on localhost.

Then comes the last 5%: getting it on a real URL that you can send to someone. That's usually where a side project stalls. You open a hosting dashboard, create an account, connect a repo, pick a framework preset, and by the time you're done you've forgotten why you built the thing.

This post shows the shortest path I know: one command, no account, a live HTTPS link. I build the tool, so read it with that in mind. I'll also be clear about what it doesn't do.

What you need

A static site: plain HTML, or the output of a build (npm run build). Claude Code usually builds with Vite, Astro or plain HTML, and all of those produce a static folder.
Node.js, so npx works.

That's it. No account, no token, no config file.

The command

From the project folder, after building:

npm run build
npx -y dropthehassle deploy

The CLI looks for the site in this order: a folder with index.html, or dist/, build/, out/, _site/ or public/. You can also pass the folder explicitly: npx -y dropthehassle deploy dist.

Here's the real output from a test deploy I ran this week (claim link removed):

  Uploading your site...

  Linked this folder to your site (.dropthehassle.json, kept out of git).

  Live at https://sunny-lynx-807.dropthehassle.app
  Claim it (the link works for 7 days, then an unclaimed site is removed):
  https://dropthehassle.com/claim#…

The site was live on HTTPS (a Let's Encrypt certificate) straight away. Client-side routes survive a refresh too: a path that isn't a real file gets your index.html (a missing file such as /missing.png still returns a 404).

Let Claude Code run it

You don't have to type the command yourself. Ask:

Build the site and deploy it with npx -y dropthehassle deploy. Show me the live link and the claim link.

Claude Code asks permission before it runs the shell command, so you see exactly what's happening. If you deploy often, add one line to your project's CLAUDE.md:

## Deploy
Run `npm run build && npx -y dropthehassle deploy`. Always show me the claim link.

Updating the site

The first deploy writes a small .dropthehassle.json file into the folder. It links the folder to the site. Run the same command again and it updates the same site instead of creating a new one:

  Linked folder: updating https://sunny-lynx-807.dropthehassle.app in place.

  Uploading your site...

  Live at https://sunny-lynx-807.dropthehassle.app

That file contains the site's key. The CLI keeps it out of git; don't commit it or paste it anywhere.

What an unclaimed site looks like

These are the parts you should know before you send the link around:

The claim link works for 7 days. If you don't claim the site in that time, it's removed. Open the link and sign in to keep it.
Unclaimed sites are not indexed. I checked the headers: an anonymous site is served with noindex, nofollow, so search engines are asked to skip it. That's fine for "show a friend" or "test on my phone". It's not how you'd launch.
There's a small bar at the bottom that says "Made with DropTheHassle", with "Claim this site" and "Report abuse" links. Visitors can dismiss it.

So think of the anonymous link as a preview you can share, and claim it when you want to keep it.

Putting it on your own domain

When the project earns a real name, you have two options:

Buy the domain with the site. A .com is €19 a year including VAT in the EU, or $19 elsewhere, and it's the same every year. Because the domain and the site sit in the same place, there are no DNS records to edit.
Use a domain you already own. Add one A record at your registrar.

Claude Code can check whether a name is free, but it can't buy it. The checkout is always a human click. That's deliberate: your AI can publish, but it can never spend your money.

Honest limits

Static sites only. A folder that still needs a build is refused, and so is a site that needs a server to run (PHP, a Node server, Python). If your project has a backend, host that part elsewhere. With an account you can put it behind the same name under a path like /api.
Build first. Point the command at the built output, not at the source folder.
Size. Until you claim it, an anonymous site can be at most 25 MB (that's in the terms). After claiming, the normal account limits apply; signed-in uploads can be up to 100 MB.
Claude Code on the web (the cloud version) blocks it by default. Cloud sessions run in a sandbox with a network allowlist. npm's registry is on the default list, so npx downloads fine, but dropthehassle.com is not, so the upload is blocked. Fix it in the environment settings: set network access to Custom, add dropthehassle.com, and keep the default list included. Or add https://dropthehassle.com/mcp as a connector in claude.ai; connectors don't go through the sandbox network. Also note that each cloud session starts fresh, so the .dropthehassle.json link is gone and a new session creates a new site. Claim the first one.
Don't put tokens in the repo or in environment variables that other people can read. The anonymous flow doesn't need a token at all.

Why one command matters

Most side projects don't die because the code is bad. They die at localhost. A live link changes how you treat the thing: you open it on your phone, send it to a friend, notice the broken button on mobile. That feedback loop is worth more than any hosting feature.

So: build it, run one command, look at it on a real URL. Decide about the domain later.

The full step-by-step guide, with the domain part in more detail, is here: Deploy a Claude Code website to your own domain. If you'd rather let your editor's agent do the deploy through MCP, see the MCP guide.

Questions or rough edges you hit? Tell me in the comments. I read them and fix what I can.

Disclosure: I'm behind DropTheHassle.