DEV Community: Jamie Street

Your AI Can Build a Website. Where Does It Go When the Chat Ends?

Jamie Street — Tue, 28 Jul 2026 11:52:47 +0000

An AI agent can now build a complete website in one conversation. A landing page, a dashboard, a small game, a gallery. The code is real and it works.

Then the conversation ends, and the website is trapped. It exists as a code block in a chat window. You can copy it, screenshot it, or lose it. The build cost collapsed. The shipping cost did not.

This article describes five practical patterns for the last mile: getting AI-built front-ends onto real URLs, with the least friction for each situation.

Disclosure: I run Nippy, the static host I use in the examples. The patterns work with any host that supports the same operations; the point is the pattern, not the vendor.

Pattern 1: the agent ships it

The cleanest path: the AI that built the artifact also publishes it.

This works through MCP (Model Context Protocol). You connect a hosting tool to your AI client once. After that, "publish this" is part of the conversation. The agent writes the files, calls the tool, and returns a live URL.

I wrote a full walkthrough with a live demo if you want the step-by-step version.

Use this pattern when the artifact is born in a chat and the chat is where you work.

Pattern 2: you ship the folder

Sometimes you have the files locally — an export from an AI tool, a folder from a code session. The old-fashioned path is still the fastest: drop the folder on nippy.host, pick an address, and the site is live. No account setup ritual; the first publish confirms your email.

Use this pattern for one-off artifacts and for people on your team who do not touch a terminal.

Pattern 3: iterate on a stable URL

AI-assisted building is iterative. Version 2 arrives ten minutes after version 1. If each version gets a new URL, the person reviewing it is always holding a dead link.

The pattern: publish once, then update in place. The URL never changes; the content does. Your client refreshes the same link and sees the newest version. On Nippy this is one command:

npx @nippyhost/cli deploy

Use this pattern for client review loops and for anything you share in a group chat.

Pattern 4: CI ships what the repo holds

When the AI-built project graduates into a git repository, stop deploying by hand. Put a deploy token in a repository secret and add one step to your workflow:

NIPPY_TOKEN=$SECRET npx @nippyhost/cli deploy

Every merge ships. This is the boring, correct pattern for anything with a lifespan longer than a week.

Pattern 5: protect the prototype

Not every AI-built artifact is for the public. A pitch mock-up with a client's name on it should not be indexable, and sometimes should not be open at all.

Two small tools cover most cases. A password on the site keeps drafts private until they are ready. A QR code for the URL puts the prototype on a phone in one scan, which is the fastest way to test a mobile layout with a real device.

Use this pattern before you send anything with a client's brand on it to a public URL.

One warning: read what the AI wrote

Before you ship an AI-built page, search the files for secrets. Agents sometimes embed API keys, private endpoints or test data directly in the HTML, because that is the shortest path to "it works". A static site is public by definition. What is in the file is on the internet.

Thirty seconds with a search for key, token and secret is enough. Make it a habit.

The point

The interesting change is not that AI writes code. It is that the artifact loop — idea, build, share, feedback — now fits inside an hour. The build step got fast. The patterns above make the share step match it.

If you want to try the full loop, Nippy covers all five patterns, and the help center documents each one. Total setup time is roughly the length of this article.

What is the best thing an AI has built for you that never made it out of the chat window? Tell me in the comments — and then ship it.

Related reading

Website Analytics Without a Cookie Banner: What Is Actually Legal in 2026

Jamie Street — Tue, 28 Jul 2026 11:30:52 +0000

Most cookie banners protect nothing. They exist because a site loaded an analytics script that plants an identifier on your device. The site owner often wants only one number: how many people visited.

There is a better path. This article explains what the law actually regulates, what changed in the UK in 2026, and how to measure traffic without a consent banner. It is not legal advice. It is a map, with sources, so you can check your own position.

Disclosure: I run Nippy, a static hosting service with built-in cookie-free analytics. I explain below how it avoids the consent trigger. The same logic applies to any tool built the same way.

The law does not say "cookies"

The UK and EU rules regulate storage and access on the user's device. A cookie is one example. The rules also cover localStorage, tracking pixels, scripts and device fingerprinting. The UK regulator lists these technologies explicitly in its guidance on storage and access technologies.

This has two consequences:

You cannot escape the rules with a fingerprint instead of a cookie. Fingerprinting is in scope.
Analytics that stores nothing on the device, and reads nothing from it, avoids the main trigger.

That second point is the foundation of cookie-free analytics.

How cookie-free analytics works

A cookie-free system counts on the server. The request itself carries enough for aggregate statistics:

The page that was requested.
The referrer header.
The user agent, for browser and bot detection.
The country, derived from the IP address and then discarded.

The system does not set an identifier. It does not read one. It does not build a profile of one visitor across days or across sites. It produces totals: views, visitors, sources, countries. Individual people are not the product; the aggregate is.

This is how the analytics in Nippy works: views, visitors, sources, countries and realtime, with bots filtered out, switched on per site — and no banner, because there is nothing on the device to consent to.

The UK in 2026: the rules caught up

Until recently, UK law (PECR) required consent for almost all analytics storage. The Data (Use and Access) Act changed this. The ICO finalised its updated guidance in April 2026. There is now an explicit statistical purposes exception.

The exception lets you collect usage statistics without consent. Four conditions apply:

Sole purpose. You collect the information only to understand use of the service and to improve it.
Aggregates, not individuals. You must not monitor or track individual visitors.
Third parties as processors only. Your analytics provider can act only on your behalf. It cannot reuse the data.
Transparency and objection. You must tell users clearly what you do, and give them a simple, free way to object.

Note what this means in practice. In the UK, even cookie-based first-party analytics can now run without a consent popup, if you meet all four conditions. And cookie-free analytics meets the first three by design; you still owe users a clear notice and an opt-out. A short section in your privacy page can do both jobs.

The exception does not cover advertising, profiling or cross-site tracking. Those still require consent.

The EU: stricter, and read the fine print

The EU ePrivacy rules still require consent for storage and access, with no general analytics exception. Some countries carve out narrow exemptions — France's CNIL permits strictly-configured audience measurement, for example — but there is no EU-wide rule you can rely on.

There is a second thing to know. The European Data Protection Board read the scope of the rules broadly in its guidelines on Article 5(3): techniques such as pixel tracking, URL decoration and some IP-based tracking can fall in scope even without a classic cookie.

The honest summary for EU traffic: analytics that stores nothing and reads nothing from the device is in the strongest possible position, but "cookie-free" is not a magic phrase. A tool that quietly fingerprints devices to make its visitor counts is not exempt anywhere. Ask your vendor what the visitor count is made from.

GDPR still applies

The consent-banner question and the GDPR question are separate. If your analytics touches personal data at any point — an IP address in a server log is personal data — GDPR applies to that processing. For aggregate statistics this is normally manageable: legitimate interests as the basis, minimal data, short retention, and no attempt to identify anyone. But it is a real obligation, not a footnote. Your privacy page should describe it.

A checklist

Before you remove your banner, check these:

Your analytics sets no cookie and uses no localStorage. Verify in DevTools, not in the sales page.
It does not fingerprint. Ask the vendor how visitors are counted.
It reports aggregates only. No individual visitor timelines.
Your privacy page explains the measurement, and offers a way to object.
If you serve EU traffic, check the position of the relevant national regulator.
Everything else on the site that stores or reads device data — embeds, fonts, ad scripts — has its own trigger. The banner question is about the whole page, not one script.

The last point catches people. A privacy-clean analytics tool does not license a page full of third-party embeds.

Why this matters beyond compliance

A banner is friction for every visitor, to enable measurement that most sites barely use. Removing it is one less interruption, one less script, and one less thing to get wrong. Privacy-respecting measurement is also simply easier to defend — to your users, and to a regulator.

If you want to see the cookie-free approach in one place, Nippy ships it by default with every site, and the help center explains exactly what is measured. Open your own DevTools on a Nippy site and check the cookie jar. It is empty.

This article describes the position in July 2026. Laws change, and their application depends on your facts. For decisions that matter, speak to a lawyer.

Related reading

Ask Claude to Publish a Website. Get a Permanent Link.

Jamie Street — Tue, 28 Jul 2026 09:53:04 +0000

I gave Claude one prompt. Claude wrote a web page and published it. The page is live at a permanent URL. I did not open a dashboard. I did not run a build.

This article shows the full procedure. You can complete it in less than five minutes.

Disclosure: I run Nippy, the hosting service in this article.

What makes this possible

MCP (Model Context Protocol) is an open standard. It lets an AI assistant call external tools. A tool can read data. A tool can also do work in the real world.

Nippy is a static hosting service. You give it files. It gives you a live URL that does not expire. Nippy has an MCP server. When you connect it, Claude gets one new ability: it can publish websites.

The result is a very short path from an idea to a live page:

prompt → Claude writes the files → one tool call → live URL

Set up the connector

There are two paths. Use the one that matches your setup.

Path A: claude.ai in the browser

Open claude.ai.
Go to Settings → Connectors.
Add Nippy as a connector.
Approve the connection.

Path B: Claude Desktop, Claude Code or Cursor

Run the MCP server with one command:

npx nippy-mcp

Add it to your client configuration. For Claude Desktop, the entry looks like this:

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

Restart the client. The Nippy tools are now available.

The Nippy help center has a full guide for each client.

Publish a page

Give Claude a prompt. This is the prompt I used:

Make a small demo page and publish it with Nippy.

Claude then does three things:

Claude writes the HTML file.
Claude calls the Nippy MCP server with the file.
Nippy returns a live URL.

The tool call is simple. This is its shape:

{
  "name": "published-by-claude",
  "files": [
    { "path": "index.html", "content": "<!DOCTYPE html>..." }
  ]
}

The response came back in a few seconds:

{
  "url": "https://published-by-claude.nippy.site",
  "status": "live",
  "note": "Live now. The link does not expire."
}

That page is real. Claude published it while I wrote this article. You can open it here: published-by-claude.nippy.site.

Update the page

A site is not frozen after the first publish. Ask Claude to change it:

Add a dark mode toggle to the demo page and publish the update.

Claude revises the files and publishes again. The URL does not change. Your shared links stay correct.

Why this is useful

Think about the things you make and throw away:

A prototype for a client call.
A chart from one analysis.
A landing page for one event.
A gallery of photographs for your family.

Each one needs a URL for ten minutes of glory. None of them deserves a repository, a pipeline and a deploy configuration. With an MCP connection, the publish step costs one sentence.

There is also a larger point. AI agents can now produce complete artifacts: reports, dashboards, small applications. An artifact that only exists in a chat window is trapped. A permanent URL sets it free. Hosting that agents can operate is the missing piece, and MCP is the interface for it.

Other ways in

The MCP route is one of three. Nippy also accepts:

Drag and drop. Drop a folder on the page. Pick an address. The site is live.
The CLI. One command: npx @nippyhost/cli deploy. CI deploys use a NIPPY_TOKEN secret.

The first publish confirms your email. There is no password.

Try it

Connect the Nippy MCP server with Path A or Path B.
Ask Claude to make a page and publish it.
Open the URL. Share it. It does not expire.

If you publish something interesting, post the link in the comments. I would like to see it.