Ship landing pages in hours: Cursor, Claude Code, and GitHub

The old workflow for a marketing landing page was brutal: marketing writes a brief, design mocks it in Figma, engineering builds it, everyone reviews, three rounds of copy changes happen in Slack, and it ships two weeks later. At a startup, two weeks is a lifetime. The workflow I run now with marketing cuts that to hours. The secret isn’t speed for its own sake—it’s removing the handoff bottlenecks that slow everything down and misalign both teams along the way. AI is the lever, but the real change is structural: design and marketing collaborating directly in code, with GitHub as the shared workspace.

The old landing page workflow and why it breaks at startup speed

Traditional landing page production has four inherent failure modes that compound each other.

The brief-to-design gap. Marketing writes a brief in a doc. Design interprets it in Figma. Something is always lost in that translation—tone, emphasis, the specific argument marketing was trying to make. By the time the mockup reaches review, marketing has already moved on mentally, and the feedback round feels like starting over.

The design-to-engineering gap. Design hands off a Figma file. Engineering builds it. The coded version looks slightly different—spacing off, interactions missing, responsive behavior undefined. Another round of back-and-forth that adds days.

The copy-change cycle. Copy changes are the most expensive thing in the traditional workflow. Every change to headline or CTA copy means updating Figma, waiting for it to be coded, reviewing again. In Slack. Asynchronously. With a minimum of 24-hour turnaround per round.

Deployment friction. Even after everything is approved, getting it live requires a deploy. That means an engineer, a PR, a review, a merge, a pipeline. Sometimes that’s same-day. Sometimes it’s not.

Each of these gaps is a handoff, and each handoff is a place where context is lost and momentum dies. The AI-plus-GitHub workflow eliminates every one of them.

Claude Code scaffolds the 80%, Cursor polishes the 20%

The two tools have distinct roles in the workflow, and understanding the boundary between them is what makes the system work.

Claude Code is the builder. Its job is to go from a content brief to a working page structure as fast as possible. I give Claude Code the messaging brief from marketing—the value proposition, the target audience, the CTA hierarchy, the key sections—and it produces a full landing page in semantic HTML with CSS. In a single session, it generates the layout structure, responsive grid, section components, content blocks, Open Graph meta tags, and a first pass at copy adapted to the brief. Claude Code is fast and broad. It assembles the bones of the page in minutes. The output is functional but not precious—it’s a scaffold, not a deliverable.

Cursor is the finisher. After Claude Code produces the structure, I switch to Cursor for the detail work. This is where the page goes from “technically correct” to “actually designed.” In Cursor I dial in typography scales, adjust spacing to match the design system, refine color values, polish micro-interactions, fix responsive edge cases, and handle the visual details that separate a designed page from a generated one. Cursor’s context-aware editing and its ability to see the whole project at once makes this refinement loop tight enough to do in real time. A change to the headline spacing is visible in the browser preview immediately—no context switch, no deploy cycle, no Figma-to-code translation.

The split is roughly: Claude Code produces the 80% scaffold in the first session, Cursor handles the 20% polish that makes it production-quality.

How do you structure the GitHub collaboration between design and marketing?

The collaboration model is built on one principle: both design and marketing work in the same medium at the same time. Marketing isn’t writing a brief and waiting. Design isn’t building in isolation and presenting. Both are in the repository.

The workflow step by step:

1. Marketing drafts the brief as a PR description. The brief—messaging, target persona, CTA priorities, section requirements—is written directly in a GitHub pull request description. This puts the brief in the same place as the work, which eliminates the brief-as-doc problem.

2. Design scaffolds in Claude Code and opens a draft PR. The scaffolded page goes into a branch. A draft PR is opened immediately. GitHub’s PR preview deployment makes the actual page visible to marketing within minutes of starting.

3. Marketing reviews on the live preview. Marketing comments directly on the PR—not on a Figma file, not in Slack. They see the actual page at actual scale. Their copy feedback is specific because it’s in context. “This headline doesn’t land” is much more actionable when they’re reading it on the built page than when they’re reading it on a mockup.

4. Design refines in Cursor while marketing comments. Changes are pushed to the branch. The preview updates. The iteration loop is tight.

5. GitHub Actions deploys on merge. When both sides are satisfied, the PR merges. GitHub Actions runs the build and deploys automatically. The page is live.

Total elapsed time from brief to live: three to four hours for a standard campaign page. For a more complex page with custom sections and interactive elements, a day.

What this workflow produces beyond speed

The speed gain is real, but it’s not the most important change. The more important change is what happens to the quality of collaboration when both teams are working in the same medium.

Feedback specificity improves dramatically. When marketing can comment on the actual page at real scale—with real copy, real button states, real mobile layout—their feedback is no longer abstract. “The hero feels weak” becomes “the headline is too small relative to the background image at mobile, and the CTA is below the fold on iPhone SE.” Specific feedback is actionable feedback.

Ownership becomes shared. When the page is co-built in a shared repo with commit history from both teams, the output belongs to both. Marketing can’t say “design got it wrong” when they were commenting on PRs throughout. Design can’t say “marketing changed the brief” when every change is in the PR thread. The Git history is the truth.

Copy changes become zero-cost. Marketing can edit copy directly in the repository after shipping. A headline change is a one-line PR. Merge, deploy, done. No design involvement required for content-only changes. This changes the relationship between marketing and the product permanently—marketing has agency over their own content without depending on design capacity.

For a related perspective on how design and marketing build shared operational systems, how Head of Design and Head of Marketing actually collaborate covers the project management layer that makes this kind of joint ownership sustainable.

Slide decks and other content types follow the same pattern

The landing page workflow generalizes to any content type that has a visual structure and a content brief. Slide decks are the second most common application.

For pitch decks, conference presentations, and demo decks, the split is the same: Claude Code drafts the narrative structure, section flow, and content blocks; Cursor handles the visual refinement, layout precision, and brand application. The resulting deck lives in a repository alongside the landing page. Version history is in Git. Copy changes are PRs. Distribution is a GitHub Pages link.

Other applications of the same model: microsite campaigns, product changelog pages, case study pages, job listing pages, press kits. Anything with structured content and a visual wrapper benefits from the same scaffold-then-polish pattern.

How do you get started with this workflow?

If you’re a design-marketing pair looking to adopt this, here’s where to begin:

• Start with one simple campaign page, not your flagship homepage. Pick a page with limited complexity—a webinar registration page, a product launch announcement, a feature spotlight.
• Get marketing comfortable with GitHub early. The learning curve is real, but it’s mostly about reading PR diffs and writing comments—neither requires engineering knowledge.
• Set up GitHub Actions for preview deployments first. If every branch automatically deploys to a preview URL, the collaboration loop becomes self-sustaining. No one needs to ask “can I see it?” because it’s always there.
• Use Claude Code via the web interface initially, not the CLI. The web interface is accessible to marketing and requires no setup. Once the pattern is established, the CLI speeds up the design side.

For more on the CI/CD infrastructure that makes continuous preview deployments work, GitHub Actions and CI/CD: a designer’s guide covers the pipeline setup that underpins this workflow.

Key Takeaways

• The traditional landing page workflow has four compounding failure modes: brief-to-design gap, design-to-engineering gap, copy-change cycle friction, and deployment delay—all caused by handoffs between mediums
• Claude Code handles the scaffold (structure, layout, content, meta tags) fast; Cursor handles the polish (typography, spacing, interactions, responsive detail)
• The GitHub collaboration model—brief as PR description, live preview on every branch, copy changes as PRs—gives marketing agency over content and design control over quality simultaneously
• Copy changes become zero-cost after shipping: one-line PRs that marketing can make without design involvement
• The same scaffold-then-polish pattern applies to slide decks, campaign microsites, changelog pages, and any structured visual content