DEV Community: Backrun

In 2026, the Barrier to Building a Website Is Not Code. It Is Getting It Live.

Backrun — Wed, 24 Jun 2026 06:56:12 +0000

Something shifted in 2026 that most people have not fully processed yet.

The barrier to building a website is no longer knowing how to code. Multiple sources tracking AI adoption this year have landed on the same conclusion: if you can describe what you want clearly enough, AI will build it for you.

That part of the problem is mostly solved.

The barrier now is getting it live.

What the numbers say

AI tool adoption among developers hit 84 percent this year. More than 90 percent of web designers report using AI tools. The volume of code being generated has roughly doubled year over year.

But here is the number nobody puts next to those: the percentage of AI-generated HTML pages that actually make it to a live URL.

That number is not tracked anywhere. Because for most non-technical users, it is low. Very low.

The new bottleneck nobody designed for

A year ago, building a functional webpage from scratch took a developer several hours and a non-developer several days of learning. Now it takes an afternoon for a non-developer and about 45 seconds with AI.

The bottleneck moved. It used to be creation. Now it is deployment.

And the entire deployment infrastructure that exists in 2026 was built before that shift happened. It was built for developers. It assumes a terminal. It assumes Git. It assumes you know what a repository is, what a slug means, what DNS propagation involves.

None of those assumptions are true for the person who just asked Claude to build them a landing page.

That person has a finished HTML file sitting in a chat window. They have zero path from that file to a live URL that does not require learning three new tools first.

The vibe coding problem meets the deploy problem

There is a term that gained traction this year: vibe coding. Building something through AI by feel, without deep technical understanding of what is being generated.

Most commentary about vibe coding focuses on code quality. The concern is that developers are shipping code they do not fully understand, creating technical debt that compounds silently.

That concern is real. But there is a version of this problem that hits non-technical users before they even get to the quality question.

They vibe-built a page. Now what?

The answer in 2026 is still the same as it was in 2019. Open Netlify. Create an account. Connect a repo. Push a deploy. Or drag a file if you can find where the drag-and-drop option moved to in the latest UI update.

For a developer, that is muscle memory. For a marketer or solo founder or freelancer who built something with AI for the first time, it is a wall.

What actually closes the gap

The fix is not teaching non-technical users to use developer tools.

The fix is building the deploy step inside the environment where the creation happened.

That is what HTML Deployer does. It is a Chrome extension that sits inside the Claude or ChatGPT tab where your conversation is already open. It detects the HTML your AI just generated automatically. It shows you a preview across desktop, tablet, and mobile screen sizes before anything goes live. Then one click deploys to Netlify, GitHub Pages, FTP, or your own server.

No new tab. No terminal. No account setup mid-flow. No tutorial required.

The creation is already happening in the browser. The deploy should happen there too.

The broader point

Every major shift in who can build things on the web has been followed eventually by a shift in who can publish those things.

Drag-and-drop builders made design accessible. WordPress made content publishing accessible. AI is now making HTML generation accessible.

The deploy layer has not caught up yet.

In 2026, knowing how to get something live is becoming just as important as knowing how to build it. The tools that exist for the build step have changed completely in two years. The tools that exist for the deploy step have not changed at all.

That gap is where people are losing the time they thought AI just gave them back.

If you work with non-technical people who use AI to build things, what does their deploy workflow actually look like? Curious whether the wall I am describing shows up consistently or whether some teams have found a way around it I have not seen yet.

How to Copy Math Equations from Claude into Word Without Breaking the Formatting

Backrun — Tue, 16 Jun 2026 10:35:39 +0000

If you have ever asked Claude to solve a math problem and then tried to paste the result into Microsoft Word, you already know what happens.

The regular text looks fine. But the equations turn into a mess of symbols, plain text, or LaTeX code that Word has no idea what to do with.
This is one of those small friction points that sounds minor until it happens to you mid-deadline at 11pm.

Here are two methods that actually work.

Method 1: Use a browser extension to export directly

The fastest solution is a Chrome extension called Claude Exporter, available on the Chrome Web Store.

Install it, reload your Claude tab, and you will see a new export icon appear in the** upper right corner of the screen**.

Click export to Word and the extension handles the conversion automatically.

The difference compared to manual copy-paste is significant. Equations that would normally appear as raw code or broken symbols are rendered exactly as they appeared in the Claude response, formatted and ready to use inside Word.

This method requires zero extra steps from you beyond the initial install. If you regularly move content from Claude into Word documents, it is worth having.

Method 2: Ask Claude to convert the equations first

If you want more control over how the equations are formatted, skip the extension and use Claude itself.

Ask Claude to convert all formulas in its response to Word-compatible LaTeX. A simple prompt like this works:

Convert all formulas to Word-compatible LaTeX.

Claude will rewrite the equations into a structure that Word can understand. Once it does, copy the updated content, open your Word document, and place your cursor where you want the equation to appear.

Then do the following:
Press Alt and equals (Alt + =) to open the equation editor. Switch the format to LaTeX. Paste the converted formula inside the field.

If the equation still appears in linear format rather than the visual layout you expect, select it and **choose Professional **from the equation menu.

Word will render it into the full visual format with fractions, exponents, and symbols displayed correctly.

From there the equation is fully editable. You can change individual values, modify symbols, adjust fractions, or update exponents directly inside Word without going back to Claude.

Which method to use

Use Method 1when you want speed and you are moving a full conversation into a document. The extension handles everything in one click.
Use Method 2 when you need specific equations formatted a particular way, or when you are working with complex expressions and want to verify each one before it goes into the document.

Both methods solve the same problem. The manual copy-paste approach does not.

Which AI tool do you use most for math and technical work? And if you have found other ways to move equations cleanly between AI tools and Word, share them in the comments.

AI Wrote My Landing Page 3 Weeks Ago. I Have No Idea What's In It.

Backrun — Mon, 15 Jun 2026 10:06:22 +0000

This post was written with AI assistance. The ideas, experiences, and product references are my own. I used AI to help structure and articulate them more clearly.

Three weeks ago I asked Claude to build a landing page.

It took about a minute. The output was clean, structured, looked exactly right. I deployed it, sent the link to someone, moved on Yesterday a client asked me to change the CTA button color.

I opened the file.
I had no idea where anything was.

Not because the code was bad. The code was fine. But I had never read it. I watched it appear in a chat window, decided it looked right, and shipped it. The mental model I would normally build while writing code never formed because I never wrote the code.

I was looking at a stranger's work.

This is different from working with someone else's code

When you inherit a codebase from another developer, there are fingerprints. Variable names that reflect how that person thinks. Comments that explain unusual decisions. An architecture that reveals assumptions made at the start of the project.

You can reverse-engineer the intent. It takes time but the trail is there.
AI-generated code has no fingerprints.

It is technically correct, consistently structured, and completely neutral. There is no personality in it, no history, no "why did they do it this way" to chase down. It optimized for correctness, not for the person who would have to touch it three weeks later.

That person is you. And you have nothing to hold onto.

The cognitive ownership problem

There is research in learning science about the difference between recognition and recall.

Recognition is seeing something and knowing you have seen it before. Recall is being able to reconstruct it from memory without a prompt.

When AI writes your code and you review it briefly before shipping, you get recognition. The code looks familiar because you watched it appear. But you never built the deeper understanding that enables recall.

Three weeks later, recognition has faded too. You open the file cold.
Developers who write their own code build recall naturally. The act of writing forces you to make decisions, which forces you to understand the tradeoffs, which builds the mental model you need to come back to the code later.

AI skips that process entirely. Fast at generation. Zero at mental model transfer.

What this costs you

The time savings from AI generation are real and measurable. A landing page that would take 2 hours takes 45 seconds.

The costs are invisible until they are not.
Every time something breaks in code you did not write, you start from zero. No mental model to navigate by. No memory of why things are structured the way they are. Just a file full of correct-looking code that could be hiding the problem anywhere.

One developer described this exactly in a thread I was reading recently: when QA reports come in on AI-generated code, the team feeds the bugs back to the AI because nobody has the mental model to debug manually. The AI fixes the bugs it created. Sometimes correctly. Sometimes not. The team is no longer debugging. They are managing a system they do not understand.
That is not a productivity gain. That is a productivity loan with compounding interest.

The non-technical version of this problem

For developers, cognitive ownership is a real but manageable problem. You can slow down, read the output carefully, ask the AI to explain its decisions, build the mental model deliberately even if the code was generated.

For non-technical users, the problem is structural.
A marketer who generated a landing page with Claude was never going to build a mental model of the HTML. That was never the point. They needed a page, Claude gave them a page, they shipped the page.

But when something breaks, or when they need to change the offer, or when a client asks why the button does not work on mobile, they have nothing. No understanding of what they shipped. No way to fix it themselves. No path forward except going back to Claude and hoping the next output is better.

The only review step available to them is visual. Does it look right? Does it work on my phone? Is the layout broken anywhere I can see?
That review step is the only ownership they can realistically have over AI-generated HTML. And most of the time nobody builds that step into the workflow.

The one thing that actually helps

I am not going to argue that non-technical users should learn to read HTML. That is not the solution.
The solution is building the review step they can actually do into the workflow before the page goes live.

Visual review. Real screen sizes. Desktop, tablet, mobile. Before the URL exists and the client has already seen the broken version.

That is the design principle behind HTML Deployer. The extension sits inside the Claude or ChatGPT tab where the conversation happened. It loads the generated HTML automatically. It shows you exactly what the page looks like on every screen size before you deploy. Then one click and it is live on Netlify, GitHub Pages, FTP, or your own server.

The cognitive ownership problem does not fully go away. But the most expensive version of it, shipping something broken because nobody looked at it on a real screen, goes away completely.

The question worth sitting with Every AI tool that generates something asks you to make a decision before you fully understand what you are deciding about.

The faster the generation, the less time you spend with the output before shipping it.

That speed is genuinely valuable. But it has a cost that shows up later, quietly, when something breaks and you realize you are looking at a stranger's work with no map and no memory.

The question is not whether to use AI to generate. The question is what you put between generation and ship to make sure you actually own what you are about to send into the world.

Has anyone found a workflow that genuinely solves the cognitive ownership problem with AI-generated code? Not just "review it carefully" but something structural that forces understanding before shipping. Curious what people have actually tried.

How to Deploy a Static Website to GitHub Pages (The Basics + What No One Tells You)

Backrun — Thu, 11 Jun 2026 03:08:30 +0000

I've seen a lot of people generate a clean HTML page with ChatGPT or Claude, feel great about it for about 30 seconds, and then completely freeze when it comes time to actually put it online.

GitHub Pages is one of the best answers to that problem — free, permanent URLs, HTTPS included, zero server config. But the setup has a few quiet gotchas that trip people up the first time. This guide covers the actual steps, plus the two things the official docs gloss over.

What GitHub Pages is (and isn't)

GitHub Pages turns a repository into a website. That's it.

You push your files to a branch, flip a setting, and GitHub builds and serves the site from that branch. It's designed for static content — HTML, CSS, JavaScript, images. If your project needs a backend, a database, or server-side rendering, GitHub Pages isn't the right tool. But for portfolios, landing pages, documentation, demos, and microsites, it's hard to beat.

A few things worth knowing upfront:

It's free for public repos, and also available on private repos with a GitHub account
It supports custom domains — you're not stuck with username.github.io
It doesn't support server-side code (PHP, Node, Python, etc.)
For frameworks like Next.js or Vite that require a build step, you'll need GitHub Actions — this guide focuses on plain HTML/CSS/JS projects

Prerequisites

Before you start, make sure you have:

A GitHub account
A repository with your site files
An index.html at the root (this becomes your homepage)

If you haven't pushed your project yet, create a new repo on GitHub, then either upload files directly via the UI or push from your terminal:

git init
git add .
git commit -m "initial commit"
git remote add origin https://github.com/yourusername/your-repo.git
git push -u origin main

Step 1: Open Repository Settings

Go to your repository on GitHub and click the Settings tab at the top.

Step 2: Find the Pages Section

In the left sidebar, scroll down to Pages under the "Code and automation" section.

Step 3: Configure the Source

Under Build and deployment, you'll see a "Source" dropdown. Select Deploy from a branch.

Then choose:

Branch: usually main or master
Folder: /root (unless you've put your files in a /docs subfolder)

Click Save.

Step 4: Wait for the Build

GitHub will start building your site. This usually takes 30 seconds to 2 minutes the first time.

Refresh the Settings → Pages page. When it's done, you'll see a green banner:

"Your site is live at https://username.github.io/repo-name/"

Step 5: Open Your Site

Your site lives at:

https://yourusername.github.io/your-repo-name/

Bookmark it. From now on, every time you push changes to the selected branch, GitHub Pages will redeploy automatically — usually within a minute or two.

The two things that catch people off guard

1. The URL path matters

If your repo is named portfolio and your GitHub username is alice, your site is at alice.github.io/portfolio/ — not alice.github.io/. That trailing /portfolio/ affects how relative paths in your HTML work. If you link to ./style.css, it works. If you hardcode /style.css, it breaks (because that resolves to the root domain, not your project subfolder).

The fix: use relative paths for all assets, or set a <base> tag in your <head>:

<base href="/your-repo-name/">

2. Changes don't always show up immediately

GitHub Pages has CDN caching. After a push, you might see the old version for a minute or two even after the build finishes. Hard-refresh (Ctrl+Shift+R / Cmd+Shift+R) usually clears it. If you're seeing stale content during active development, consider working with a local server (npx serve . or VS Code's Live Server extension) and only pushing when you want to check the live URL.

Updating your site

Every push to the configured branch triggers a new deploy. Your workflow from this point on is just:

git add .
git commit -m "update content"
git push

No FTP, no control panel, no manual uploads.

Deploying AI-generated HTML to GitHub Pages

If you used ChatGPT, Claude, or Gemini to generate the HTML, the process above still applies — you'd copy the code, save it as index.html, commit, push, and configure Pages.

There's also a Chrome extension called HTML Deployer that skips those steps. It detects HTML code blocks directly inside the AI chat, shows a preview, and lets you publish to GitHub Pages (or Netlify, or FTP) from the same tab without touching a terminal. Useful if you're iterating quickly on a page and don't want to context-switch between tools.

Either approach gets you to a live URL. The manual route teaches you more about how GitHub Pages works; the extension is faster for repetitive deploys.

What to try next

Once you're comfortable with the basic setup, a few things worth exploring:

Custom domain: Add a CNAME file to your repo root and configure your DNS — the GitHub Pages docs cover this well
GitHub Actions for build steps: If you move to a framework that compiles output (like Astro or Eleventy), Actions lets you run the build before deploying
Jekyll: GitHub Pages has native Jekyll support, which can turn markdown files into a blog with minimal config

GitHub Pages is one of those tools that scales from a 5-minute static page all the way to a proper documentation site or blog. Starting with plain HTML is the right move — you can always layer on complexity later.

Source: https://backrun.co/blog/how-to-deploy-github-pages

Two Ways to Deploy a Website on Netlify in 2026

Backrun — Wed, 10 Jun 2026 02:14:34 +0000

Deploying a website usually starts with one question:

Where is the code stored?

If your project is already on GitHub, connecting the repository to Netlify gives you version control and automatic deployments.

If you only have a static HTML page generated by ChatGPT, Claude, or Gemini, creating a repository may add more steps than the project needs.

This guide covers both workflows:

Deploying a project from GitHub
Publishing AI-generated HTML with HTML Deployer

What Is Netlify?

Netlify is a cloud platform for building, deploying, and managing web projects.

It can connect to a Git repository, run the required build command, publish the output, and create a public URL.

When new changes are pushed to the connected branch, Netlify can automatically rebuild and redeploy the website.

Netlify also provides features such as:

Continuous deployment
Deploy Previews
Custom domains and HTTPS
Serverless Functions
Form handling
Environment variables
Global content delivery

Netlify offers Free, Personal, Pro, and Enterprise plans.

The Free plan is generally suitable for learning, personal websites, prototypes, and small experiments.

Pricing and usage limits may change, so review the current plan details before using Netlify for a production project.

Method 1: Deploy a Website from GitHub

This workflow is suitable for projects that need regular updates, version history, collaboration, or automated deployments.

Before You Start

You will need:

A GitHub account
A Netlify account
A GitHub repository containing your project
A working build configuration when required

A basic static website might have this structure:

my-website/
├── index.html
├── styles.css
├── script.js
└── images/

Make sure the website works locally before deploying it.

Step 1: Sign In to Netlify

Create a Netlify account or sign in to an existing account.

You can use GitHub as your login method, but signing in with GitHub does not automatically give Netlify access to every repository.

Repository permissions are configured separately during the project import process.

Step 2: Import Your Project

After signing in, open Sites from the Netlify dashboard.

Select Import from Git to connect an existing repository.

This tells Netlify that your project source is stored on a Git provider rather than being uploaded manually.

Step 3: Start the Deployment Setup

Select Deploy project to begin configuring the new site.

Netlify will guide you through the connection process and ask which Git provider contains your project.

Step 4: Authorize GitHub Access

Choose GitHub and complete the authorization process.

Netlify needs permission to view the repositories you want to deploy and to retrieve new changes when you update the project later.

Step 5: Install the Netlify App

GitHub will ask you to install the Netlify app.

You can give Netlify access to:

All repositories
Only selected repositories

For most projects, selecting only the repositories you plan to deploy gives you more control over account access.

Once the app is installed, return to Netlify.

Step 6: Select Your Repository

Netlify will now display the GitHub repositories it can access.

Choose the repository containing your website.

If the repository does not appear, check the Netlify app settings on GitHub and confirm that access has been granted.

Step 7: Configure and Deploy the Project

Before publishing, review the deployment settings.

Depending on the project, you may need to configure:

The branch Netlify should deploy
The build command
The publish directory

A basic HTML, CSS, and JavaScript project may not require a build command. Framework-based projects usually need both a build command and a publish directory.

When the settings are ready, select Deploy, followed by your project name.

Netlify will begin processing the repository and publish the website when the deployment is complete.

After the site is live, you can open the generated URL from the dashboard. You can also manage the domain, deployment settings, and future updates from the same project page.

Once the repository is connected, pushing new changes to GitHub can trigger another deployment automatically.

Method 2: Deploy AI-Generated HTML

A Git-based workflow is useful for maintained projects, but it may be unnecessary for a single static page.

For example, you may have generated one of the following with ChatGPT, Claude, or Gemini:

A landing page
A portfolio
A campaign page
A product prototype
A client preview
A small event website

The manual workflow would normally involve:

Copying the generated HTML
Creating local files
Previewing the page
Creating a GitHub repository
Uploading the files
Importing the repository into Netlify
Waiting for the deployment

For a small static page, a more direct workflow may be enough.

I built HTML Deployer for this use case.

HTML Deployer is a Chrome extension that detects HTML generated inside ChatGPT, Claude, and Gemini.

It lets you preview the page on desktop, tablet, and mobile before publishing it to a configured hosting target such as Netlify.

It is not intended to replace Git for larger applications.

It is mainly useful when the HTML already exists and you need to preview and share it quickly.

Configure Netlify in HTML Deployer

Before the first deployment:

Install HTML Deployer from the Chrome Web Store
Open the extension settings
Add Netlify as a publishing target
Enter the required Netlify configuration
Save the target
Confirm that the connection is working

You only need to complete this setup once unless your Netlify credentials or configuration change.

Publish the HTML Page

After configuring Netlify:

Generate a complete HTML page with ChatGPT, Claude, or Gemini
Click the Deploy button beside the HTML code
Preview the page on desktop, tablet, and mobile
Check the content, links, images, and layout
Select Netlify as the deployment target
Click Deploy to Host
Open the generated URL and test the live website

The preview step is important because AI-generated HTML can look correct on a desktop screen while still containing:

Broken mobile layouts
Missing images
Invalid links
Overflowing sections
Forms that do not submit
Scripts that fail after deployment

Publishing successfully does not guarantee that every part of the page works correctly.

Which Workflow Should You Use?

Situation	Recommended workflow
A maintained application	GitHub and Netlify
A project with regular updates	GitHub and Netlify
A team project	GitHub and Netlify
A framework-based application	GitHub and Netlify
A single AI-generated HTML page	Direct publishing workflow
A temporary client preview	Direct publishing workflow
A landing page experiment	Direct publishing workflow
A project requiring version history	GitHub and Netlify

The GitHub workflow requires more initial setup, but it provides a better foundation for ongoing development.

The direct publishing workflow removes several setup steps, but it is better suited to small static pages.

Common Deployment Problems

Page Not Found After Deployment

Confirm that the published folder contains an index.html file at its root.

Incorrect structure:

publish/
└── website/
    └── index.html

Correct structure:

publish/
└── index.html

Styles or Images Are Missing

Check whether asset paths use the correct relative URLs.

<link rel="stylesheet" href="./styles.css">
<img src="./images/product.png" alt="Product preview">

Paths that point to files on your local computer will not work after deployment.

The Build Fails

Review the deployment log and check:

The build command
The Node.js version
Missing dependencies
Environment variables
The selected base directory
The selected publish directory

The Website Works Locally but Not on Netlify

Open the browser console and check for:

Failed network requests
JavaScript errors
Blocked resources
Incorrect file paths
Missing environment variables

Checks to Make After Publishing

Review the live website on more than one screen size.

Check:

Navigation links
Mobile layout
Images and fonts
Forms
Buttons
JavaScript interactions
Page title and description
HTTPS
Custom domain settings
Browser console errors

For AI-generated pages, also inspect the HTML for placeholder content, unsupported scripts, and external resources that may stop working later.

Final Thoughts

Netlify provides several ways to publish a web project, but the right method depends on where your code is stored and how the project will be maintained.

Use GitHub with Netlify when you need:

Version control
Automatic deployments
Team collaboration
Regular updates
A structured development workflow

Use a direct static publishing workflow when you have:

A finished HTML page
A temporary prototype
A landing page experiment
A client preview
A small project that does not need a repository yet

The important part is not choosing the shortest workflow.

It is choosing a workflow that still makes sense after the first deployment.

How do you usually publish static pages generated with AI?

Source: How to Deploy on Netlify: A Step-by-Step Guide.

Two Ways to Deploy a Website on Vercel in 2026

Backrun — Tue, 09 Jun 2026 10:07:48 +0000

Most Vercel tutorials assume that your project is already stored in a Git repository.

That is usually the right workflow for applications you plan to maintain. But sometimes you only have a static HTML page generated by ChatGPT, Claude, or Gemini and need a public URL without setting up a complete repository.

This guide covers both situations:

Deploying a project from GitHub
Publishing an AI-generated static page with HTML Deployer

What Vercel Does

Vercel is a cloud platform for building and deploying web projects.

It can connect directly to a Git repository, build the project, and create a public deployment URL. When you push new changes to a connected branch, Vercel can create another deployment automatically.

Vercel also detects the configuration of many common frameworks, although you can customize settings such as:

Root directory
Build command
Output directory
Environment variables
Framework preset

For personal projects and experiments, the free Hobby plan is usually the starting point. Check the current usage limits before relying on it for a production project.

Method 1: Deploy a Website from GitHub

This workflow is best for projects that need version control, regular updates, collaboration, or automated deployments.

Before You Start

You will need:

A GitHub account
A Vercel account
A GitHub repository containing your project
A valid entry file or build configuration

For a basic static website, your repository might look like this:

my-website/
├── index.html
├── styles.css
├── script.js
└── images/

Make sure the website works locally before deploying it.

Step 1: Create a Vercel Account

Open Vercel and create an account.

You can sign up with GitHub, which also makes it easier to connect your repositories during the deployment process.

Complete any email or account verification requested during registration.

Step 2: Connect GitHub

From the Vercel dashboard, create a new project and select GitHub as the Git provider.

Vercel will ask for permission to access your repositories. You can grant access to all repositories or limit access to specific ones.

After authorization, return to the project import screen.

Step 3: Import Your Repository

Find the repository you want to deploy and select Import.

Vercel will analyze the repository and attempt to detect the framework and build configuration automatically.

For a simple static HTML project, you may not need to change anything.

For a framework-based project, review the detected settings before continuing.

Step 4: Review the Project Settings

Before deploying, check the following fields:

Project name

This is used to identify the project in your Vercel dashboard and may also affect the default deployment URL.

Framework preset

Vercel detects many frameworks automatically. Confirm that the detected framework matches your project.

Root directory

Change this when the website is stored inside a subfolder rather than at the repository root.

For example:

repository/
├── documentation/
└── website/
    ├── index.html
    └── styles.css

In this case, the root directory may need to be set to website.

Build command and output directory

Framework-based projects usually require a build command and an output directory.

For example:

Build command: npm run build
Output directory: dist

The exact values depend on the framework and project configuration.

Environment variables

Add environment variables when the project depends on API keys, service URLs, or other configuration values that should not be stored directly in the repository.

Do not commit private credentials to GitHub.

Step 5: Deploy the Project

Once the configuration looks correct, select Deploy.

Vercel will install the required dependencies, run the build process, and create a deployment.

After the deployment finishes, you will receive a public URL that can be opened in the browser.

Step 6: Publish Future Updates

Once the repository is connected, you do not need to import it again.

Update the project locally, commit the changes, and push them to GitHub:

git add .
git commit -m "Update landing page"
git push

Vercel will detect the new commit and create another deployment.

You can review previous deployments, compare changes, manage project settings, and connect a custom domain from the project dashboard.

Method 2: Deploy AI-Generated HTML

Sometimes a Git-based workflow is more than you need.

For example, you might have asked ChatGPT, Claude, or Gemini to generate:

A landing page
A portfolio
A product prototype
An event page
A campaign page
A small static website

You could copy the code into files, create a repository, push it to GitHub, and then import it into Vercel.

However, for a single static page, I wanted a shorter workflow.

I built a Chrome extension called HTML Deployer for this specific use case. It detects HTML generated inside supported AI chats, provides a responsive preview, and publishes the page to a configured hosting target.

It is not intended to replace Git for maintained applications. It is mainly useful when you need to turn a static AI-generated page into a shareable URL quickly.

Configure Vercel in HTML Deployer

The Vercel connection only needs to be configured once:

Open HTML Deployer settings
Add Vercel as a publishing target
Enter the required Vercel configuration
Save the target
Confirm that the connection is working

The exact credentials required depend on the deployment configuration used by the extension.

Publish the HTML Page

After the Vercel target is ready:

Generate a complete HTML page in ChatGPT, Claude, or Gemini
Select the Deploy button beside the HTML code
Preview the result on desktop, tablet, and mobile
Fix any visible layout or content problems
Select Vercel as the publishing target
Choose Deploy to Host
Open the generated URL and test the live page

Previewing the page before deployment is important. AI-generated HTML can look correct at one screen size while still containing broken mobile layouts, missing images, invalid links, or scripts that do not work as expected.

Which Workflow Should You Use?

Situation	Recommended workflow
A maintained web application	GitHub and Vercel
A team project	GitHub and Vercel
A project with frequent updates	GitHub and Vercel
A framework such as Next.js or React	GitHub and Vercel
A single AI-generated HTML page	HTML Deployer or manual static deployment
A quick prototype or campaign page	HTML Deployer
A project requiring version history	GitHub and Vercel

The GitHub workflow takes slightly longer to set up, but it provides proper version control and a better foundation for ongoing development.

The extension workflow removes several setup steps, but it is better suited to small static pages.

Checks to Make Before Publishing

Regardless of the deployment method, review the website after it goes live.

Check:

Desktop and mobile layouts
Navigation links
Images and external assets
Forms
JavaScript interactions
Page title and metadata
HTTPS
Environment variables
Custom domain configuration
Browser console errors

A successful deployment only means the files were published. It does not guarantee that every part of the website works correctly.

Final Thoughts

Vercel provides a straightforward deployment workflow when your project is stored in GitHub:

Connect the repository
Review the build configuration
Deploy the project
Push future updates through Git

For a small static page generated by an AI tool, a lighter publishing workflow may be more convenient.

The right option depends on what happens after the first deployment. Use GitHub when the project will continue to grow. Use a direct static publishing workflow when you mainly need to preview and share a finished HTML page.

How do you usually deploy static pages generated with AI?

Source: How to deploy a Website on Vercel - Backrun

You Don't Own the Code AI Wrote for You

Backrun — Mon, 08 Jun 2026 04:30:39 +0000

AI is getting faster at generating HTML.

That sounds like good news. For most people reading this, it probably is.

But there is a group of users for whom faster generation is actually making things worse. Not because the output is bad. Because the output is arriving faster than they can do anything with it.

The amplification problem

There is a pattern that keeps showing up in how people actually use AI at work.

AI amplifies what you already have.

If you are a developer, AI amplifies your ability to ship. You generate, you review, you deploy. The whole loop is fast because you already knew how to close it.

If you are a marketer, a solo founder, a freelancer with no technical background, AI amplifies your ability to generate. But the rest of the loop, review, debug, deploy, still runs at the same speed it always did. Which for most non-technical users is somewhere between slow and completely stuck.

Faster generation does not help you if you cannot close the loop.

It just means you have more finished HTML sitting in chat windows going nowhere.

What the data from real usage looks like

In conversations with users of HTML Deployer, a Chrome extension I built for deploying AI-generated pages without touching a terminal, the same story comes up over and over.

Someone generates a landing page with Claude. It looks exactly right. They spend the next hour trying to get it live. Sometimes they succeed.
Often they do not. The page stays in the chat. The campaign launches late or not at all.

This is not a story about AI failing. The AI did its job. The HTML is good.

This is a story about what happens after the AI does its job.

The gap is structural, not a skill problem

Every deploy tool in existence was designed with a developer-shaped user in mind.

Netlify assumes you have a file saved locally or a Git repo ready to connect. GitHub Pages assumes you understand what a repository is and why it needs to be public. FTP assumes you have hosting, credentials, and some idea of what a file path means.

These are not unreasonable assumptions if your user is a developer.

They are completely wrong assumptions if your user just typed a prompt into Claude and got back a finished page.

That user does not have a local file. They have a chat window. They do not have a Git repo. They have an output they want to share. They do not know what FTP stands for and should not have to.

The tooling gap is not about intelligence or effort. It is about who the tools were designed for and who is actually using AI right now.

Who is actually using AI right now

The fastest growing segment of AI users is not developers.

It is people who never expected to be building anything but suddenly can describe what they want and get something real back. Marketers. Consultants. Small business owners. Teachers. Freelancers who do everything themselves. People running one-person operations who used to outsource web work and now realize they can generate it themselves.

That population is enormous.

And almost none of the tooling built around AI generation was designed for them.

The part that does not get talked about enough

There is a term from software testing called plausible wrongness. The output looks correct. It passes a surface inspection. But it behaves wrong under real conditions.

The deploy situation for non-technical AI users is a kind of structural plausible wrongness.

The workflow looks like it should work. Claude gives you HTML. Netlify lets you deploy HTML. The steps should connect.

But the steps were designed for two different users. The AI was designed for everyone. The deploy tools were designed for developers. The person in the middle, the non-technical user holding a finished HTML file, falls through the gap between them.

What closing the gap actually looks like

The fix is not teaching non-technical users to use developer tools.

The fix is building the deploy step where the generation already happened.

That is the design bet behind HTML Deployer. The extension lives inside the Claude or ChatGPT tab. It detects the HTML automatically. It shows you a preview on desktop, tablet and mobile before anything goes live. It deploys to Netlify, GitHub Pages, FTP or your own server in one click.

No new tab. No terminal. No file to save. No workflow to learn.

The generation is already happening in the browser. The deploy should happen there too.

The broader point

Every time AI gets faster at generation, the gap between output and outcome gets more visible for the users who cannot close it themselves.

That gap is not going to close on its own. Developer tools will not become intuitive for non-technical users just because AI got better.

Someone has to build the bridge.

Right now, not enough people are building it.

If you work with non-technical users who use AI tools, what is the step they get stuck on most consistently? Generation is rarely the answer anymore. I am curious what comes after.

The Faster AI Gets, the Bigger the Gap It Creates for Non-Technical Users

Backrun — Fri, 05 Jun 2026 02:00:17 +0000

AI is getting faster at generating HTML.

That sounds like good news. For most people reading this, it probably is.

But there is a group of users for whom faster generation is actually making things worse. Not because the output is bad. Because the output is arriving faster than they can do anything with it.

The amplification problem

There is a pattern that keeps showing up in how people actually use AI at work.

AI amplifies what you already have.

If you are a developer, AI amplifies your ability to ship. You generate, you review, you deploy. The whole loop is fast because you already knew how to close it.

If you are a marketer, a solo founder, a freelancer with no technical background, AI amplifies your ability to generate. But the rest of the loop, review, debug, deploy, still runs at the same speed it always did.
Which for most non-technical users is somewhere between slow and completely stuck.

Faster generation does not help you if you cannot close the loop.

It just means you have more finished HTML sitting in chat windows going nowhere.

What the data from real usage looks like

In conversations with users of HTML Deployer, a Chrome extension I built for deploying AI-generated pages without touching a terminal, the same story comes up over and over.

Someone generates a landing page with Claude. It looks exactly right. They spend the next hour trying to get it live. Sometimes they succeed. Often they do not. The page stays in the chat. The campaign launches late or not at all.

This is not a story about AI failing. The AI did its job. The HTML is good.

This is a story about what happens after the AI does its job.

The gap is structural, not a skill problem

Every deploy tool in existence was designed with a developer-shaped user in mind.

These are not unreasonable assumptions if your user is a developer.

They are completely wrong assumptions if your user just typed a prompt into Claude and got back a finished page.

That user does not have a local file. They have a chat window. They do not have a Git repo. They have an output they want to share. They do not know what FTP stands for and should not have to.

The tooling gap is not about intelligence or effort. It is about who the tools were designed for and who is actually using AI right now.

Who is actually using AI right now

The fastest growing segment of AI users is not developers.

That population is enormous.

And almost none of the tooling built around AI generation was designed for them.

The part that does not get talked about enough

There is a term from software testing called plausible wrongness. The output looks correct. It passes a surface inspection. But it behaves
wrong under real conditions.

The deploy situation for non-technical AI users is a kind of structural plausible wrongness.

The workflow looks like it should work. Claude gives you HTML. Netlify lets you deploy HTML. The steps should connect.

What closing the gap actually looks like

The fix is not teaching non-technical users to use developer tools.

The fix is building the deploy step where the generation already happened.

No new tab. No terminal. No file to save. No workflow to learn.

The generation is already happening in the browser. The deploy should happen there too.

The broader point

Every time AI gets faster at generation, the gap between output and outcome gets more visible for the users who cannot close it themselves.

That gap is not going to close on its own. Developer tools will not become intuitive for non-technical users just because AI got better.

Someone has to build the bridge.

Right now, not enough people are building it.

If you work with non-technical users who use AI tools, what is the step they get stuck on most consistently? Generation is rarely the answer anymore. I am curious what comes after.

I Started Counting the Steps Between AI Output and Something Real

Backrun — Wed, 03 Jun 2026 09:27:02 +0000

Something changed in how I use AI tools about three months ago.

I stopped asking "can AI do this?" and started asking "how many steps does it take to go from AI output to something I can actually use?"

That question changed everything.

The output is not the product

When ChatGPT or Claude generates something for you, what you get is raw material. Not a finished thing. Raw material.

A developer gets code. They still need to run it, test it, debug it, deploy it.

A marketer gets HTML. They still need to put it somewhere, get a URL, send it to someone.

A founder gets a landing page. They still need to figure out hosting, domain, publish flow.

The AI part is fast. Genuinely, impressively fast. 45 seconds for a complete HTML page is real and it matters.

But we got so excited about the 45 seconds that nobody counted what came after.

I counted

Here is what it actually takes to go from "Claude gave me an HTML file" to "I have a live URL I can share" using the default workflow most people end up with.

Copy the HTML from the chat
Open a new tab
Create or log into a Netlify account
Find the deploy option
Save the HTML as a file locally
Drag the file into Netlify
Wait for deploy
Copy the URL
Realize the URL is something like rainbow-unicorn-a3f92.netlify.app
Go back and configure a custom domain
Wait for DNS propagation

That is eleven steps. Eleven steps between a finished AI output and something a real person can open on their phone.

Some of those steps take 30 seconds. Some take 20 minutes. Some fail and send you back to step 4.

The AI saved you 2 hours of writing and design work. The deploy process took 45 minutes on a good day and 3 hours when something went wrong.

The honest math

People talk about AI productivity in terms of what it generates. Nobody talks about the total workflow.

Total workflow = generation time + everything after

For a developer, "everything after" is second nature. Git push, CI/CD picks it up, done. The steps are invisible because muscle memory made them disappear years ago.

For everyone else, every single step is visible, unfamiliar, and potentially a dead end.

This is the real productivity gap. Not whether AI can write good code. It can. The gap is between the output and the outcome.

What I actually changed

I started optimizing for step count, not generation quality.

A slightly worse output that takes 2 steps to use beats a perfect output that takes 11 steps every time.

That thinking led me to build HTML Deployer, a Chrome extension that cuts the HTML-to-live-URL flow from 11 steps to 3.

Step 1: the extension detects the HTML Claude or ChatGPT just generated, no copy-paste.
Step 2: you preview it on desktop, tablet, and mobile before anything goes live.
Step 3: you pick a target, Netlify, GitHub Pages, FTP, or your own server, and click deploy.

That is it. You never leave the tab. You never touch a terminal. You never save a file.

The generation is still 45 seconds. The deploy is now under 60 seconds too.

The question worth asking about every AI tool

Before you add another AI tool to your workflow, count the steps between its output and something you can actually use.

If the answer is more than 3, the tool is probably not saving you as much time as the demo suggested.

The AI part of the problem is mostly solved. The handoff part is where the time is actually going.

How many steps does your current AI-to-live workflow
take? Curious whether the 11-step version I described
is common or whether people have found shorter paths
I haven't seen yet.

Your AI-Generated HTML Looks Perfect. Have You Seen It on a Phone?

Backrun — Tue, 02 Jun 2026 02:08:01 +0000

There is a specific kind of confidence that comes from looking at AI-generated HTML in a chat window.

It looks clean. The structure makes sense. The copy is right. You've been staring at it for five minutes and you can't find anything wrong.

So you deploy it.

Then someone opens it on their phone and sends you a screenshot.

The heading is overflowing the screen. The CTA button is half-hidden behind the bottom navigation bar. The form fields are so small that tapping them is basically a game of precision. The layout that looked perfect on your 1440px monitor is completely broken on a 390px screen.

This has a name in software testing: plausible wrongness.

The output is technically correct. It passes a surface inspection. But it behaves wrong under real conditions.

Why AI-generated HTML fails on mobile

AI writes for the happy path.

When you prompt Claude or ChatGPT to build a landing page, it optimizes for what you asked for. Clean HTML. Good copy. Reasonable structure. It has no way of knowing what device your audience uses, what screen size your client will open the link on, or whether that hero section collapses gracefully at 375px.

It also has no skin in the game. It hands you the output and moves on. The consequences of plausible wrongness land on you.

Developers catch this early because the review loop is short. Generate, open in browser, resize window, check mobile, fix, repeat. The feedback is immediate.

For non-technical users the loop doesn't exist at all. They see the HTML in the chat. It looks right. They find a way to get it live. Someone opens it on a phone.

That's when they find out.

The review step that nobody builds in

Every conversation about AI-generated code focuses on two moments: generation and debugging.

Nobody talks about the moment between them.

Preview.

Not preview in the chat window. Not preview in a desktop browser. Preview that shows y

I Asked AI to Build Me a Landing Page. Getting It Live Took 3 Hours.

Backrun — Mon, 01 Jun 2026 02:30:57 +0000

I asked Claude to build me a landing page. It took 40 seconds.

Getting it live took 3 hours.

Not because I'm bad at tech. Because the entire handoff between "AI gave me HTML" and "page is on the web" was designed for someone who isn't me.

Here is exactly what happened.

Claude generated a clean, complete HTML file. Looked right in the chat. I copied it.

Then I opened Netlify. Created an account. Got asked for a team name.Typed something. Got asked for a project name. Typed something else. Looked for the drag-and-drop deploy option I'd seen in a tutorial. Couldn't find it. The UI had changed.

Opened YouTube. Found a tutorial. It was from 2022. The sidebar it referenced didn't exist anymore.

Went back to Claude. Asked how to deploy to Netlify. It gave me CLI commands.

I don't have Node installed on this machine.

Opened a new tab. Searched "deploy HTML without terminal." Found a Reddit thread from 2021. Someone suggested GitHub Pages. Opened GitHub. Created a repo. Got confused about whether it should be public or private. Picked public. Tried to upload the file. GitHub asked me to commit with a message. I typed "first commit." The page deployed but showed a 404. Turned out I needed the file named index.html not page.html.

Renamed it. Redeployed. Waited.

3 hours after Claude handed me a finished HTML file, I had a live URL.

The hell loop nobody talks about

There's a term from AI coding discussions called the "hell loop" — when an agent goes in circles trying to fix a bug it created itself. You lose the thread, forget where you started, spend more time recovering context than actually solving the problem.

The deploy version of this is the same thing.

Tab 1: the HTML sitting in the chat.
Tab 2: Netlify, half-configured.
Tab 3: a tutorial that's out of date.
Tab 4: Stack Overflow.
Tab 5: back to Claude, asking for help deploying.
Claude suggests the terminal again.

You are now debugging the deploy process instead of shipping the thing you built.

Why this keeps happening

Every deployment tool was built by developers for developers. The mental model is: you have a local environment, you have Git, you have a terminal, you know what a CLI flag means.

That mental model does not describe the person who just used Claude to build a landing page for their campaign. It doesn't describe the solo founder testing an offer. The freelancer sending a quick demo to a client. The marketer who got a beautiful HTML file and just needs a URL.

AI lowered the floor for creation dramatically.
The deploy floor didn't move.

What actually fixed it for me

I got frustrated enough to build a Chrome extension called HTML Deployer that sits inside the Claude or ChatGPT tab where the conversation already happened.

It detects the HTML automatically. No copy-paste. You preview it on desktop, tablet, and mobile before anything goes live. Then you pick where it goes: Netlify, GitHub Pages, FTP, or your own server.
Click deploy. Get a URL.

The whole thing takes under 60 seconds and you never leave the tab.

I built it because I was tired of paying the deploy tax on every single project. Turns out a lot of other people were paying it too.

If you've hit this wall before, what was your workaround? And if you're a developer reading this thinking "just use Netlify drop" — try explaining that to someone who has never seen a deploy pipeline in their life. That's the gap.

The Deploy Tax: The Hidden Cost Nobody Talks About After AI Generates Your Code

Backrun — Fri, 29 May 2026 02:40:16 +0000

There's a cost that shows up right after AI writes the code.

Not the debugging cost. Not the "works on my machine" cost. The one that comes even earlier, before any of that.

The deploy cost.

Here's what I mean

You prompt Claude or ChatGPT to build a landing page. It does it in 45 seconds. Clean HTML, good structure, looks exactly right in the chat window.

Then what?

For developers, this is trivial. Push to GitHub, Netlify picks it up, done.

But most people using AI to build web pages right now are not developers. They are marketers running campaigns. Solo founders testing an offer. Freelancers building a quick demo for a client. No-code builders who can generate beautiful HTML but have never touched a terminal in their life.

For them, the 45-second generation is followed by a loop that looks something like this:

Tab 1: the AI chat with the HTML sitting there
Tab 2: Netlify, where they get confused about "team names" and "project slugs"
Tab 3: a YouTube tutorial from 2021 that references a UI that no longer exists
Tab 4: Stack Overflow
Tab 5: back to the AI asking how to deploy. The AI gives them terminal commands. They don't have a terminal open.

They close the tab. The HTML never goes live.

This is not a skill problem

It's a tooling problem.

The entire deploy workflow was designed by developers, for developers. Nobody designed the last mile for the person who just used AI to build something real but has no idea what Git is.

@harsh2644 wrote about the debugging tax this week: 30 seconds to generate, 5 hours to debug. That ratio is real.

But there is a deploy tax sitting right next to it. Except this one doesn't even get to debugging. It stops at "how do I put this on the web" and the answer has always been "go learn something first."

The gap I built something to close

That's why I built HTML Deployer, a Chrome extension that sits inside your ChatGPT or Claude tab.

It detects the HTML your AI just generated, lets you preview it on desktop and mobile before you publish, and deploys it to Netlify, GitHub Pages, FTP or your own server in one click.

No terminal. No new tab. No workflow to learn.

The generation got fast. The deploy should too.

What's your deploy workflow when you're working with AI-generated HTML?

Curious whether this is just a problem I was seeing or something others run into too.