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 rewrites them when you change your mind. That half is solved.

The half the agent cannot hand you is the boring one: an address the site 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.

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 the Bubble page is the one to read if what you are planning might really be an application.

Both products are young and 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 about Birta before you start: there is no visual editor, 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 in v0, Bolt or Lovable, 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 once the conversation gets long, but in a small file the agent reads as input. If the site is specifically a portfolio, the pieces you choose matter more than the palette, and how to make a portfolio website settles that first. Call it design.md and keep it in the project folder. It only has to answer what 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", and they are the part you keep reusing, because the next round of edits reads the same file and the agent stops re-litigating decisions you made.

If writing this kind of instruction is new, your prompt is the brief covers the craft.

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. 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 a search engine indexes each of those as a page of its own. A single-page app can be published. Its in-app navigation has to run through #: with regular paths, opening or refreshing any path other than the root returns “page not found”.

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 in your design. If the form is the main point of the site, the lead generation page guide takes that scenario the whole way.

Birta sites do not take payment yet, so 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 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 desktop app. So check rather than assume: ask the agent to list your Birta projects. If it cannot see them, connect through one of the documented paths above.

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. Because you asked it to hold, nothing reaches the public project address until you say so, and the draft gets its own address you can open in a browser. Leave that line out of the prompt and the agent publishes as soon as it considers the work done, which is the usual way to work.

Step 4: Look at it yourself first

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

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

Two minutes here saves a colleague's attention for the things you 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.

They need no Birta account. A project's version access has two settings, restricted and link, it applies to every version at once, and new projects start at link. So a colleague holding the address opens the page, leaves remarks and replies to yours, signed in to nothing, under a nickname the system issues. If the project was closed to restricted at some point, that same link sends them to a sign-in screen instead, and the agent can set access back to link.

Do not use share_project for this. It adds a full collaborator by email, someone who can publish and read your leads, and only works for people who already have an account. Right tool for a business partner, wrong one for a colleague with an opinion on a headline.

About fifteen minutes after the first remark you get one email listing what was said and by whom, with your own left out. The reviewer gets nothing.

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, the page, the element, the text, the author, 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 refreshes the tab they have open. 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 wait is there because you asked for it in step 3. The version you reviewed keeps its own address afterwards and keeps taking remarks, which is useful for a round of "one more thing" after launch.

Then the domain, where the plan matters: the free plan connects none 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: the project's Leads tab straight away, and one email about fifteen minutes later to everyone with access. No Telegram, no Slack, no webhook, no field where you type a different address. The free plan lets you read ten leads per site per month, Solo a hundred, Pro 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. 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