DEV Community: Linc

Replacing Contact Form 7 and Gravity Forms when I move a client site from WordPress to Astro

Linc — Tue, 03 Nov 2026 00:09:16 +0000

Every WordPress site I migrate to Astro has the same hidden landmine. It's not the theme, it's not the blog posts. It's the forms.

Contact Form 7, Gravity Forms, WPForms, sometimes all three on one site because three different devs touched it over the years. The client doesn't think about any of it. They just know leads show up in their inbox. If that stops the day you launch, you hear about it in about two weeks when they ask why the phone went quiet.

So here's the checklist I run now before I touch DNS.

1. Find every form, not just the contact page

I don't trust the menu. I search the database export for shortcodes and blocks:

grep -oE '\[(contact-form-7|gravityform|wpforms)[^]]*\]' wp-export.xml | sort | uniq -c
grep -o 'wp:gravityforms/form[^>]*' wp-export.xml | sort | uniq -c

That usually turns up the forgotten ones. A quote form on a landing page from 2021. A newsletter box in the footer widget. A "request a callback" popup nobody remembers adding.

I put each one in a little table: page URL, form name, fields, where it sends, and anything weird it does.

2. Figure out what each form actually does

This is the part people skip. A form plugin is rarely "just email me". Look for:

Multiple recipients or routing (sales vs support based on a dropdown)
Integrations like Mailchimp, a CRM, Zapier, Google Sheets
File uploads (CVs on a careers page, photos for a quote)
Conditional fields
Auto replies to the person who submitted
Thank you page redirects that the client's Google Ads conversion tracking depends on

That last one has bitten me. The old site sent people to /thank-you/ and an ads conversion fired there. New site showed an inline "thanks!" message and conversions dropped to zero. Client thought the ads broke.

3. Rebuild as plain HTML

On the Astro side I keep forms boring. A normal <form> with real name attributes, no JS required to submit. I host the client sites on novence.ai so I create the form there (CLI, API or I just ask the coding agent to do it over MCP) and point the action at it:

<form action="/__forms/FORM_ID" method="POST">
  <label>Name <input name="name" required></label>
  <label>Email <input type="email" name="email" required></label>
  <label>Message <textarea name="message" required></textarea></label>
  <!-- honeypot, keep it hidden -->
  <input type="text" name="_gotcha" tabindex="-1" autocomplete="off" style="display:none">
  <button type="submit">Send</button>
</form>

Submissions get stored and emailed, which covers maybe 80% of what the old plugins were doing. The honeypot plus rate limiting has been enough spam control for the small business sites I do. If you're somewhere else, Formspree or Web3Forms work the same way, the pattern is identical.

For the other 20%:

File uploads: I don't fake these. Most form backends for static sites won't take files and honestly I'd rather not store CVs anyway. I link to a proper upload tool or ask them to email attachments.
CRM / Mailchimp: their own embed form, or a webhook into Zapier. Don't try to rebuild the integration in client side JS.
Routing by dropdown: two separate forms is often simpler than one smart one. Ask the client if anyone actually uses the dropdown. Half the time nobody does.

4. Keep the thank you URL

If the old site redirected to a thank you page, I build the same page at the same path. Zero clever-ness. Then tracking keeps working and I don't have to explain to an ads person why the numbers moved.

If the old thank you URL had a weird slug I still keep it, and if I really have to change it, it goes in /_redirects with everything else.

5. Test from the preview URL before launch

Before the domain moves I submit every form on the preview deploy with a real email address:

did it arrive, and how fast
can the client see the visitor email clearly so they can reply fast
does the honeypot actually stay hidden on mobile
does the thank you page load

I also ask the coding agent to run the checks (lighthouse, axe, broken links) so labels on inputs don't get missed. Accessibility on forms is where AI generated markup is most sloppy in my experiance, usually placeholder text pretending to be a label.

6. Tell the client where leads go now

One short email. "Your enquiries now come from this address, add it to your contacts so it doesn't land in spam." That one sentance has saved me more support tickets than anything else on this list.

And I leave the old WordPress install up for a week after launch with its forms still pointing at the old inbox, just in case some cached page or old ad sends someone there.

Forms are boring, which is exactly why they break quietly. Do the audit first and the actual rebuild takes like twenty minutes per site.

What weird form setups have you found on old WP sites? I once found one that emailed a guy who left the company in 2019.

The DNS checklist I run so a WordPress to Astro move never breaks client email

Linc — Sun, 01 Nov 2026 00:02:42 +0000

The scariest part of moving a client off WordPress isnt the rebuild. Its cutover day, when you touch their DNS and their email quietly stops working at 4pm on a Friday.

I've done enough of these WordPress to Astro moves now that I run the same checklist every time. Nothing fancy. It just stops me from being the guy who broke the bakery's inbox.

Why email breaks during a website move

Most small business clients have their domain at some registrar, the website at a cheap WordPress host, and email at Google Workspace or Microsoft 365. Three different companies, one DNS zone.

The website only needs two records. Email needs a handful of others. The problem is that a lot of hosts and registrars have a "connect your domain" button that helpfully wipes every record it doesnt recognise. That's how MX records disappear.

So the whole job is: change the website records, touch nothing else.

Step 1: screenshot the zone before you touch it

Before anything, I export or screenshot the full DNS zone. Every record. I drop it in the client folder with the date.

Then I sort it into two piles:

Website: the apex (example.com) and www. Usually an A record pointing at the old WordPress host and a CNAME or A on www.
Email and everything else: MX, the SPF TXT, DKIM (TXT or CNAME), DMARC TXT, plus random verification TXT records for Google, Facebook, whatever.

Pile two does not get touched. Ever. If I'm not sure what a record does, it goes in pile two.

Step 2: get the new site live on a preview URL first

The Astro build gets deployed and checked long before DNS day. I deploy with the CLI:

npm run build
npx novence deploy ./dist --json

That gives me a *.novence.ai preview URL that isnt indexed, so I can send it to the client, run through the redirects and forms, and not worry about Google picking up a half finished site.

Cutover day should be boring. If you're still fixing layout bugs on cutover day you're doing it in the wrong order.

Step 3: attach the domain and let the host tell you the records

I dont type DNS records from memory. I attach the domain and copy exactly what comes back:

npx novence domains add www.clientsite.com.au

For Novence that prints a www CNAME to fallback.novence.ai, and then you do one thing for the apex: either an ALIAS on @ to the same target, or a URL redirect from the apex to https://www.clientsite.com.au/.

Small but important: the apex cant be a plain CNAME if the domain also has MX records. That's a DNS rule, not a host thing. If the registrar doesnt support ALIAS or ANAME, use the forward to www and move on.

Step 4: edit two records at the registrar, by hand

At the registrar I:

Change the www record to the new CNAME.
Change or replace the apex A record with the ALIAS or the forward.
Delete the old WordPress host's A records for those two names only.

That's it. I dont click any wizard, I dont "import" a template, and I dont let the new host manage the whole zone unless the client actually wants that.

Then I compare the zone against my screenshot from step 1. Every MX, SPF, DKIM and DMARC record should be byte for byte the same.

Step 5: test mail both ways

Once DNS resolves and HTTPS is issued, I test email in two directions:

Send from my personal Gmail to hello@clientsite.com.au. Incoming works, so MX is fine.
Ask the client to reply from that address back to me. Outgoing lands in my inbox and not spam, so SPF and DKIM are fine.

Takes two minutes. I do it while still on the call with them so they see it working.

If incoming fails, the website can stay on the new host. Go back to Google Admin or the Microsoft 365 setup page, copy the MX records they publish, and put back whatever went missing. Dont try to roll back the whole site in a panic.

Step 6: check the domain status, then the boring stuff

npx novence domains status

I wait until it stops asking for more DNS changes, then:

Load the apex and www, with and without https, and make sure they all land on one canonical URL.
Spot check a few old WordPress URLs to confirm the 301s from /_redirects fire on the real domain, not just the preview.
Submit the sitemap in Search Console for the real domain.

Step 7: leave the old host running for a week

I dont cancel the old WordPress hosting on cutover day. DNS caches, someone has a bookmark to /wp-admin, the client remembers a PDF that was only ever on the old server. A week of overlap costs a few dollars and has saved me more than once.

After the week I grab a final backup of the old site and the database, then cancel.

The short version

Screenshot the zone.
Website records are www and the apex. Everything else is someone elses problem and you leave it alone.
Get the host to print the records, dont guess them.
No "connect domain" wizards.
Test mail in and out before you hang up.

The rebuild is where you show off. Cutover is where you keep the client. If you're moving a pile of WordPress sites over, having all of them on one host with the same domain flow makes this checklist really repetable, which is the whole point.

The redirect map I build before migrating any WordPress site to Astro

Linc — Sat, 31 Oct 2026 00:06:45 +0000

Every WordPress site I've migrated to Astro had the same hidden landmine. Not the theme, not the plugins. The URLs.

WordPress leaves a mess of URL shapes behind after a few years. /?p=123, /2019/04/some-post/, /category/news/, /wp-content/uploads/2020/05/menu.pdf, tag pages nobody remembers making. Google has all of them indexed. The client has some of them printed on flyers. If you rebuild the site in Astro and just ship it, a chunk of that turns into 404s overnight and the client calls you three weeks later asking why the phone stopped ringing.

So now I don't touch a single Astro component until I've built the redirect map. Here's how I do it.

1. Pull every URL the old site actually has

I grab three lists and merge them:

The sitemap (/sitemap_index.xml or /wp-sitemap.xml, depends on the SEO plugin)
A crawl of the live site (Screaming Frog free tier is fine under 500 URLs, or let your coding agent write a quick crawler)
The Search Console "Pages" export, because that shows what Google thinks exists, wich is not always what the sitemap says

The Search Console list is the one that catches the weird stuff. Old landing pages from a 2021 ad campaign, a /specials page someone deleted but still gets hits. Those are the ones that hurt when they break.

2. Decide the new URL for each one

I dump the merged list into a CSV with two columns, old and new, and go through it. Most of it is boring:

/2019/04/some-post/ goes to /blog/some-post
/category/* mostly goes to /blog
Attachment pages and ?p= links go to whatever post they belonged to
PDFs in wp-content/uploads I copy across and keep at a sane path

This is a great job to hand to Claude Code or Cursor. Give it the CSV and the new Astro src/pages tree and ask it to propose the new column. It gets maybe 90% right. I review the rest by hand because the agent has no idea the client calls the "Services" page "What we do" on their business cards.

3. Write it as a redirects file

I host client sites on novence.ai, so the map just becomes a /_redirects file in public/:

/2019/04/:slug/   /blog/:slug   301
/category/*       /blog         301
/specials         /offers       301
/wp-content/uploads/2020/05/menu.pdf   /files/menu.pdf   301

Splats and placeholders cover most of the date-based post URLs in one line, so a site with 300 old posts usually ends up with a redirects file of maybe 20 to 40 lines. Keep it in the repo, it's part of the site now.

4. Test it before DNS moves

This is the step people skip. Before I point the domain, I deploy to the preview URL (npx novence deploy ./dist) and run every old URL from the CSV against it with a tiny script:

for (const { old, expected } of rows) {
  const res = await fetch(previewBase + old, { redirect: "manual" });
  const loc = res.headers.get("location");
  if (res.status !== 301 || !loc?.endsWith(expected)) console.log("FAIL", old, res.status, loc);
}

Anything that prints FAIL gets fixed before the client ever sees it. I make the coding agent run this as a check before every deploy for the first month, so if someone renames a page later the old link doesn't quietly die.

5. Watch it for a few weeks after launch

After the domain switches I keep an eye on two things: Search Console's 404 report, and the analytics for top landing pages. If a page that used to get traffic drops to zero, there's usually a redirect missing. Add a line, redeploy, done.

Why bother

Honestly the redirect map is the difference between "the new site is nice" and "the new site killed our Google rankings". The design gets all the attention but this is the boring hour of work that actually protects the client's business. And once you've done it on two or three migrations, the CSV plus agent plus test script becomes a repeatable thing you can do on every WordPress site you move.

If you're doing agency migrations, how are you handling the old URLs? Curious if anyone has a better way to catch the stuff that isn't in the sitemap.

How I let clients edit their Astro site without giving them WordPress back

Linc — Thu, 29 Oct 2026 00:05:40 +0000

Every agency that moves clients off WordPress hits the same wall. Not speed, not hosting, not SEO. It's the client asking "ok but how do I change my opening hours now?"

On WordPress the answer was "log into wp-admin". Which also meant they could break the theme, install 4 plugins and ring you on a Friday. On a static Astro site the honest answer is usually "send me an email and I'll do it". That works for a while, then it turns into a stream of tiny unpaid jobs.

Here is how I handle it now after migrating a bunch of small business sites. Short version: don't give them a CMS. Give them the 3 or 4 things they actually change.

1. Figure out what they really edit

I went back through a year of client emails for about a dozen sites. Almost every request fell into a few buckets:

opening hours and holiday closures
a menu, price list or services list
team members (someone leaves, someone joins)
one "announcement" line at the top of the page

Nobody was asking to redesign the homepage. Nobody wanted to write blog posts (the ones who said they would, never did). So the whole "we need a CMS" conversation is mostly about 3 or 4 small lists.

2. Pull that content out into JSON

For each of those buckets I keep one file in public/data/:

public/
  data/
    hours.json
    menu.json
    team.json

hours.json is boring on purpose:

{
  "monday": "7am - 3pm",
  "tuesday": "7am - 3pm",
  "saturday": "8am - 1pm",
  "sunday": "Closed",
  "note": "Closed 25-26 Dec"
}

Everything else on the site stays as normal Astro components and markdown. The design, layout and copy are mine. The lists are theirs.

3. Fetch it at runtime, not build time

This is the bit that tripped me up first. In Astro it's tempting to import hours from '../data/hours.json' and render it at build time. That's fine until the client edits the file live, because the built HTML still has the old hours baked in.

So for client editable blocks I render a small fallback in the HTML and then fetch the JSON on the page:

<ul data-hours>
  <li>See our hours below</li>
</ul>
<script>
  fetch('/data/hours.json')
    .then((r) => r.json())
    .then((h) => {
      const el = document.querySelector('[data-hours]');
      el.innerHTML = ['monday','tuesday','saturday','sunday']
        .map((d) => `<li>${d}: ${h[d]}</li>`)
        .join('') + (h.note ? `<li>${h.note}</li>` : '');
    });
</script>

Tiny, no framework island needed, and the page still loads fast. If you care about the hours being in the initial HTML for SEO, render the build time version as the fallback and let the fetch overwrite it. Best of both.

4. Give the client a form, not a file

The client is never going to open a JSON file. And I'm not giving them a git login.

I host these sites on novence.ai and the paid plans have an owner edit option: you set which email addresses can edit and which data files they can touch, and the client just bookmarks theirsite.com/edit. They type their email, get a one time code, and get a generated form for those fields. No password to forget, no admin panel, no plugin updates. The /edit page is noindex so it doesnt show up in Google.

For the restaurant clients this alone killed most of the "can you update the menu" emails.

If you're on another host the same idea works with any headless form + a small serverless function that writes the JSON. It's just more pieces to babysit.

5. Don't let your next deploy wipe their edits

This is the gotcha that will bite you once. The client edits menu.json live. A week later you push a design tweak from your repo, which still has the old menu.json. Congrats, you just reverted their menu.

What I do now:

before any deploy, pull the live /data/*.json files back into the repo
my coding agent does this as a step in the deploy script so I can't forget
the JSON is committed, so I also get a history of what the client changed and when

Something like:

for f in hours menu team; do
  curl -s "https://clientsite.com/data/$f.json" -o "public/data/$f.json"
done
git commit -am "sync client data" || true
npm run build && npx novence deploy ./dist

6. What this doesn't do

Be upfront with clients about the edges:

it's not a page builder. New pages or layout changes are still a job for you (and billable)
don't put anything private in /data, those files are public URLs
bookings, payments and shop stuff go in a proper widget (Cal.com, Stripe payment links etc), not JSON

Most small business owners are actually relieved by this. A form with 6 fields is less scary than wp-admin ever was.

The result

Fewer tiny support jobs, clients who feel in control of the stuff they care about, and no WordPress admin to keep patched. When I pitch a WordPress to Astro move now, "you can still edit your hours and menu yourself" is usually the line that gets the yes.

If you've got a different setup for client edits on static sites I'd genuinly like to hear it in the comments.

How I run a one person web agency with a coding agent (find, build, check, ship)

Linc — Tue, 27 Oct 2026 00:07:25 +0000

I've been running a one person web design shop for a while now. The thing that changed it most this year wasn't a new framework, it was handing the boring 80% of every build to a coding agent and keeping the parts that actually need a human.

Here's the exact loop I use to go from "local business with a bad site" to "live site the owner can edit", usually inside a day.

1. Finding the client

I don't cold pitch with a deck anymore. I pick a niche (plumbers, dentists, cafes in one suburb), look at their current sites on my phone, and note the obvious stuff: slow load, broken contact form, no mobile menu, hours that are out of date.

Then I get the agent to build a quick mockup of their homepage using their real copy and photos. Sending someone a link to their own site, but better, gets way more replies than "hey I do websites".

Rule I learned the hard way: never send the mockup on a URL with my agency name all over it. Use a neutral preview link and keep it to one page.

2. The build prompt

I use Claude Code mostly, sometimes Cursor or Codex. The prompt that matters is the first one. Mine looks roughly like this:

Build an Astro site for <business>. Static output only.
Pages: home, services, about, contact.
Put all editable content (hours, phone, services list, prices)
in /data/site.json and read it at build time. No CMS.
Contact form posts as a plain HTML form, no JS required.
Run a build and fix every error before you stop.

Two things in there save me hours later:

All the stuff the client will want to change lives in one JSON file. Opening hours, phone number, the services list. Nobody edits the hero copy, they edit the hours every public holiday.
"Run a build and fix every error before you stop." Without this the agent cheerfully hands you something that dosen't compile.

3. Checks before anything goes live

Agents are confident. That's not the same as correct. Before a deploy I have the agent run a short checklist:

broken internal links
images missing alt text or over ~300kb
the form actually has name attributes on every field
Lighthouse mobile score on the homepage

If anything fails it fixes and reruns. I only look at the output once its green. This step alone killed most of the "hey the form doesn't work" emails I used to get a week after launch.

4. Deploying without me in the loop

This was the bit that used to need me. Now the agent deploys itself. I host client sites on novence.ai because it's built for exactly this, the agent can push a static folder from the CLI:

npm run build
npx novence deploy ./dist

or if I'm working inside an MCP capable client, it just calls the deploy tool directly. Either way I get a preview URL back, check it on my phone, and point the clients domain at it when they approve.

The nice side effect: every client lives in one account. No more 14 different hosting logins and a spreadsheet of renewal dates.

5. Letting the client edit (without a CMS)

Remember that /data/site.json? The client gets a simple edit page for it with a one time email code, no password, no admin dashboard to break. They change their Christmas hours, the site updates, and I never hear about it.

This is honestly what lets me charge a monthly fee without feeling guilty. They're paying for "it just works and I can fix the small stuff myself", not for a login screen.

What I'd tell someone starting out

Pick a niche and a suburb. Generic agencies are invisible.
Lead with a real mockup of their site, not a portfolio.
Make the agent run checks, every single time.
Keep editable content in data files, not a CMS.
Put every client on one host so maintenance is one job, not twenty.

The agent does the typing. You still do the selling, the taste and the "does this actually make sense for a plumber" calls. That split is the whole business.

If you're doing something similar I'd genuinely like to hear what your loop looks like, especially how you handle client approvals.

Why we stopped using WordPress for small business client sites (and moved to Astro)

Linc — Sun, 25 Oct 2026 23:12:14 +0000

For years the default for any local business site was spinning up another WordPress install, throwing 10 plugins at it, and charging a monthly retainer just to keep Elementor and Contact Form 7 from breaking.

Now that Claude Code and Cursor can build a clean Astro site in a couple hours, WordPress feels like way too much overhead for a 5 to 20 page business site.

Here is the workflow we switched to for migrating client sites off WordPress:

1. Map the old URLs first

The main way agencies mess up a WordPress to Astro migration is breaking old URLs that already rank on Google. Before building anything, have your agent pull their sitemap and generate a /_redirects file so every old /wp-content/ link or weird trailing slash 301s cleanly.

2. Skip the headless CMS for small clients

Most local business owners log into wp-admin twice a year to change their opening hours or update a price list. Wiring up Sanity or Strapi for that is overkill.

Instead, we just drop a /data/services.json or /data/hours.json file into the static build.

3. Keep all the clients in one spot

Instead of paying WP Engine per site or glueing together separate form and hosting accounts for every client, we deploy the Astro dist/ folder straight to novence.ai (npx novence deploy ./dist).

It keeps all our client projects and contact forms in one place, checks for broken links on deploy, and gives the business owner a simple /edit page on their domain where they can get an email code and update their JSON data themselves without a rebuild.

If you run a small agency or freelance, ditching PHP updates and database backups for plain static Astro files is honestly the best quality of life upgrade you can make.

Let Your Coding Agent Deploy Its Own Websites (Claude Code / Cursor + MCP)

Linc — Thu, 20 Aug 2026 11:11:33 +0000

You've probably had this moment: you ask Claude Code or Cursor to build a landing page, it writes clean HTML, CSS, and a bit of JS, and then... it stops. It hands you a folder.

Now you open a browser. You log into a hosting dashboard. You create a project, connect a repo, wait for a build, and paste a URL back to the client.

The agent did the work. You did the deployment. That's a weird division of labour, and it's the part that hasn't been automated yet, not because deploying is hard, but because almost every host assumes a human with a browser session, an OAuth token, and a credit card on file.

This post walks through closing that gap: giving your agent a hosting surface it can drive end to end. I'll use Novence because it's built for exactly this, but the general shape applies to any host that exposes an MCP server.

Disclosure: I build Novence. I've tried to keep the "here's when this is the wrong tool" section honest, skip to it if you want the caveats first.

What we're building

By the end you'll be able to type this into Claude Code:

Build a 3-page static site for a coffee roaster called Fern & Ash then deploy it and give me the live URL.

And get back a working https://something.novence.ai/ URL. No dashboard, no git push, no build config.

The pieces

Three things make this work:

Self-service account creation over HTTP. One POST gets an API key. There's no signup form the agent has to fill in.
MCP tools for the deploy loop. Create project → get upload URLs → deploy → read check results. Your agent calls these like any other tool.
Quality gates before promotion. Lighthouse, axe, and link checks run on every deploy. Fail them and the deploy never reaches the live URL.

That third one matters more than it sounds. Agents generate broken markup constantly. Images without alt, links to pages they meant to create and didn't, contrast ratios that fail on the accent colour they picked. If the checks return structured issues, the agent can read them and fix them. Without gates, "deployed" and "actually works" drift apart fast.

Step 1: Bootstrap a key.

Give your agent your email address, and tell it to connect to novence.ai, (or copy the prompt from the homepage).

Or you can run your own command:

curl -s -X POST https://api.novence.ai/v1/bootstrap \
  -H 'content-type: application/json' \
  -d '{"email":"you@example.com"}'

Response:

{ "apiKey": "nv_live_…", "emailVerificationRequired": true }

The key works immediately. A one-time code lands in your inbox, verify it to unlock the full free tier and billing:

curl -s -X POST https://api.novence.ai/v1/auth/verify-email \
  -H 'content-type: application/json' \
  -d '{"email":"you@example.com","code":"123456"}'

Lost the key later? Resend the OTP and hit POST /v1/auth/reissue-key.

Step 2: Wire up MCP

The server speaks streamable HTTP at https://api.novence.ai/mcp.

Claude Code:

claude mcp add --transport http novence https://api.novence.ai/mcp \
  --header "Authorization: Bearer nv_…"

Cursor - add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "novence": {
      "url": "https://api.novence.ai/mcp",
      "headers": {
        "Authorization": "Bearer nv_live_…"
      }
    }
  }
}

Restart the client and you should see four tools available: create_project, get_upload_url, deploy, and get_checks_results.

Step 3: Ask for a site

That's genuinely it. Now you can prompt:

Build a 3-page site for a coffee roaster called Fern & Ash. Homepage, services page, and a contact section. Then deploy it to Novence and give me the live URL.

What happens under the hood:

Tool	What it does
`create_project`	Opens a project with a unique suffix, returns a project ID
`get_upload_url`	Returns presigned URLs; agent pushes HTML/CSS/JS, then confirms
`deploy`	Validates `index.html`, snapshots the files, queues the check worker
`get_checks_results`	Returns structured Lighthouse / axe / link issues

Pass the checks and the deploy promotes to https://{suffix}.novence.ai/.

Fail them and you get something the agent can act on:

{
  "status": "failed",
  "issues": [
    { "type": "axe", "rule": "image-alt", "selector": "img.hero", "impact": "critical" },
    { "type": "link", "href": "/about", "status": 404 }
  ]
}

In practice this turns into a nice self-correcting loop: the agent reads the failures, patches the markup, redeploys. You watch. The first deploy of a generated site fails these checks more often than not, which is the point.

Prefer code to prompts?

There's an SDK if you'd rather drive it from a script or a CI step:

import { Novence, bootstrapAccount, verifyEmail } from "@novence/sdk";

const { apiKey } = await bootstrapAccount("you@example.com");
await verifyEmail("you@example.com", process.env.VERIFY_CODE!);

const client = new Novence({ apiKey });
const { project, url } = await client.projects.create({ name: "fern-and-ash" });
await client.files.uploadDir(project.id, "./site");
await client.deployments.create(project.id);

console.log(url); // https://{suffix}.novence.ai/

Same control plane behind REST, GraphQL, MCP, and the SDK - pick whichever fits the context you are calling from.

Custom domains

Preview URLs are fine internally, but clients want their own domain. Point www at Novence with a CNAME, then redirect the apex at your registrar:

Type	Host	Value
CNAME	`www`	`fallback.novence.ai`
URL redirect	`@`	`https://www.example.com/`

The www-first approach keeps SSL simple. Apex CNAMEs are technically non-standard and every host works around them differently; a registrar-level redirect avoids the whole category of problem.

The part nobody automates: paying

Here's the bit I find genuinely interesting about agent-driven infra.

If an agent can create an account and deploy but can't pay, you've still got a human botttleneck, it just moved to the billing page. So there are two paths:

Tell your AI assistant to open up the dashboard (console-kit).

You then get access to the dashboard (Unique - you have to try it.) select 'manage billing' tab.

# Human with a card

curl -s -X POST https://api.novence.ai/v1/billing/checkout \
  -H "authorization: Bearer $KEY" -H 'content-type: application/json' \
  -d '{"plan":"pro"}'
# → Stripe Checkout URL

# Agent, via Machine Payments Protocol
curl -i -X POST https://api.novence.ai/v1/billing/mpp \
  -H "authorization: Bearer $KEY" -H 'content-type: application/json' \
  -d '{"plan":"pro"}'
# → 402, then settle with a Payment credential

Same subscription either way. The MPP path means an agent operating on a budget can provision its own hosting without a human in the loop at all. Whether you want that is a separate question, but the plumbing exists now, and I suspect a lot of infra will grow this shape over the next year.

When this is the wrong tool

Being straight with you, because the comments section will be anyway:

Static only. HTML, CSS, JS. No server-side rendering, no API routes, no edge functions. Marketing sites, landing pages, docs, portfolios. If you need Next.js SSR, this isn't it.
Netlify, Vercel, Cloudflare Pages and GitHub Pages all have generous free tiers, and some have MCP servers now. If you're happy with a git-push workflow and don't mind creating projects by hand, they're excellent and you should use them.
The real differences are that there's no human signup step, no git dependency, and checks gate promotion rather than reporting after the fact. If none of those three are pain points for you, stick with what you've got.

The free tier is one project, 20 deploys a month, and one custom domain, enough to try the loop end to end. Pro is $29/mo for 20 projects and 10 domains, which is the tier that makes sense once you're running client work.

Try it

Fastest possible test - one command, no reading:

point your agent at the machine-readable brief and let it figure the rest out:

Agent brief: https://novence.ai/llms-full.txt
OpenAPI spec: https://novence.ai/openapi.yaml
Docs: novence.ai/docs

If you try it and the deploy loop breaks in an interesting way, I'd rather hear about it than not, drop it in the comments.