Build a Website Without a Website Builder

You already have the builder

If you pay for Claude or ChatGPT, the thing that builds the website is already open on your screen. It writes the HTML, the styles and the browser code, in whatever design you describe, and it rewrites them when you change your mind. That half of the problem is solved.

The half the agent cannot hand you is the boring one: an address the site actually lives at, somewhere for enquiries to land, and a domain with your name on it. That is the gap a website builder used to fill, and it is the only piece you still have to go and get.

So this guide skips the shopping list. Seven steps, from an empty page to your own domain. If you are weighing a specific builder rather than the category, the alternatives pages take one tool at a time and say where it still earns its subscription. The Bubble page is the one to read if what you are planning might really be an application rather than a site.

Both products are young and both are still rolling out, so check what your own plan includes today rather than trusting this table in six months. Neither is on a free tier.

One thing to know about Birta before you start, so nothing surprises you later. There is no visual editor here, no template gallery and no drag-and-drop canvas. The agent writes the site and Birta publishes it. If you would rather drag blocks around a page, a builder really is the better product, and we have written that down properly.

If you already have a prototype sitting in v0, Bolt or Lovable, your job is a different one. Start at sharing an AI prototype instead.

1. Step 1DesignSettle the look first and write it into a design.md the agent reads.
2. Step 2BriefSay what the site is for, which pages exist, and what the form collects.
3. Step 3BuildConnect Birta once, then ask for a draft rather than a published site.
4. Step 4CheckOpen the draft address yourself before anyone else sees it.
5. Step 5ReviewSend the version to a colleague; they mark up the page and the agent reads it.
6. Step 6PublishPut it live and connect your domain.
7. Step 7Run itKnow where enquiries land and what the visitor numbers can tell you.

Step 1: Settle the design and write it down

Decide how the site should look before the agent writes a line. Not in the chat, where it evaporates the moment the conversation gets long, but in a small file the agent reads as input. Call it design.md and keep it in the project folder.

It only has to answer the questions the agent would otherwise guess at:

Feel: calm, plain, a little bit expensive. Not playful.

Colours:
- background #FBFAF7
- text #1A1A1A
- one accent #0F6C5F, used for links and the button and nowhere else

Type:
- headings: one serif, generous size, tight line height
- body: system sans, 17px, line height 1.6
- never more than two fonts

Spacing:
- one column, max width 680px
- big gaps between sections, small gaps inside them

Reference: the feel of a well-set book page, not of a SaaS landing.

Don't:
- no gradients, no shadows, no icons from a set
- no stock photography
- no animation beyond a link hover

Three lines of "don't" save more time than a page of "do". They are also the part you will keep reusing, because the next round of edits reads the same file and the agent stops re-litigating decisions you already made.

If writing this kind of instruction is new to you, your prompt is the brief covers the craft. This guide just needs the file to exist.

Step 2: Say what the site has to do

Now the site itself. Pages, the one thing you want a visitor to do, and what you need to collect when they do it.

Build a static site from design.md in this folder.

Pages: home, services, about, contact. Real .html files, not a single-page app
with client-side routing. Every internal link ends in a slash or in .html.

The one action: get an enquiry. A short form on the home page and on contact.

Declare a Birta form with key "enquiry" and these fields:
- name, short text, required
- email, email, required
- message, long text, required
- consent, consent, required

Write the form markup in the site's own design, handle the refusal codes, and
show my own wording on success. Don't publish yet.

Two constraints worth understanding rather than copying.

Keep it static. Birta serves finished browser files. Anything that has to keep running on a server, a database, sign-in, private keys, background jobs, belongs on an application platform instead. The static-site test is the short version.

Ask for real pages, not a single-page app. An ordinary multi-page static site works fine: a request for /services/ is served services/index.html, and any .html path is served directly. What breaks is a site with one index.html at the root that resolves routes in the browser, because a direct hit on /services finds no file there and returns a 404. Telling the agent this in the brief is cheaper than finding it after launch.

The nine field types a Birta form accepts are short text, long text, email, phone, number, date, single choice, multiple choice and consent. There is no form block and no template: the agent writes the markup itself, in your design. If the form is the main point of the site rather than one part of it, the lead generation page guide takes that scenario the whole way.

Birta sites do not take payment yet, so if you need to sell on the page, put a payment link on it and collect the money elsewhere.

Step 3: Let the agent build a draft

Connect Birta to your agent once, from the connection guides. Claude web, Claude Desktop, Claude Cowork, Claude Code, ChatGPT on the web, the ChatGPT desktop app, Codex and Cursor each have their own page, because each one connects differently.

There is no separate guide for ChatGPT Work yet, and we have not verified whether Work mode picks up the MCP servers configured in the ChatGPT desktop app. So check rather than assume: ask the agent to list your Birta projects. If it can see them, you are connected. If it cannot, connect through one of the documented paths above and build there.

Then ask for a draft, not a live site:

Create a new Birta project called <name> and put this site in a draft version.
Don't publish it. Give me the draft's address when you're done.

The agent writes the files into a draft. Nothing is served at a public project address until you say so, and the draft gets its own address you can open in a browser.

Step 4: Look at it yourself first

Open the draft address in a private window, so nothing cached hides a missing file. Then do four things:

1. Walk the one action you defined in step 2, start to finish.
2. Reload the page halfway through, which exposes anything that only lived in memory.
3. Check it at phone width as well as on the desktop.
4. Click every internal link and confirm nothing 404s.

Two minutes here saves a colleague's attention for the things you actually want their opinion on.

Step 5: Let someone else mark up the page

Send them the draft address. They open it, click the heading or button or paragraph they mean, and type. The remark sticks to that element as a numbered pin.

By default, they need no Birta account for this. A project's version access has exactly two settings, restricted and link, it applies to every version of the project at once, and new projects start at link. So a colleague holding the address can open the page, leave remarks and reply to yours, signed in to nothing. They appear under a nickname the system issues rather than a name they choose.

If you have closed the project to restricted at some point, that same link sends them to a sign-in screen instead. Ask the agent to set version access back to link and send it again.

Do not use share_project for this. That tool adds a full collaborator to the project by email, someone who can publish and read your leads, and it only works for people who already have a Birta account. It is the right tool for a business partner. It is the wrong one for a colleague giving an opinion on a headline.

About fifteen minutes after the first remark lands, you get one email listing what was said and by whom, with your own remarks left out. The reviewer gets nothing; the notification is for the people with access to the project.

Then hand it over:

I left remarks on the draft. Read them and fix the site.

The agent reads every thread on that version: the number, which page it is on, which element it is pinned to, the text, who wrote it and whether it is resolved. Thread numbers never move and are never reused, so "do number 3 but keep the wording of number 5" is a sentence that works.

The draft address stays the same across rounds, so your reviewer keeps the tab they already have open and refreshes it. The full mechanics are in versions and remarks.

Step 6: Publish it and connect your domain

When it looks right, say so. The agent publishes the draft and only then does the project address start serving it.

The version you just reviewed keeps its own address afterwards, and it keeps taking remarks, which is useful for a round of "one more thing" after launch. Your live address is the clean one.

Then the domain. This is where the plan matters, so here is the honest line: the free plan connects no custom domain and keeps a small Birta mark on the published site. Solo, at $12 a month, connects one domain and lets you hide the mark. Pro, at $39, connects five. The custom domain walkthrough covers the DNS records and what to expect while they propagate.

Everything else in this guide, including the whole review loop, works on the free plan.

Step 7: What happens once it is live

Enquiries land in two places and only two. They appear in the project's Leads tab straight away, and they arrive by email about fifteen minutes later, in one message to everyone with access to the project. There is no Telegram, no Slack, no webhook and no field where you type a different address.

The free plan lets you read ten leads per site per month, Solo a hundred, and Pro has no limit.

For traffic, ask the agent for the project's stats over a week, a month or a quarter. What comes back is a visitor total and a breakdown by day, week or month. That is the whole picture: no referrers, no sources, no funnels, no way to tell that a particular person visited. It answers "is anyone coming", not "where from".

Frequently asked questions