Build and ship your own pages, without a designer or dev

Why your RevOps function should build its own pages in 2026

Quick disclaimer: we are not a web design or dev shop, this sits a little outside our usual lane. But the ability to spin up a landing page or a shareable proof asset to nurture leads in your pipeline has become a must-have for a modern RevOps function in 2026, not a nice-to-have you outsource and wait a week for. Here is why, and exactly how to get it without needing outside help.

If you run an online business, you know the feeling: you need a landing page for a specific offer, or a fresh proof page to send a prospect, and getting it made means a designer, a back-and-forth, and a week you do not have. So it does not get made, and you lose the momentum.

The alternative most people reach for is a page builder or an AI site tool. They are fast, but they trap you in two ways: everything you make looks like the thousand other pages made with the same tool, and every edit means clicking around someone else’s interface.

There is a third way, and it is the one we use for our own site and everything we send prospects. You get pages that are genuinely fast to make and change, that look like yours, and that you edit by just saying what you want, no deep tech, no design queue. A page for a new offer goes live the same afternoon you think of it. An edit a prospect’s feedback needs happens in minutes. That turnaround is a real advantage, and it is what this page hands you.

The page you are reading was built exactly this way. The animations, the layout, this article, all of it. That is the point: this is not a description of a workflow, it is the workflow showing its own receipts.

The idea in one line

You sketch the page, Claude builds it, you push it live. That is the whole loop, and everything below is just detail on those three steps.

The important part, and the thing that makes your pages look like yours instead of generic: you start with a sketch, not a prompt. The thinking happens before the generating. That one habit is the difference between a page that feels designed and a page that feels churned out.

Zero to one: your first page, start to finish

Here is the honest arc, the way it actually goes the first time.

Step 1 — Sketch the page first

Before any tech, get the shape down. This can be anything:

• boxes drawn on paper with a pen,
• a rough layout in Figma,
• or you can even ask Claude to propose a wireframe and tweak it in words.

It does not need to be pretty. You just need to decide, roughly, what goes where: a headline up top, then the three things you do, then a proof section, then a button to book. A sketch you can photograph or screenshot is perfect, because you can hand that image straight to Claude in the next step. Starting here is what keeps the result yours: you are directing the design, not accepting a template.

Step 2 — Have Claude build a simple version

Open Claude, show it your sketch, and describe the page in plain english. Claude turns the sketch into a real, working page: real layout, real styling, real text where you gave it. You look at it, and you correct it the way you would correct a designer, “make the headline bigger,” “move the button up,” “this section is too busy.” Claude makes the next pass. You loop until it looks right. No code touches your hands.

Step 3 — Push it to the stack, and it is live

When you like it, you say “push.” The page goes live on the internet automatically, usually within a couple of minutes, on your own domain. Done. The next time you want to change it, you open Claude and say what to change, and repeat.

That is zero to one. The rest of this page is the setup that makes those three steps possible, and the reference for doing it again and again.

What is running under the hood

You do not need to understand this to use it, but it helps to know what the pieces are and why they are there. Each one is doing a job so you do not have to:

Astro is the framework that builds the pages. It makes fast, clean pages that load quickly and look high quality, and it handles the technical plumbing so the effort goes into how the page looks and reads, not into making it work.

GitHub stores every version of the site. Every change is saved, so nothing is ever lost and anything can be undone. It is your safety net and your history.

Vercel puts the site live. It watches GitHub, and the moment a change is saved there, it publishes the new version to the internet. No manual “upload” step, ever.

Claude, on your computer, is the one doing the building. Through Claude Desktop with file access turned on, Claude works on the real files, checks its own work, and saves changes. It is not printing code for you to paste, it is doing the work, and you are directing it.

Put together: you describe or sketch what you want, Claude builds it and checks it, you review it on your own screen, then one word ships it live.

Before you start: the one-time setup

The whole thing is free to begin. Set these up once and you never touch them again:

• Node.js — the engine the site build needs. Install the LTS version from nodejs.org.
• A GitHub account (free) and git on your computer, for storing versions.
• A Vercel account (free tier), connected to your GitHub, for putting the site live.
• Claude Desktop, with the filesystem tool turned on so Claude can work on files on your computer. This is the piece that lets Claude do the building instead of just talking about it.

What it costs: the stack is free to start. Astro is open-source, GitHub and Vercel both have free tiers that cover a site like this, and the only paid pieces are a Claude subscription and a domain name (about $12 a year). Roughly an hour to get running.

Getting off the ground

Once the accounts exist, this is the entire first-time setup. You can have Claude run these for you, or paste them into a terminal yourself:

# 1. create a new site
npm create astro@latest my-site

# 2. move in and start the local preview
cd my-site
npm run dev            # opens the site at http://localhost:4321

# 3. save the first version
git init
git add -A
git commit -m "initial commit"

# 4. create an empty repo on GitHub, then connect and save it there
git remote add origin https://github.com/<you>/my-site.git
git push -u origin main

Then import that GitHub repo into Vercel once (New Project, pick the repo, deploy). From that point on, every save-and-push publishes automatically. You never do the “put it live” step by hand again.

Copy this into Claude to start

Once your accounts are ready, paste everything between the lines into a new Claude Desktop conversation (with file access on), then talk to it in plain english.

You are going to help me build and run my website. I am not a developer, so you
do the technical work and I will direct you in plain english.

The stack:
- Astro for the site (fast pages, good for SEO, simple content files).
- GitHub to store every version.
- Vercel to publish it live automatically when I push.
- You, running on my machine through Claude Desktop with file access, as the
  builder. You edit the real files, check your own work by running the build,
  and save to git.

How we work:
1. I describe a page or a change in plain english (often with a sketch).
2. You build or edit the real files.
3. You run `npm run build 2>&1 | tail -4` to confirm it works.
4. I look at it on the local preview and correct you.
5. We loop on 2 to 4 until it looks right.
6. Only when I say "push" do you save it to git (with a short note of what
   changed) and push to GitHub, which publishes it live.

Rules:
- Never publish without me explicitly saying "push" or "ship it".
- Reuse the styles and components we already have. Keep the look consistent.
- Keep pages fast and SEO-clean (good headings, page titles, descriptions).
- Make it look genuinely good and distinct, not like a generic template.

Start by setting up a new Astro project (or opening mine at <PATH>), confirm the
build runs, then wait for my first instruction.

Making changes later, and two things you will do constantly

Editing is the same loop as building: open Claude, say what to change, look at it, push. “Make the headline shorter.” “Swap this photo.” “Add a testimonial under the pricing.” Minutes, and it is live.

Two moves cover most of what an online business needs:

Add a new page for an offer or a proof story. Show Claude a sketch or just describe it:

“Build a page at /offer/[name] with this headline, these three benefits, this proof, and a button to book. Use the same look as the rest of the site.”

You get a real, on-brand page at its own link, ready to send in an email or a DM.

Update something a prospect flagged. After a call where someone raised a concern:

“On the [page], add a short section that answers [the concern], right above the button.”

Live in minutes, while the conversation is still warm.

Why this beats a page builder or a plain chat

A page builder is fast but keeps you inside its structure and its look, and every edit is clicking through a UI. This is faster to change (you just say what you want) and the result looks like yours, not like everyone else’s.

A plain Claude chat can write you a page, but you are then on your own to make it work, host it, and change it later. This setup has Claude working in your real project: it reuses your styles so pages stay consistent, it checks its own work so things do not break, and you get a real preview-and-correct loop. That loop is what makes the good stuff possible, custom touches, animations, layouts tuned by eye, none of which survive copy-pasting from a chat.

Short version: a chat gets you a draft. A page builder gets you a template. This gets you fast, good-looking pages that are genuinely yours, and an easy way to keep changing them.