Thirty minutes is a real number and a misleading one, and I want to do something unusual for a post with this title: tell you exactly which is which. Thirty minutes is what my pipeline needs to take a landing page from a markdown brief to a deployed, browser-verified scaffold: real layout, real copy structure, working form, live URL. It is not what the page costs. The positioning took days of thinking, the polish took more sessions, and the offer it presents took years to be true. The pipeline compresses the mechanical middle of the work to almost nothing, and doing that repeatably from one CLI is worth building, which is why this post exists.
I ship lead-generation pages on my own platform this way (code-only pages in my Laravel app, six locales, no page builder), so everything below is the working version, including the production incident that taught me the pipeline's most important stage.
Why MCPs Are the Difference Between a Prompt and a Pipeline
Without tools, an AI coding agent writing your landing page is a copywriter locked in a room: it produces files and asserts they work. The Model Context Protocol is what unlocks the room. MCP servers give the agent hands: a real browser to drive, screenshots to take, consoles to read, services to call. That turns "generate a landing page" from a text task into a build-verify loop. If MCP is new to you, my MCP setup guide covers the plumbing; the rest of this post assumes the plumbing and shows the pipeline.
The pipeline is four stages. Every stage runs from the same Claude Code session.
Stage 1: The Brief Is a Markdown File
Every page starts as a markdown brief in the repo: audience, the one action the page exists to cause, the offer, the objections to answer, the proof I can honestly show. Ten minutes of writing, and it does two jobs: it forces the thinking that no pipeline can do for me, and it becomes the agent's context document so the build stage executes decisions instead of improvising them.
The discipline that matters most in the brief, learned the hard way across my own pages: the proof section may only contain things that are true and checkable. Real project counts, real screenshots, real client outcomes. An agent will happily generate impressive-sounding testimonials if you let it — and fabricated trust content on a lead page is not just wrong, it is commercially self-destructive the day a prospect checks. Write the proof yourself. It is the least automatable paragraph on the page and the one doing the selling.
Stage 2: Build Against Your Own Design System
The build prompt is short because the context is rich: the brief, plus the design tokens and component conventions of the site it will live on. My pages are Blade views in a Laravel app with a token-driven design layer, so "build the page" means "compose it from the system" — the agent reuses the spacing scale, color tokens, and section patterns that already exist. That is what keeps a 30-minute scaffold from looking like a 30-minute scaffold.
Two practices carry this stage. First, point the agent at an exemplar (your best existing page), because models imitate structure more reliably than they follow described rules. Second, let a design-review pass run as its own step, with the agent critiquing hierarchy, contrast, and rhythm against the tokens before you ever look; the design skill I use for this catches the templated-default look that is the tell of AI-built pages. For simpler standalone sites the same two practices apply directly — I walked through that variant in building local business websites with Claude.
Stage 3: Verify in a Real Browser, or You Shipped a Hope
This is the stage that separates a pipeline from a demo, so it gets the war story.
I once shipped a lead-gen page on this site where the form — the entire point of the page — was silently broken in production. Two stacked causes, both invisible in code review: the captcha value was never set into the session, and my guest-page cache layer was stripping cookies on cached responses, so even a correct form could not validate. The page rendered beautifully. The console was clean. Every submission died quietly. No error reached me; the leads just did not exist.
The lesson is now stage three of every run: the agent must prove the conversion path end to end, as a real visitor, in a real browser. With a browser-automation MCP attached (Playwright-based in my setup; here is that workflow), the checklist runs from the same session that built the page:
- Load the page logged-out: as a guest, through whatever caching production applies, not as the developer with a warm session.
- Screenshot at mobile, tablet, and desktop widths; read the layout, not just the HTTP status.
- Read the console and network logs for the errors that render invisibly.
- Fill and submit the form, then verify the record exists — inbox, database, CRM. Not "the form returned 200." The record. Exists.
That last item would have caught my broken form in sixty seconds. It has since caught two other regressions before visitors could meet them. If your pipeline has one verification step, make it this one.
Stage 4: Deploy Is a Push
The page deploys the way everything on this site deploys: commit, push, and a GitHub Actions workflow ships it to production. No FTP session, no page-builder publish button, no "works locally" limbo; the pipeline ends at a live URL because the deploy automation already existed before the AI ever touched a page. That ordering is worth stating for anyone building this: agents multiply whatever pipeline discipline you already have. Automated deploys and design tokens made my 30-minute scaffold possible; bolting an agent onto manual deploys just produces faster-stranded files.
After deploy, measurement is deliberately unautomated in my version: analytics on the conversion action and a habit of actually looking. Tools for A/B testing exist in every flavor and none of them rescue a page whose offer is wrong — iteration on the brief beats iteration on button colors, and the brief is a markdown file precisely so that iterating it re-runs the whole pipeline cheaply.
What the 30 Minutes Cannot Contain
The honest boundary list, because the title's number deserves its asterisks. The pipeline does not know your positioning; the brief does, and writing a good brief is marketing judgment. It does not generate trust; your real work does, and faking it is the one shortcut that costs more than it saves. And it does not make taste optional: the design-review pass narrows the gap between generated and designed, but the final call on "does this feel right" has not been delegated successfully by anyone I believe.
What it does do is collapse the cost of the mechanical middle so far that iteration becomes the default. When a page idea costs thirty minutes to make real and verifiable, you test ideas you would previously have meeting'd to death. That — not the speed itself — is what changed how I work: the pipeline made "let's just build it and look at it" the cheapest option on the table.
A page converts because the brief was honest and the form was proven to submit as a logged-out visitor; everything between those two facts is the part a pipeline can carry for you. Brief-driven, system-composed, browser-verified landing pages are on my services page.
