DEV Community: Usman Haider

Add Sitelas to Claude in One Click — Then Say This First

Usman Haider — Wed, 05 Aug 2026 06:46:00 +0000

Adding a connector is the easy part. You click a button, a permission screen appears, you click again, and you land back in a chat box that looks exactly like it did thirty seconds ago.

That's where most people stop. Nothing on screen says anything changed, so the natural move is to close the tab and mean to come back to it.

This post is the other half. Everything below is a real screenshot of a real session — the listing, the permission prompt, the build, and the site that came out of it.

Step 1: Add it from the directory

Open the Sitelas listing in Claude's directory and click add.

That's the whole setup. No URL to paste, no config file to edit. Claude sends you to Sitelas to sign in — or create your account, if you don't have one — and approve the connection, then drops you back where you started.

Two things worth reading on that screen. Sitelas sits in the Community tier, and Claude tells you plainly what that means: community connectors have undergone automated reviews, and may not yet meet the quality tier of verified connectors. And the description is the honest scope of the thing — Claude picks a template, customizes it, publishes to your domain, then handles edits, contact-form messages and analytics, all from chat.

Using Claude Code or Claude Desktop instead? Those read connectors from a config file and never see the directory, so they still take the raw MCP endpoint: https://sitelas.com/api/mcp.

Step 2: Read the screen before you click Connect

One screen stands between the click and the connection, and it's the only place that spells out what you're handing over.

The left column is what Claude can do in your account: build a site from a template or design a new one, edit pages, publish, undo the last publish, read your form messages and contacts, draft replies, point a custom domain at a site, read its analytics — and delete a site, if you ask it to.

That last one is in the "can" column on purpose. Naming the uncomfortable capability is what makes the right-hand column worth believing:

It can't charge you. It can hand you a checkout link; the payment happens on Polar's page, not through Claude.
It can't change or delete your Sitelas account. No such tool exists.
It can't reach sites that aren't yours. Every tool is scoped to the account that approved the connection.
It can't see anything outside Sitelas.

Everything Claude builds also shows up in your normal editor. Connecting doesn't move your sites somewhere Claude-shaped — same sites, same dashboard, second way in.

Step 3: The first thing to say

Describe the thing you want the way you'd describe it to a person — what it's for, roughly how it should feel, what the visitor should do. Here's the exact sentence I used:

Build a one-page site for Fettle & Spoke, a neighbourhood bike workshop — repairs, servicing and wheel building. Warm and hand-made feeling, not corporate. Add a contact form so people can ask about a repair.

The first time Claude reaches for a Sitelas tool, it asks:

You approve per tool, or once for all of them. Either way the first move is yours.

Then it works. Not by filling in a template — it looked at the closest archetype and rejected it out loud: "Gable is the closest archetype but it's built around a multi-page before/after project portfolio — overkill for a warm one-pager." So it composed the page from primitives instead, picked the type, and went looking for workshop photography.

Note the step in the middle — "Created successfully. Let me take a look at how it actually renders before showing you." It screenshotted its own work before handing it over.

The bit that matters: nothing is public yet

What came back is a preview, not a live site. That isn't a figure of speech. At the moment Claude finished, here is what the two addresses actually returned:

URL	Status
`preview-fettle-and-spoke-1522.sitelas.com`	200 — the finished site
`fettle-and-spoke-1522.sitelas.com`	404 — doesn't exist yet

So you get to see the whole thing, click every link, and change your mind, with no chance of anyone stumbling onto a work in progress. Here's what was sitting at that preview address:

The second thing to say is whatever you want changed:

"Warmer palette, and cut the hero copy to two sentences."
"Move the enquiry form above the workshop story."
"Swap the photo for something with more negative space."

Each one updates the draft and hands back the same preview link, refreshed. When it's right, say "publish it" — the only step that makes anything public, and it only ever happens because you asked.

Step 4: The prompt people forget — after it's live

Most website tools stop caring once the site ships. This is the half that makes the connector worth keeping.

Every form on your site sends submissions to your Sitelas inbox with no setup at all — the repair-enquiry form on Fettle & Spoke was wired the moment it was built.

You can read that in the dashboard whenever you like. Or you can just ask, in the same chat that built the site: "Any new messages this week, and where did they come from?" Claude already has the context — it built the page, it knows which form is in the hero and which is in the footer, and it reads the results without you exporting anything. If you want submissions somewhere else too, each form takes a webhook URL in the editor, which covers Zapier, Make, n8n, or your own endpoint.

The three sentences, together

If you only remember one thing from this post, make it these:

"Build me a [what it is] — [how it should feel]." → a designed draft and a private preview.
"Change [the thing you don't like]." → same preview, updated. Repeat freely.
"Any new messages on my site this week?" → your form submissions, read back to you.

Everything above happened in one sitting, in one chat, with no dashboard open. That's the whole loop.

Next: launching a waitlist from Claude Cowork follows the same loop on a page that's already live and collecting signups. If you'd rather hand the work to an autonomous agent than type in a chat, an AI agent can build and run a site with an account API key instead. And running your website from the same chat that built it goes deeper on the operate half.

Add Sitelas from Claude's directory →

Launch a Waitlist From Claude Cowork — Then Ask It What Came In

Usman Haider — Mon, 27 Jul 2026 11:13:25 +0000

Launching a waitlist is the easy half. You can get a decent page up in an afternoon.

The half that dies is the running of it. Two weeks later nobody has opened the form tool, nobody knows whether Tuesday brought four signups or none, and the "we'll review them weekly" habit lasted exactly one week. The page is still live. The loop is dead.

So I tried something different for my last one: I launched it from Claude Cowork , and before I closed the workspace I asked Claude to check the signups every morning and email me what came in. That second sentence is the one that interests me — it's what turns a page you published into a loop you can actually stay on top of.

The product is Loopin , a fictional group-chat planning app I use for demos. The page is real and live at loopin-7992.sitelas.com, and the digest email is real too — I've quoted it in full below rather than describing it. Here's the whole loop, end to end.

Cowork vs. a chat (the 30-second version)

If you've only used claude.ai as a chat, Cowork is the same Claude with a workspace around it: a task view, progress tracking, and — the part that matters here — scheduled tasks. You can hand Claude a job and a time, and it runs on its own.

That's the difference between the waitlist I ran from a single chat and this one. In a chat, you're present for every step; the work happens because you're there. In Cowork, you set the job up once and it keeps happening while you're doing something else.

Both need Claude to actually be able to touch your site. That's what the connector is for.

Connect Sitelas once

One-time setup: Sitelas is in Claude's connector directory, so adding it takes one click — open the listing and choose Add.

Using Claude Code or Claude Desktop instead? Those read a config file rather than the directory, so point them at https://sitelas.com/api/mcp.

Sign in, approve, done. Claude can now design sites, publish them, read form submissions, and pull analytics — for any Sitelas site you own. The connector is available in Cowork the same way it's available in a chat; you'll see Sitelas listed under the workspace's connectors.

Step 1 — Launch the page

I opened a Cowork task and described the product rather than the design:

Build a waitlist page for Loopin — it lives inside your existing group chat and turns "we should get dinner sometime" into an actual calendar invite. Works with iMessage, WhatsApp, Discord, Telegram, Slack. Warm and a bit funny, not enterprise SaaS. Email capture, and a short "how it works" section.

Claude picked an archetype, wrote the copy, and came back with a preview URL — not a live site. This is worth understanding because it's how every Sitelas change behaves: work lands on a draft, you get a preview link, and the public URL doesn't change until you say publish. You can iterate as many times as you like; visitors keep seeing the last published version, or nothing at all if you've never published.

I asked for two changes — a warmer headline, and the channel logos moved above the fold. Each came back as an updated preview. When it read right, I said make it live, and Claude published it.

The headline it landed on:

Someone says "soon." Loopin makes it Thursday.

That's better than what I'd have written, and I say that as the person who would have written it.

One honest note about the page: the social-proof numbers on it ("9,300+ group chats") are demo copy from the design, not real signups. The real count is one, and it's mine — which becomes relevant in a moment, and is a more useful thing to show you than a fake number.

Where the signups actually go

Every submission from that form lands in the Sitelas inbox — your dashboard, under Messages. No setup, no third-party form tool, no spreadsheet to wire up. That's the default and it's the only destination you need.

That is the real Loopin inbox, and it contains exactly one entry — mine. I submitted the form myself on launch day to check it worked. Each entry expands to show exactly the fields the form asked for; a form with more fields shows more. The fact that it is otherwise empty matters in a minute.

If you do want submissions somewhere else, each form has a "Forward to webhook" setting in the editor: point it at an HTTPS endpoint — Zapier, Make, n8n, your own handler — and each submission is POSTed there as well. That's the route to a Google Sheet or a CRM, via a Zap that appends a row. There's no OAuth dance and no accounts to link; it's one URL field.

The reason this matters for the automation: because submissions live in Sitelas, Claude can read them through the connector. No export, no CSV, no "log in and check."

Step 2 — The part that makes it run

Here's the actual move. Still in Cowork, I created a scheduled task :

Every morning at 9:30, check the Loopin waitlist for submissions from the last 24 hours. Email me a short digest: how many signed up, who they are, and anything that stands out. If there were no new signups, say so in one line — don't skip the email.

Then I approved it once, and closed the tab.

Three things about that prompt are deliberate, and each one is a thing I got wrong before getting it right:

"Email me." Cowork scheduled tasks run on their own and show their results in the app. If you want something in your inbox, the task has to say so. The mail then arrives from Claude's own address — mine came from no-reply-claude@mail.anthropic.com — not from Sitelas, and not from your own account. Leave that sentence out and the task still runs perfectly; you just have to go and look at it, which is the exact habit that dies.

"Last 24 hours." Without a window, you get a digest of the entire list every morning, which stops being information by day three.

"If there were no new signups, say so — don't skip the email." This is the one I'd argue for hardest. A system that only speaks up on good news is indistinguishable from one that's quietly broken, and you find out which you have three weeks in, when you discover the form stopped submitting on day two. The empty email costs nothing and it's the only proof the loop is still alive.

What the digest actually looks like

I was impatient, so the next morning I test-fired the task by hand instead of waiting for 9:30. The email arrived a couple of minutes later, from Claude's own address:

Loopin: 1 new waitlist signup in the last 24h — usman.haider.pro@outlook.com, Sun 26 Jul 9:47 PM PKT. That's the first signup ever, so all-time total is now 1 and there's no meaningful trend yet. Quota is fine: 1 of 50 used this month, resets 1 Aug. Note the form only asks for an email, so no name was captured. Submission left unread for your triage.

That one signup is me — I'd filled in my own form the previous evening to check that submissions actually landed, and it fell inside the 24-hour window. As proof that the world wants Loopin, it's worthless. As a picture of what the loop does, it's exactly right.

Read what's in that paragraph. I asked for "how many signed up, who they are, and anything that stands out." What came back was the count, the address, the timestamp, the all-time total for context, the month's quota, the reason no name was captured, and a note that it had left the submission unread so I could triage it myself.

None of that is a database dump. Claude opened the actual submission through the connector and wrote up what it found — which is only possible because the submissions live in Sitelas rather than in a form service Claude can't see.

The task itself is one row on Claude's Scheduled page. That is the whole of the automation — no server, no cron file, no dashboard of my own to maintain. If I want it to stop, I delete the row.

The loop, in one picture

That's the entire shape of it, and it's worth stating plainly because it's the bit that's genuinely new:

You describe the page. Claude builds it and hands you a preview URL. Nothing is public until you say publish.
A visitor fills in the form. The submission lands in your Sitelas inbox — no form service, no spreadsheet, no wiring.
You ask Claude what came in. It reads that inbox through the connector and answers in plain English, on demand or on a schedule.

Every one of those steps happens in the same place, with the same assistant, and none of them asks you to export anything.

The honest caveats

A few things Sitelas doesn't do, so you can plan around them rather than discover them:

No bulk email sender. When you're ready to invite the list, Claude can draft individual emails through your own Gmail connector — genuinely good for a focused early-access batch, and not a substitute for Mailchimp at 50,000 addresses.
No CRM and no native scheduling. The inbox is a list of submissions, not a pipeline.
Commerce is single-item. A waitlist doesn't need it, but if you're thinking of a paid pre-order: Sitelas supports one Stripe payment link per item, not a cart.

And one about Cowork: a scheduled task is Claude doing the work on a timer, not a background service inside Sitelas. It's worth knowing which system owns which half — Sitelas holds the site and the submissions; Cowork holds the schedule.

One note on my own demo, so you're not misreading the screenshots: the digest I've quoted is a manual test fire , not the 9:30 run. I set the schedule up, fired it twice by hand to see the output, and then deleted the task — with one submission in the inbox, and that one mine, there was nothing for it to watch yet. The mechanism is the same either way; I just don't want you to think I've been running this for weeks.

Why this is different from a website builder

The page took about fifteen minutes. Any decent builder could have done that part.

What no static-site builder can do is the second half: the site is an automation endpoint sitting next to your other connectors , so the same assistant that built it can read its submissions, summarize them, and put them in your inbox on a schedule — without you exporting anything or opening a dashboard.

That's the actual pitch for running a site from the same place you built it. And it's the same capability an autonomous agent uses when it builds and runs a site with an API key — Cowork is just the friendlier door to it.

Try it

Add Sitelas from Claude's connector directory — one click — then ask Claude to build the waitlist you've been putting off.

Then, before you close the tab, ask it to check the signups every morning and email you what it finds. That second sentence takes ten seconds and it's the difference between a page and a loop.

Sitelas — the website builder for AI agents.

Can an AI Agent Build and Run a Website?

Usman Haider — Fri, 24 Jul 2026 07:50:25 +0000

Short answer: yes — and not just build. On Sitelas, an AI agent with a single API key can design a real site, publish it to a live URL, and then run it: read the messages that come in, check the traffic, ship an edit. Here's exactly what an agent can do — and where a human stays in the loop.

"Can AI build a website?" stopped being an interesting question about a year ago. Every tool can generate a page from a prompt now. The interesting question is the next one: can an agent — Claude, or an autonomous coding agent — build a real website, publish it, and keep running it, without a person clicking through a dashboard?

On most platforms the answer is "sort of." An agent can generate code, or hit a deploy API — but what it produces is a codebase somebody still has to own, and there's no "run it" story at all. Sitelas is built for exactly this: a site isn't a code export, it's a live thing an agent can create and operate through an MCP connector. Here's what that actually means.

Two ways an agent gets in

There are two doors, and they lead to the same room.

Interactive — you, in a Claude chat. You add the Sitelas connector in claude.ai — it is in Claude's connector directory, one click —, and now Claude can act on your site inside the conversation you're already having.

Headless — an agent, with an API key. For an autonomous agent (say, Claude Code, or your own script), Sitelas issues a personal API key. You create it in your dashboard's Account tab; the agent sends it as Authorization: Bearer … to the MCP endpoint and gets the exact same tools the interactive connector does — no reduced set, no "read-only for robots." A headless agent is a first-class citizen.

Either way, the agent isn't just talking about your website. It can do things to it.

What an agent can build

Give an agent a description and it composes a real site — not a wireframe, not a code dump. Under the hood it picks a design that fits the brief, writes the copy, lays out the pages, and sources real photography (no "hero-image.jpg" stand-ins — actual images).

What comes back is a private preview. And this is the important part: nothing goes live until a human says so. Even when you tell Claude "build it and publish," it builds, previews, and asks — it won't push an unreviewed page to your live URL.

The site loaded in the builder at the top of this post is a real one, composed by Sitelas from a brief exactly like that — the design system, the type, the layout, the photography, all real. An agent produced the whole page from a sentence; the visual editor is there for when you'd rather click than type.

What an agent can run (the part most tools skip)

Building is the easy half now. The half that matters — and that almost no "AI website" tool touches — is day 2: the leads, the replies, the edits. Because a Sitelas site lives inside Claude, the same agent that built it can operate it.

Ask an agent "any leads this week?" and it reads your form submissions — they land in your Sitelas inbox automatically, with no setup and no Google account. Ask "how's traffic?" and it pulls your analytics. It can draft replies, publish an update, or restyle the site, all by being asked. Your website becomes an automation endpoint sitting next to your other connectors, the way your Gmail and Calendar already are. That's the thing a Webflow or Squarespace site simply can't be.

Where a human stays in the loop (on purpose)

An agent that can do everything is also a liability, so Sitelas draws the line deliberately:

Publishing is a decision, not a default. The agent previews and asks; a human approves what goes live.
Money stays human. An agent can't move a site onto a paid plan on its own — checkout is a link a person completes. It builds and runs on the free tier; a human decides to pay.
Your domain stays yours. Connecting a custom domain needs DNS records only you can add at your registrar.

The pattern is the same each time: capability is the easy half; control is the design. An agent does the work; a human keeps the keys to what ships and what costs money.

How to point an agent at Sitelas

For yourself, in claude.ai: add Sitelas from Claude's connector directory — one click. Now every chat can build and run your site.
For a headless agent: generate an API key in your Sitelas dashboard and hand it to the agent. Same tools, no chat required.

Either way, the site stays yours — you keep control of what publishes.

The honest version

"An AI agent builds your website" sounds like a demo. The real story is smaller and better: an agent can take a site from a sentence to a live URL, and then keep it running — while you stay in control of the two things that matter, what publishes and what you pay. That's not a magic trick. It's a website that finally lives somewhere an agent can reach.

New here? How to Build a Website From a Claude Chat walks through the build end to end, and Run Your Website From the Same Chat That Built It goes deep on the day-2 operating loop.

Try it

Add the connector in claude.ai (https://sitelas.com/api/mcp) and tell Claude what to build — or start in your browser at sitelas.com.

Run Your Website From the Same Claude Chat That Built It

Usman Haider — Tue, 14 Jul 2026 12:39:58 +0000

Everyone can generate a website now. Type a prompt, get a decent page — that part is a commodity. The question nobody's answering is what happens on day 2: the leads start arriving, a line of copy needs a tweak, someone asks for a section you forgot. That's when a website stops being a design project and becomes a thing you have to run — and where most tools hand you yet another dashboard to log into and dread.

Sitelas makes a different bet. Because a Sitelas site lives inside Claude through an MCP connector, the same chat that built the site also runs it. You don't open an admin panel to see who filled out your form, write back, or change the page. You just ask.

Here's what "running your site from a chat" actually looks like.

First, the 30-second why

Claude connects to outside tools through MCP connectors — you already use the ones for Gmail, Calendar, and Drive. Sitelas has one too.

Add it once — it is in Claude's connector directory, so it is one click — and Claude can do things with your site, not just talk about it: publish it, read its submissions, restyle it, add a section.

Your site becomes an automation endpoint sitting next to your other connectors — the thing a Webflow or Squarespace site can't be.

New here? Start with How to Build a Website From a Claude Chat.

"Did anyone fill out my form today?"

That single question is the whole idea. You ask; Claude reads your site's submissions, surfaces the new lead — Maya, a bakery owner — and drafts a warm reply in your voice. One message, no tabs.

It works because every form on a Sitelas site captures submissions to your inbox automatically — no integration required. You can open that inbox in the dashboard any time:

…but running your site from a chat means you rarely need to. Claude reads those same submissions straight from your site, so "who wrote in today, and what do they want?" is answered in the thread you're already in — not in a panel you have to remember to check.

Sending leads to a spreadsheet

Say you want every lead in a Google Sheet you can sort and share.

Here's the thing: you don't wire anything up. Claude already reads your Sitelas submissions. And if you've added Claude's own Google Sheets connector, it can already write to your Drive. So you just ask:

"Put this week's leads in a Google Sheet."

Claude pulls the submissions from your site, creates the Sheet in your Drive, and fills in the rows. No OAuth screen on our side. No third-party automation service. Nothing to maintain. Two connectors already sitting in the same chat, doing the boring part between them.

Want it automatic, without asking? Drop a webhook URL into the form's settings and every submission forwards the instant it arrives — to a Zapier "Catch Hook" that appends the row, or straight to Slack, or your CRM. Your Sitelas inbox stays the source of truth either way.

Changing the site itself — still just a chat

Running a site isn't only inbox work; it's the site too. "Add an FAQ section." "Make the hero warmer." You say it, and Claude edits — but it previews first, so your live page never changes until you approve it:

This is the part worth underlining: Claude shows you a preview URL, and the live site keeps serving the old version until you say "publish." Edits accumulate in the preview; nothing goes public by surprise. When it looks right, one word — "publish" — pushes it live, and a one-step revert is always there if you change your mind.

The whole loop, in one window

You: "Anyone fill out my contact form today?" Claude: reads your submissions, surfaces the lead.
You: "Draft a warm reply, and put this week's leads in a Google Sheet." Claude: drafts the reply and writes the rows into your Drive.
You: "Add an FAQ section and warm up the palette." Claude: edits, shows a preview.
You: "Publish." Claude: it goes live.

No dashboard-hopping. No export-sort-reimport. No glue code. The context never resets — so the chat that knows who wrote in is the same one that drafts her reply, and the same one that ships the new section.

The honest caveat

This is a conversational way to run a site, not an enterprise ops suite.

No built-in CRM.
No native bulk-email sender. Claude drafts individual replies through your own Gmail — perfect for a focused early stream of leads, not a 50k blast.
No native bookings.
Commerce is single-item checkout — one Buy button per product or tier, via a payment link you supply — not a full cart or inventory system.

When your funnel outgrows a chat, bring dedicated tools. For the day-to-day of a small site — reading leads, replying, keeping the page fresh — this is the loop, and it lives where you already work.

Why this is different

That's the wedge: your site isn't a destination you visit, it's an endpoint you operate — next to every other tool you already run in Claude.

Prefer not to leave for claude.ai? There's an editor too

Everything above runs from a chat — but you don't have to. Every Sitelas site also opens in a visual editor with the same AI built in: describe an edit in plain language and it happens on the canvas, or click any element and adjust it by hand.

And if you want to see the read-submissions-then-act loop pushed further — scoring signups and drafting invites — I Launched a Waitlist and Ran It From One Claude Chat walks through it end to end.

Try it

Add the Sitelas connector in Claude (https://sitelas.com/api/mcp), publish a site, then just start asking: who filled out the form, draft them a reply, put the leads in a Sheet, add a section.

Set up an account at sitelas.com, connect it to Claude, and run your site from the chat you're already in.

I Turned My Resume Into a Portfolio Site — From One Claude Chat

Usman Haider — Mon, 22 Jun 2026 09:12:36 +0000

Everyone tells you to "have a portfolio site." The advice is right; the gap is the problem. You already have a résumé — a tidy PDF with your roles, projects, and skills — and turning it into a live, good-looking website is an afternoon of fighting a builder, nudging columns, and second-guessing fonts. Most people never close that gap.

Sitelas closes it in one prompt. Because it plugs into Claude as a connector, the résumé you already have is the input. You attach the PDF in the chat, ask for a portfolio, and Claude reads it, designs around it, and hands you a real Sitelas site — previewed privately, published only when you're ready. I did exactly that with my own résumé. Here's how it went.

All you need is the PDF

No new content to write, no template to shop for. If you can drag a file into a chat, you can do this.

One-time setup: Sitelas is in Claude's connector directory, so adding it takes one click — open the listing and choose Add.

Using Claude Code or Claude Desktop instead? Those read a config file rather than the directory, so point them at https://sitelas.com/api/mcp.

Sign in to Sitelas when prompted. From then on, Claude can build sites, change themes, read form submissions, and publish — all from chat.

Step 1: Attach your résumé and ask

Drop the PDF into the composer and type one line — "create me a portfolio website using Sitelas, résumé attached." That's the whole instruction.

Claude reads the résumé straight from context — your summary, roles, projects, skills — and treats it as the brief. It weighs the portfolio templates and picks the one whose register fits — for mine, a dark single-page "engineer" layout. It doesn't dump the PDF into a page; it maps each part of the résumé onto the matching section of a designed template, then builds the site.

How Claude turns a résumé into a site

This is the part that's easy to underestimate. A résumé has structure — a headline role, a summary, a reverse-chronological work history, a project list, a skills block, education — and a good portfolio has the same structure in a different shape. Sitelas's job is the mapping:

Your title and summary become the hero and About section.
Work history becomes an experience timeline.
Projects become a project grid, one card each.
Skills become a tech-stack strip; education its own block.

It also picks a template whose register fits the résumé. Mine reads as a senior software engineer, so it chose a dark, two-column "engineer" layout — restrained, monospace accents, the kind of thing that signals "I ship." A designer's résumé would land somewhere brighter and more visual. You're not picking from a dropdown of 40 themes; Claude picks the one that fits and customizes it to you.

You get a private preview first — nothing is public yet

Just like building from scratch, the portfolio lands as a draft. Claude hands you a preview URL that's private to you, and the permanent address stays a 404 until you publish. So you can click through the whole thing, read every section, and change anything — reword the About, reorder projects, swap the palette — before a single recruiter sees it.

This is also the moment to fill any gaps. If the template leans minimal and your résumé has more — a full skills grid, an education block, contact details — just say so, and Claude adds the sections. Every edit re-previews; the live site stays untouched until you publish again.

Step 2: Publish when it looks right

When the preview reads the way you want, tell Claude to make it live.

Claude promotes the draft to the permanent URL and archives the previous state, so a one-step revert is always available. The site is now live at a real address you can put on LinkedIn, in an email signature, or at the top of your next application.

The result

Here's what came back from my résumé — a dark, two-column portfolio with a sticky profile card, an About section, an experience timeline (xMap, Turing, Decision Labs), a projects grid, and social links, all pulled straight from the PDF.

It reads like a site someone built on purpose, not a résumé pasted into a wrapper — because the content is mapped into a real design, not poured into a box.

Make it yours

A generated portfolio is a strong starting point, not a cage. Everything is editable two ways: keep prompting Claude in the same chat ("add an education section," "make the accent green," "move Projects above Experience"), or open it in the visual editor and adjust by hand with the same draft → preview → publish flow. You can also wire up a contact form so messages reach you — and because the site lives next to your other Claude connectors, you can read and reply to those messages from the same window.

Why do this from a chat at all?

Because the portfolio is never really "done." You change jobs, ship a project, win an award — and updating the site is one more message in a chat that already knows your history, not a login-and-relearn chore. The same window that built it keeps maintaining it. That's the difference between Sitelas and a traditional builder: it's a site that lives where you already work. For the from-scratch version of this flow, see How to Build a Website From a Claude Chat; to start from an existing page instead of a résumé, see I Cloned a Website From a Claude Chat.

Try it

Add the Sitelas connector in Claude, attach your résumé, and ask for a portfolio. Review the private preview, tweak anything, then publish. Start at sitelas.com.

I Cloned a Website From a Claude Chat

Usman Haider — Sun, 21 Jun 2026 21:21:38 +0000

There's a moment when you find a layout you wish you'd built — a landing page that just works, an old site of your own you want to move, a competitor's structure you'd like as a starting point. The usual answer is "open the dev tools and start copying." Slow, brittle, and you end up with a pile of HTML that isn't really yours to edit.

Sitelas does it in one prompt. Because it plugs into Claude as a connector, you can hand Claude a URL, say clone this , and get back a real, editable Sitelas site — previewed privately first, published only when you're ready. I did exactly that with nextjs.org. Here's how it went, end to end, and the one honest caveat that matters.

What "clone" actually means here

This isn't a screenshot and it isn't an <iframe> wrapper. Claude captures the page — the full-page render, the DOM with computed styles, the design tokens (palette, type scale, spacing), and the real image URLs — and then rebuilds it section by section as a Sitelas site. The output is a normal site made of Sitelas's own building blocks, with a proper header, footer, theme, and pages.

Which means the moment it exists, it's yours to change : reword the hero, swap the palette, drop a section, wire up a form — by prompting Claude or in the visual editor, exactly like any site you build from scratch. The clone is your starting point, not a frozen copy. (New to the build flow? Start with How to Build a Website From a Claude Chat.)

First: connect Sitelas to Claude

One-time setup: Sitelas is in Claude's connector directory, so adding it takes one click — open the listing and choose Add.

Using Claude Code or Claude Desktop instead? Those read a config file rather than the directory, so point them at https://sitelas.com/api/mcp.

Sign in to Sitelas when prompted. Claude can now capture URLs, compose sites, change themes, and publish — all from chat.

Step 1: Hand Claude a URL and say "clone it"

You give it the address; Claude does the rest in one turn — capture, study, rebuild, preview.

Watch what it actually does: it captures nextjs.org, reads the structure and design tokens straight off the page (the black-on-white palette, the Geist / Geist Mono typography), pulls the real image URLs, then composes a fixture that mirrors the original — and saves it as a draft.

What came back was a faithful, section-by-section replica: the ▲ hero with "The React Framework for the Web" and the npx create-next-app@latest code pill, the "What's in Next.js?" feature grid, the "Powered By" tooling cards (React, Turbopack, SWC), the deploy-templates block, the eight-logo showcase wall ending in customer testimonials, and the full multi-column footer with an email signup form.

Side by side, the original and the clone read as the same page — same structure, type, and layout — except the one on the right is a real Sitelas site I can edit, restyle, and republish from chat.

You get a private preview first — nothing is public yet

Just like building from scratch, the clone lands as a draft. Claude hands you a preview URL (preview-nextjs-clone-1983.sitelas.com) that's private to you; the permanent address stays a 404 until you publish. So you can click through the whole thing, decide what to keep, and change anything before a single visitor sees it.

This is also where you'd start making it your own — different copy, your palette, your sections. A clone you publish verbatim is rarely the goal; a clone you adapt is the fast way to a site that's genuinely yours.

Step 2: Publish when you're happy

When the preview looks right, tell Claude to make it live.

Claude promotes the draft to the permanent URL and archives the previous (empty) state, so a one-step revert is always available. nextjs-clone-1983.sitelas.com is now a real, live site.

The honest caveat: copied images are copied images

This is the part to take seriously. When Claude rebuilds a page, it reuses the real assets from the source so the clone looks right — which means the imagery, logos, and screenshots are pulled straight from the original and are very likely copyrighted. That's fine for a personal demo or a private prototype. It is not fine to publish someone else's photography, logos, and brand art as your own.

So the responsible flow is: clone to get the structure and layout fast, then replace the borrowed pieces with your own. Claude can swap every image for licensed stock in one pass — just ask — and the text is yours to rewrite anyway. Treat a clone as scaffolding, not a finished product, and you stay on the right side of this.

When cloning is the right move

Migrating your own site. You already own the content and brand — clone it into Sitelas, then edit and publish from chat going forward.
A starting layout you'll customize. Admire a structure? Clone it as scaffolding, then change the copy, palette, imagery, and sections until it's your site, not theirs.
A fast prototype. Stand up a realistic page to test an idea, knowing the assets get swapped before anything ships.

What it's not for: republishing someone else's brand, art, and copy verbatim. The capability is powerful; the imagery caveat above is the guardrail.

Why do this from a chat at all?

Same reason the rest of Sitelas lives in Claude: the context never resets. The chat that cloned your page can keep going — restyle it, connect a form to Google Sheets, read submissions, draft replies through Gmail — without you opening a dashboard. The clone isn't a dead end; it's the first step of a site you run from the same window. For a full worked example of that loop, see I Launched a Waitlist and Ran It From One Claude Chat.

And if you'd rather fine-tune by hand, every cloned site opens in the visual editor with the same draft → preview → publish flow.

Try it

Add the Sitelas connector in Claude, paste a URL, and say clone it. Review the private preview, swap the borrowed imagery for your own, customize until it's yours, then publish. Start at sitelas.com.

I Launched a Waitlist and Ran It From One Claude Chat

Usman Haider — Thu, 18 Jun 2026 19:58:30 +0000

A waitlist is the cheapest demand test you can run before you build the thing. The problem is the plumbing: a landing-page tool, a form tool, a spreadsheet to watch the signups, and then — when you finally have a list — a mail-merge to invite the right people. Four tools and a long evening, for what should be a two-day experiment.

I ran the whole thing for a fictional indie SaaS, Juno (an analytics co-pilot), from a single Claude chat. Page to published list to drafted invites. Here's exactly how — and why it's a category no static-site builder can touch.

What an MCP connector actually is (30-second version)

Claude can connect to outside tools through MCP connectors. Add one, and Claude can do things in that tool for you, not just talk about it. You already use the Gmail, Calendar, and Google Drive connectors. Sitelas has one too — add it and Claude can design sites, publish them, and read your form submissions, all from chat. That's the difference between "Claude gives me launch advice" and "Claude runs the launch." (Want the plain step-by-step first? See How to Build a Website From a Claude Chat.)

Step 1: Connect Sitelas to Claude

One-time setup: Sitelas is in Claude's connector directory, so adding it takes one click — open the listing and choose Add.

Using Claude Code or Claude Desktop instead? Those read a config file rather than the directory, so point them at https://sitelas.com/api/mcp.

Sign in to Sitelas when prompted, and switch on the Gmail and Google Sheets connectors while you're there (we'll use them for the sheet and the invites). Setup's done; everything else is just asking.

Step 2: Ask Claude to build and publish the launch page

You describe it once — Claude picks a layout, writes the form, previews it , and publishes:

That's the real, branded launch page at the top of this post — live on the web, with a working waitlist form. Because you told it to publish, Claude previews the page and pushes it live in one go; for any change after launch it shows you a preview first, so your live page never changes until you say go. Every submission already lands in your Sitelas inbox. Want changes? "Add a launch countdown." "Make the hero darker." You say it; Claude edits, previews, and republishes. No drag-and-drop, no template wrestling.

Step 3: Ask Claude to drop the signups into Google Sheets

Every signup already lands in your Sitelas inbox — no setup, nothing to connect on Sitelas's side. Want them in a spreadsheet you can slice? Just ask Claude:

"Put my Juno waitlist signups in a Google Sheet and keep it updated."

Claude reads the signups from your site with the Sitelas connector, then writes them to a sheet in your own Drive using its own Google Sheets connector — the same one you'd use for any other Sheets task. Sitelas never sits in the middle, and your visitors never see a login screen. New signups? Ask Claude to refresh the sheet.

Step 4: Let the signups roll in — then ask Claude to score them by fit

Post the link on X, in your communities, on launch day. As signups arrive, Claude reads them straight from your site's submissions — no exporting, no sorting a spreadsheet by hand. You ask:

A 400-row spreadsheet becomes a ranked, reasoned shortlist — the people most likely to convert and give you real feedback, first. Then you push on it like a growth partner: "Who mentioned churn?" "Group the enterprise ones for a separate track."

Step 5: Ask Claude to draft the invites

Gmail is already connected, so you close the loop in the same chat:

Claude drafts a personalized invite for each of your top signups — referencing what they said they'd use Juno for — plus a warm "you're on the list" note for everyone else. You review, approve, send. From "waitlist is live" to "best 20 invited" without leaving the window.

The whole loop, in one window

You:"Build & publish a waitlist page." → Claude (Sitelas) ships it. You:"Put the signups in a Google Sheet." → Claude reads them from Sitelas and writes them to your Drive with its own Sheets connector.…signups keep arriving in your inbox… You:"Score the signups by fit, give me the top 20." → Claude (Sitelas) returns a ranked shortlist. You:"Draft the early-access invites." → Claude (Gmail) writes them, personalized.

A handful of messages and one quick click. One window. A live landing page, a self-updating list, AI segmentation, and drafted invites.

What makes this different

It's not that any single piece is new — it's that there are no handoffs. Normally the page lives in one tool, the signups in another, the segmentation in your head, the invites in a fourth tab. Every gap is glue work. Routing it through Claude's connectors collapses that into one conversation where the context never resets — Claude already knows who scored highest when it drafts their invite, because it's the same chat that ranked them.

That's the part a Webflow or Squarespace site can't do: your site isn't a destination, it's an automation endpoint sitting next to every other tool you run in Claude. Form submission → fit score → personalized invite, composed in one thread — no Zapier seat, no dashboard-hopping, no glue code.

	The usual patchwork (page + form + sheet + mail-merge)	Claude + Sitelas connector
Tools to juggle	4	1 (Claude)
Build + publish the launch page	Separate tool	In chat
Auto-collected signups	Maybe	Yes → your inbox (+ Sheets via Claude)
AI scoring / segmentation	No	Yes
Personalized invites from one place	No	Yes (Gmail)

Prefer not to leave for claude.ai? There's an editor too

Everything above runs from claude.ai — but you don't have to. Every Sitelas site also opens in a visual editor with the same AI built in : describe an edit in plain language and it happens on the canvas, or click any element and tweak it by hand.

The honest caveat

This is a lightweight, conversational pipeline — not a full growth stack. There's no native bulk-email sender (Claude drafts individual messages through your own Gmail, which is perfect for a focused early-access list, not a 50k blast), and no built-in CRM. When your list is huge and your funnel is mature, bring dedicated tools. But for the launch itself — where the real work is having a page up and inviting the right people fast — this is the whole loop in a chat window.

Try it

Add the Sitelas connector in Claude (plus Gmail and Google Sheets). Ask it to build and publish your waitlist page, drop the signups into a Google Sheet, score the ones that land, then draft the invites. Set up an account at sitelas.com, connect it to Claude, and launch from the chat you're already in.

How to Build a Form and Connect It to Google Sheets

Usman Haider — Thu, 18 Jun 2026 19:58:30 +0000

A form is how your site turns visitors into leads — a contact request, a waitlist signup, a project inquiry. In Sitelas you build one in the visual editor; every submission lands in your inbox automatically, and from there you can forward it wherever you already work — a Google Sheet, Slack, your CRM — with a single webhook. Here's the whole thing, start to finish.

(New to the editor? Start with How to Use the Sitelas Editor; this guide picks up from there.)

Step 1: Add a form in the editor

Open the page where you want the form and add a Form block:

Click the + (add block) where you want it, and choose Form from the block list. A form drops onto the canvas with starter fields.
Click any field to edit it in the settings panel — change its label , switch its type (short text, email, phone, dropdown, long text, file upload), and toggle required.
Use + Add field for anything extra (company, budget, "how did you hear about us"), and set the submit button label.

Keep it short — name, email, and one "what do you need" field converts better than a ten-field wall. When it looks right, Publish the site so the form is live and can start collecting.

Step 2: Every submission lands in your inbox

Before you connect anything, every form already works. Submissions are captured and show up in your site's Messages inbox — open your dashboard, pick the site, and click Messages.

You can read entries, filter unread, reply, and export to CSV — no setup required. The inbox is always the destination; forwarding just sends a copy somewhere else.

Step 3: Forward submissions with a webhook

Want each submission to also drop into a spreadsheet, a Slack channel, or your CRM? Add a webhook — one HTTPS URL that Sitelas POSTs each submission to the moment it arrives.

In the editor, click your Form block and open its settings. In the Forward to webhook field, paste a webhook URL, then republish. That's it — every new submission is sent to that URL, with all its fields (and links to any uploaded files) as JSON.

The webhook is the universal connector: point it at an automation tool and route the data anywhere you already use.

Step 4: Get submissions into Google Sheets

To land each submission as a row in a Google Sheet, put a Zapier (or Make ) automation between your form and the sheet:

In Zapier, create a Zap with Webhooks by Zapier → Catch Hook as the trigger. Copy the webhook URL it gives you.
Paste that URL into your form's Forward to webhook field (Step 3) and republish.
Submit your own form once so Zapier sees a sample.
Add a Google Sheets → Create Spreadsheet Row action, map the fields, and turn the Zap on.

Now every submission appends a row to your sheet, in your own Google account — and it still lands in your Sitelas inbox as the source of truth. The same pattern works for Airtable, Notion, Slack, or an email tool: swap the second step for whatever you use.

What about file uploads?

If your form has a file upload field (a résumé, a brief, a logo), Sitelas stores the file securely for you — no Google account or setup needed. The attachment shows up in your inbox as a download link, and the webhook payload includes that same durable link, so whatever you forward to (your sheet, your CRM) gets a working file link too.

Recap

Add a Form block in the editor and set your fields.
Publish — the form is live and submissions land in your Messages inbox automatically.
Forward to webhook (in the Form block's settings) → point it at Zapier/Make → Google Sheets, Slack, or your CRM.
File uploads are stored for you and shared as secure download links.

Try it

Open your dashboard, add a form to a page, publish, and read your first submission in the inbox. When you're ready to route it onward, drop a Zapier webhook URL into the form's settings. You can also drive the whole thing from a Claude chat — building the form, publishing, and reading submissions by just asking; here's how building from a chat works, and how a waitlist runs from one chat. Start at sitelas.com.

How to Build a Website From a Claude Chat

Usman Haider — Thu, 18 Jun 2026 19:58:30 +0000

Most website builders make you open an app, pick a template, and start dragging things around. Sitelas has a visual editor too — but you don't have to use it. Because Sitelas plugs into Claude as a connector, you can build, restyle, and publish a real website by just describing it in a chat.

The part that makes this safe — and genuinely different — is the flow: Claude shows you a preview before anything goes public. Nothing is live until you say so. Here's the whole loop, with a freelance photographer's portfolio as the example.

First: connect Sitelas to Claude

One-time setup: Sitelas is in Claude's connector directory, so adding it takes one click — open the listing and choose Add.

Using Claude Code or Claude Desktop instead? Those read a config file rather than the directory, so point them at https://sitelas.com/api/mcp.

Sign in to Sitelas when prompted. That's it — Claude can now design sites, change themes, publish them, and read your form submissions, all from chat.

Step 1: Describe the site — Claude builds a draft and previews it

Tell Claude what you want in plain language: the kind of site, the vibe, the pages.

Claude picks a fitting design, writes the copy around your brief, drops in stock imagery to start, and saves it all as a draft. Then it hands you a preview URL — something like preview-linden.sitelas.com.

This is the important bit: that preview is private and the draft is not public. Your real address (linden.sitelas.com) returns a 404 until you publish. So you get to see the whole site, click through every page, and decide what to change — with zero risk of anyone stumbling onto a work-in-progress.

Step 2: Review and refine — keep prompting until it's right

Open the preview, look it over, and tell Claude what to change. Want a different look? Just describe it — Claude restyles the whole site at once.

Change the palette, rewrite the hero, swap a photo, add a section — each request updates the draft , and Claude gives you back the refreshed preview. Your live site still doesn't exist yet, so iterate as much as you like:

"Make the palette warmer and a touch darker."
"Tighten the About copy — two sentences, not a paragraph."
"Swap the cover image for something with more negative space."

Keep going until the preview is exactly what you want. There's no penalty for changing your mind ten times — it's all just the draft.

Step 3: Publish when it's right

When the preview looks the way you want it, tell Claude to make it live.

Claude promotes the draft to your public address and confirms it's live. Now linden.sitelas.com is a real website you can share anywhere — a link in your bio, a business card, an email signature.

Editing later: the same preview-then-publish loop

Here's where the flow really pays off. Once your site is live, new changes don't touch it. Ask Claude for an edit and it stages the change as a fresh preview — your live site keeps serving the last published version until you publish again.

So you can add a contact form, refresh your portfolio, or change your rates without ever putting a half-done edit in front of visitors. You review the new preview, tweak it if you need to, and publish when it's ready — exactly like the first time.

The mental model

It's the same model whether you work from chat or the visual editor, and it's worth holding onto:

The preview is always your latest draft. Every change Claude makes shows up here first.
The live site is your last publish. It only changes when you explicitly say "publish."

That gap between draft and live is the whole point. You experiment freely in the preview; visitors only ever see the version you signed off on.

Why do this from a chat at all?

Because the context never resets. The same Claude that built your site can connect Google Sheets to your contact form, read the submissions that come in, and draft replies through your Gmail — all in the same conversation. Your site stops being a separate destination you log into and becomes one more thing Claude can do for you, next to your email and calendar. For a full worked example — launch page → signups → scored shortlist → drafted invites — see I Launched a Waitlist and Ran It From One Claude Chat.

And if you'd rather point and click for a particular change, every site still opens in the visual editor with the same draft → preview → publish flow. Chat and editor edit the same draft, so you can move between them freely.

Try it

Add the Sitelas connector in Claude, then ask it to build the site you've been meaning to make. Review the preview, prompt until it's right, and publish when you're happy. Start at sitelas.com.

How to Use the Sitelas Editor

Usman Haider — Thu, 18 Jun 2026 19:58:30 +0000

Every Sitelas site opens in a visual editor in your browser. It's where you nudge things by hand — change a headline, swap a color, add a page — and where you publish when you're ready. You reach it from your dashboard: open a site and hit Edit. By the end of this guide you'll have restyled a site, added a page, made an edit with the built-in AI, and published it — no code, no template wrestling.

That's the whole editor up top. Three regions to know:

Left rail — Home, Pages, Theme, and the AI assistant.
Canvas — your actual site, fully interactive. Click any element to select and edit it.
Bottom bar — edit/live and device toggles on the left; Discard, Save, Preview, and Publish site on the right.

Notice the amber strip up top: "Not published yet — visitors see a 404 until you publish." That's the lifecycle talking — more on it at the end.

Edit vs. live, and previewing on mobile

The bottom-left toggles change how you see the canvas:

Edit — the working mode. Click elements, edit text inline, drag focus around.
Live preview — the same page without edit handles, exactly as visitors see it.
Desktop / Mobile — flip the canvas between a full-width view and a phone frame to check responsiveness before you ship.

For a shareable preview, the Preview button in the bottom bar opens your site's preview URL in a new tab — a real, live link that always shows your latest draft (safe to send to a client; it's excluded from search engines).

Restyle everything from the Theme panel

Open Theme in the left rail to change the look of the whole site at once — no element-by-element editing.

You get brand colors (primary, secondary, accent, background, surface), text & border tokens, and typography (display and body fonts). Change a token here and it cascades everywhere that token is used, so the whole site stays consistent.

Pages: single pages and collections

Open Pages to manage your site's structure. There are two kinds.

Single pages — one page, one URL (Home, About, a landing page). Add, rename, duplicate, or delete them; New page creates one from scratch.
Collections — one design, many entries. The project collection here powers every /work/<project> detail page from a shared template, so adding a new project gives you a new page automatically — no rebuilding the layout. Collections are how you run a blog, a portfolio of case studies, a listing of events, and so on.

Click any page to edit it on the canvas; click a collection to manage its items.

Make changes by describing them — the AI panel

Don't want to hunt for the right control? Open the AI panel and just say what you want.

Type something like "make the hero background darker," "rewrite the intro in a warmer tone," or "add a pricing page," and the assistant makes the edit directly on the canvas. You can shift-click elements first to point it at exactly what you mean. It's the same draft you're editing by hand — so you can mix manual tweaks and AI edits freely.

How draft, preview, and publish fit together

This is the part worth understanding clearly, because it's what keeps your live site safe while you experiment.

A new site starts as a draft. When you create a site — from a template or blank — it isn't public yet. Its live URL returns a 404 (that amber banner), while its preview URL shows the draft so you can review and share it.
Every change lands in the draft. Edit text, swap the theme, add a page, run an AI edit — each Save updates your draft, and the preview reflects it immediately. Your live site doesn't change at all.
Publish promotes the draft to live. Hit Publish site and the current draft becomes the public site. The banner clears.
Keep editing — changes pile up in the draft again. After publishing, new edits go back into the draft (and the preview) and accumulate there. Visitors keep seeing the last published version until you publish again. Changed your mind? Discard drops the unsaved edits.

So the mental model is simple: the preview is always your latest draft; the live site is your last publish. You can iterate as much as you like without anyone seeing a half-finished change.

Forms and integrations

Your site can also collect leads — a contact or signup form whose submissions land in your Sitelas inbox and can auto-route to Google Sheets or a webhook the moment someone hits submit. Building a form and wiring it to Google Sheets is its own short guide: How to Build a Form and Connect It to Google Sheets.

Try it

Open your dashboard, create a site from a template (or start blank), and hit Edit. Restyle it from the Theme panel, add a page, ask the AI to change something, flip to mobile to check it — then Publish when it looks right. Prefer not to click around? You can do all of this from a Claude chat instead — see How to Build a Website From a Claude Chat. Start at sitelas.com.

I Hired My First Engineer Without Leaving a Claude Chat

Usman Haider — Thu, 18 Jun 2026 07:51:56 +0000

Hiring your first engineer usually means five tabs: a website builder, a form tool, a spreadsheet, your inbox, your calendar. Every handoff between them is a place to lose a candidate.

I wanted to see how far I could get without ever leaving Claude. Turns out: the whole way. A careers page built and published, applications captured, resumes screened and ranked, interview invites drafted and scheduled — all in a single conversation. Claude drives Sitelas through its MCP connector, and reaches into your Google connectors in the same breath.

Here's exactly how it works.

What an MCP connector actually is (30-second version)

Claude can connect to outside tools through something called MCP connectors. Once you add one, Claude can do things in that tool on your behalf — not just talk about it.

You probably use a few already: the Google Drive, Gmail, and Calendar connectors let Claude read your files, draft emails, and schedule events. Sitelas has one too. Add it, and Claude can design websites, publish them, and read your form submissions — all from chat. That's what turns this from "Claude gives me hiring advice" into "Claude runs my hiring pipeline."

Step 1: Connect Sitelas to Claude

This is the only setup, and it takes about a minute:

Open Sitelas in Claude's connector directory and choose Add — one click.
On Claude Code or Claude Desktop, which read a config file instead, use this URL: https://sitelas.com/api/mcp
Sign in to Sitelas when prompted — that's it. Start chatting.

While you're in there, switch on the Gmail and Google Calendar connectors too — we'll use both later. From here, everything happens by just asking.

Step 2: Ask Claude to design and publish the careers page

You describe the page in plain language:

"Using Sitelas, build and publish a careers page for my startup, Northwind. We're hiring a founding backend engineer. Modern, technical, confident tone. Include an application form with name, email, resume upload, GitHub link, years of experience, and a 'project you're proud of' question."

Claude picks a fitting design, customizes it to the brief, builds the form with exactly those fields, and publishes it live — then hands back the URL. No drag-and-drop, no template wrestling, no separate "now go publish" step. Want changes? "Make the hero darker." "Add a second role for a designer." You say it; Claude edits and republishes.

One message in, you have a real, branded careers page on the web.

Screenshot The published careers page, side by side with the Claude message that returned its URL.

Step 3: The applications collect themselves

There is nothing to wire up. Every application submitted through the form lands in your Sitelas inbox automatically — timestamp, source, every field, and the resume stored as a secure download link.

Ask for it whenever you want:

"Read the applications that came in for the backend engineer role."

Claude reads them straight from the inbox. If you also want each one as a spreadsheet row, add a webhook to the form and point it at Zapier or Make, then on to Google Sheets — the inbox stays the source of truth either way.

Step 4: Let the applications roll in — then ask Claude to screen them

Post the link wherever you'd normally say "email us your resume." As applications arrive, you don't open a single PDF. You ask:

"Read all the applications for the backend engineer role. Open each resume, then score the candidate 1–10 on: production Go/Rust experience, has shipped at scale, startup background, and the quality of their 'project you're proud of' answer. Give me a ranked table with a one-line reason per score, and flag your top 5."

Claude reads the submissions, opens each linked resume from the inbox, and returns a ranked shortlist with reasoning — an evening of resume-reading compressed into the time it takes to refill your coffee. Then you interrogate it like a hiring partner:

"Compare #2 and #4 on distributed systems."
"Who am I underrating because their resume is plain but their project answer is excellent?"

Screenshot Claude's ranked candidate table, exactly as it came back in the chat.

Step 5: Bring in your other connectors to close the loop

This is where one connected conversation beats five tabs. Gmail and Calendar are already on, so you keep going in the same chat:

"Draft warm interview-invite emails to my top 5 candidates, and suggest three interview slots next week from my calendar."

Claude drafts the emails through your Gmail connector and proposes slots through your Calendar connector. You review, approve, and you've gone from "job is live" to "interviews booked" without ever leaving the window.

The connectors compose: Sitelas captures the candidates and stores their resumes, Gmail sends the outreach, Calendar books the time. Claude orchestrates all three.

The whole pipeline, in one window

You:"Build & publish a careers page for a backend engineer role."

Claude → (Sitelas) designs + publishes it, returns the URL.

…applications come in, collected in your Sitelas inbox…

You:"Read the applications, open each resume, score and rank them."

Claude → (Sitelas) returns a ranked shortlist with reasons.

You:"Draft invites to my top 5 and find interview slots next week."

Claude → (Gmail + Calendar) drafts emails, proposes times.

Four messages. One window. A careers page, a live applicant database, AI screening, and scheduled interviews.

What makes this different

It's not that any single piece is new — it's that there are no handoffs. Normally the website lives in one tool, the applications in another, the screening in your head, the emails in a third tab, the calendar in a fourth. Every gap is friction, and a chance to drop a candidate.

Routing it all through Claude's connectors collapses that into one conversation where the context never resets. Claude already knows who your top 5 are when it drafts the invites — because it's the same chat that scored them.

	The usual patchwork (form tool + sheet + inbox)	Claude + Sitelas connector	A full ATS
Tabs / tools to juggle	4–5	1 (Claude)	1, after days of setup
Build + publish careers page	Separate tool	In chat	Yes
Auto-collected applications	Maybe	Yes → your Sitelas inbox	Yes
AI resume screening	No	Yes	Premium tiers
Email + schedule from one place	No	Yes (Gmail + Calendar)	Partially

The honest caveat

This is a lightweight, conversational pipeline — not Workday. No formal interview-stage board, no compliance reporting, no fifty-reqs-a-year scale. If you're a large org, you'll want a dedicated ATS — and that's fine. Outgrowing this means you're winning.

But for hiring your first 1–10 people — where the real pain is just having somewhere to apply, and then reading the pile — this gives you the whole loop, careers page through scheduled interviews, without leaving a chat window.

Try it

Add the Sitelas connector in Claude (plus Gmail and Calendar).
Ask Claude to build and publish your careers page.
When applications land, ask Claude to read the resumes and rank candidates.
Ask it to draft invites and find interview times.

The job that used to span five tools and a long evening now fits in one conversation.

Set up an account at sitelas.com, connect it to Claude, and let it run the whole pipeline for you.

Run Your Whole Site From Inside Claude.ai

Usman Haider — Mon, 15 Jun 2026 11:22:34 +0000

Most website tools split into two worlds: a builder for setup, a dashboard for operations. Sitelas collapses both into a Claude.ai chat. Here's what that actually looks like.

What ships in the connector

Sitelas exposes its whole feature set to Claude.ai as MCP tools, over OAuth 2.1. Once installed, every feature in the product becomes a Claude verb — site creation, content editing, brand changes, scheduled publishing, form submissions, contact records, analytics, and custom domains. Site creation and editing run on Claude's own tokens via your claude.ai subscription; Sitelas charges zero AI credits on this path.

Installation (one minute)

Add Sitelas from Claude's connector directory — one click. Sign in when prompted.
On Claude Code or Claude Desktop, which read a config file instead, use https://sitelas.com/api/mcp.
Sign in to Sitelas when prompted. PKCE-protected OAuth 2.1 — 1-hour access tokens, 30-day refresh tokens that rotate on every use.

Day 0: Site creation

"Build a bakery site for Midnight Oven, Brooklyn — sourdough plus coffee, warm palette, contact-only."

Claude calls select_template_for_brief with structured arguments (audience, register, conversion goal). The tool returns the top three scored archetypes. Claude picks one, clones it via create_site_from_template, then runs bulk passes — patch_nodes for copy, replace_images_from_search for hero shots. Live at midnight-oven.sitelas.com in about a minute.

Day 3: Submissions and contacts

"Anyone reach out this week?"

Claude calls list_submissions — three messages. Sarah asks about gluten-free; Mike wants catering. "Draft a reply to Mike about Saturday catering." Claude calls draft_reply_to_submission; the draft lands in your dashboard inbox ready to send.

Day 5: Analytics

"How's traffic been?"

Claude calls get_analytics(range_days: 7) and top_pages. You get pageviews, unique sessions, top paths, top referrers, and a daily timeseries — in chat. No dashboard tab needed.

Day 7: Scheduled publishing

"Publish a 'Closed Thursday' banner next Wednesday at 9am."

Claude calls schedule_publish with a banner-bar patch and a future run_at. A Vercel cron flips the live page over at the scheduled time.

Day 21: Cloning a layout

"Clone the layout of ra.co and adapt it for my warehouse-party series."

Claude calls capture_url — a Fly.io Playwright service returns a full-page screenshot, simplified DOM, and detected brand tokens. Claude's vision reads the screenshot, picks the closest events-category archetype, and composes a replica in-session.

What's intentionally not in the connector

Stripe Connect (we don't touch the money), native commerce or bookings (use stripe-payment-link and calendly-embed instead), broadcast email sending (use Mailchimp / ConvertKit / Beehiiv directly). Anything Claude already has a native connector for — Gmail, Drive, Calendar, Microsoft 365 — Sitelas leaves alone; it shows up as a verb-rich endpoint those existing connectors can call into.

One subscription, two surfaces

You can also build and edit from yourname.sitelas.com/edit with the in-editor AI chat (Gemini 2.5 Pro). It calls the same MCP tools Claude does — same fixture, same authoring layer. Same site, just a different chat panel.