“Put it back.”
Rollback repoints the live site at the previous release. It takes milliseconds and works even if the current draft is a mess.
How it works
From a sentence to a live page.
There are four steps. You do one of them once, and the fourth one forever. Here is what actually happens in between — including the parts that stop a confident AI from breaking a site people depend on.
The loop
Draft on top. Live underneath. One move between them.
Everything your AI does happens in a draft. The live site is a stack of numbered, read-only releases and a pointer that says which one visitors get.
Step by step
What you actually do.
Pick your domain
Tell us the name you want and we register it for you, in your name. If you already own one, keep it where it is — you'll add two records, or hand us the nameservers and we'll do all of it. Either way the domain stays yours.
We provision the site
Server space, build resources, HTTPS and a starter page go up before you touch anything. From the first minute there is a real address with a valid certificate that returns a real page — not a “coming soon” parking placeholder.
Connect the builder to your AI
You get a name and a URL. Paste them into Claude, ChatGPT, Cursor or any other client that speaks MCP. Your assistant now has a set of tools pointed at your site, and only at your site — the access token is scoped to it.
Describe what you want
“A home page, an about page, and a contact form. We're a bakery in Parkhurst, open six till two, closed Mondays.” Then keep going: change the hours, add the specials, swap the photo, write a post. It is the same conversation every time.
The bit everyone gets stuck on
DNS, diagnosed rather than reported.
Almost nobody fails at building the site. They fail at pointing the domain, and the reason is nearly always the same: they bought the domain at one company, but the nameservers point somewhere else entirely — a Shopify trial from three years ago, an old agency's Cloudflare account. So they add the record correctly, in the wrong place, and wait forever.
Our checker doesn't just say “waiting for DNS”. It asks the servers that are actually authoritative for your domain and tells you what is really going on.
risecrumb.co.za
authoritative ns cloudflare
1.1.1.1 ✓ 203.0.113.24
8.8.8.8 ✓ 203.0.113.24
9.9.9.9 … propagating (ttl 300)
! your DNS is managed at Cloudflare,
not GoDaddy — add the record there
The easy path
If you'd rather not touch any of it: change your nameservers to ours once, and every record after that — the site, the email, the verification — gets created for you. One instruction instead of four.
When it goes wrong
Because sometimes it will.
The model will occasionally do something you didn't ask for. The design assumes that, rather than hoping otherwise.
“What changed on Tuesday?”
Every edit, build, check and publish is recorded against the request that caused it. You can read the site's history as a plain list, in order.
“Back to Friday morning.”
Restore to a point in time rather than a release number, and carry on from there. Nothing is destroyed — the restore is itself a new release.
A specific failure we designed against
A coding assistant that loses its place in a file will often rewrite the whole thing from what it believes the page contains — faithfully reproducing everything visible and silently dropping the analytics tag and the booking widget you pasted in months ago. Our publish step compares the candidate against what is live and refuses when tags disappear that you didn't ask to remove. You can also pin a snippet so any rewrite that loses it fails outright.
Honest limits
What this builds, and what it doesn't.
Your site is compiled to static files. That is what makes it fast, cheap and almost impossible to break into — and it is also a real constraint. Better you know now.
Fits well
- Brochure and marketing sites, any number of pages
- Menus, price lists, service pages, galleries, team pages
- Blogs, news, case studies, documentation
- Contact and enquiry forms, with submissions emailed to you
- Landing pages and campaign microsites
- Catalogues that mirror a store you already run elsewhere
Doesn't fit
- Customer accounts and logins on your own site
- Checkout and payment processing hosted by us
- A database your site reads and writes at request time
- Anything that needs your own server-side code running live
When you outgrow it — and if things go well you will — we say so and help you move, rather than quietly answering “unsupported”. Bookings, payments and storefronts can be embedded from services that do them properly.
Ready to try it on a real domain?
Tell us what you're building. We'll tell you honestly whether it fits.