The bet

I'm no longer defaulting to WordPress or Webflow for marketing sites.

The better model is straightforward: a developer builds a proper site once, then the business maintains it through AI tools connected to GitHub — ChatGPT Codex, Anthropic Claude, or similar.

Below is the stack, in order, and a real photo swap I ran end to end.

Why the old options fall short

WordPress is flexible, but you're permanently managing plugins, themes, updates, and security.

Webflow and page builders work well for design teams who live in them. They get awkward the moment a non-designer only needs to swap one photo or fix a line of copy.

Custom sites under the old process look great at launch — then every small change becomes a ticket, a wait, and another billable round.

There's a fourth path: build the site correctly in code, hand it off, and let AI handle day-to-day maintenance against the same repository the developer shipped.

How the stack works (top to bottom)

Keep the stack simple on purpose. Simple stacks are reliable — and the sequence matters.

Flow diagram: developer builds first, handoff to management, edits via ChatGPT Codex or Anthropic Claude, changes go to GitHub, then preview link and Vercel deploy the live site
Read top to bottom: developer builds → handoff → AI maintenance → GitHub → preview or production on Vercel.
  1. Developer builds first. Structure, design system, SEO foundations, forms, and performance — in real code — then pushed to GitHub.
  2. Handoff to the management team. Marketing or operations owns routine updates after launch.
  3. They edit through AI. ChatGPT Codex or Anthropic Claude connects to that GitHub repo. Requests stay in plain English: swap a photo, update hours, fix a headline.
  4. Changes land on GitHub. The repo remains the source of truth, with full history and a clean path to revert.
  5. Preview, then Vercel. Review a preview before anything goes public. When approved, Vercel deploys production. A domain (GoDaddy or similar) points at Vercel; contact forms go through Resend or SendGrid.

Need user accounts or other app-like features later? Add a backend then. Most brochure and lead-gen sites do not need that complexity on day one.

A real session: swapping a photo with Codex

I ran this on a live project — Birch Island Cottage — with Codex connected to the GitHub repository. No WordPress admin. No Webflow designer seat. Just conversation, the source files, and a preview.

Codex sits beside regular ChatGPT, with a different job: build, debug, and ship code.

ChatGPT app menu showing Codex selected with the subtitle Build, debug, and ship
Codex is built for shipping code changes, not only answering questions.

1. It found the project on GitHub

I asked whether it could change a photo on the site. Codex asked for the repository. I gave the project name — slightly wrong, even — and within seconds it resolved tysongreenan/birch-island-cottage.

Codex message confirming it found the GitHub repository
Connected to the actual source files that deploy to production — not guessing from a screenshot of the live page.

2. I pointed at the exact photo

I asked Codex to show me the site, then annotated the welcome-section image with a simple note: change this photo.

Cottage interior photo highlighted with a visual annotation
Pointing at the element is clearer than describing "the photo near the welcome text" over email.

3. I attached the replacement image in chat

I dropped the new file into the conversation. No FTP. No media library. No waiting on a shared folder "when someone has time."

New photo attached in the Codex chat
Attach the asset in chat; the agent updates the file in the repository.

4. Preview first — production stays untouched

I told it not to push to main and that I wanted a preview. Codex opened a local preview with the new image in the welcome section and left production alone.

Codex chat on the left and live website preview on the right
Chat on the left, live preview on the right — you review the change before the public does.

I didn't like the result, so I asked it to revert. The preview branch was removed. Main was unchanged.

Chat confirming preview was discarded and main remains unchanged
Preview, reject, revert. Production never took the hit — safer than editing live in a page builder and hoping undo works.

Why this model is stronger

Maintenance stops taxing the developer relationship. Photo swaps, hours, headlines, and seasonal copy can move through marketing in chat. Developers stay on architecture, larger features, and quality — not endless micro-tickets.

The goal is not "clients never need developers." It is "clients should not need a developer to change a photo."

SEO improves when the site is clean code. AI can tighten titles, headings, alt text, internal links, and schema against real files — not inside a theme that wraps every paragraph in three layers of markup. I have seen substantial ranking gains from that discipline alone.

Performance stays high. A focused site on Vercel avoids the admin and plugin weight that slows traditional CMS stacks.

The foundation still requires craft. Brand, layout, accessibility, forms, analytics, and the deploy pipeline are still a developer's job at the start. AI maintenance works because that foundation is solid — not instead of it. The developer builds the house; AI is the lightbulb phase.

What belongs in AI maintenance

A strong fit: swapping photos, updating contact details and hours, refining copy, fixing obvious SEO gaps, small layout tweaks, and seasonal content.

Still plan carefully with a developer: payments, user accounts, major information architecture, compliance-sensitive work, and full redesigns.

Codex and Claude can also handle larger work — even new pages — but that is a separate conversation. This post is about the everyday loop: request → edit → preview → ship or revert.

What changes for clients and developers

Before: screenshots over email, interpretation gaps, delayed deploys, then another round of "one more thing."

After: the person closest to the content describes the change in English, previews it, and only then ships — or reverts without drama.

The site stops feeling locked. Developers stop living in maintenance mode. Trust goes up on both sides.

The case, simply

I am betting the winning marketing website of the next few years is custom enough to be fast and searchable, versioned in GitHub, hosted on something like Vercel, and maintainable by non-developers through AI coding agents.

Not another locked-in page builder. Not a retainer for every hero image.

If "can you change this photo?" is still a full project, it is time to rethink the stack.