Most SaaS founders take six weeks to ship a landing page that should take seven days. The page sits in Figma for two weeks, in dev for two more, and in "one more review" for the rest. By the time it ships, the positioning is already stale. The teams that ship in one week are not faster designers, they are faster decision-makers, and the playbook is repeatable.

This playbook walks through seven steps to ship a SaaS landing page in one week, in the order an experienced product designer would run them. Each step has a definition, why it matters, a concrete execution checklist, what to deliver by end of day, the common mistakes founders make, and a real-product example where the principle is visible.

TL;DR, shipping a SaaS landing page in one week is a sequence: lock the positioning on day one, write the copy on day two, design the wireframe on day three, design and build the page on days four and five, instrument and pre-launch on day six, then ship and iterate on day seven.

How to ship a SaaS landing page in one week: a brief overview

• Day 1, lock the positioning: One audience, one promise, one proof. Decided, not debated.

• Day 2, write the copy first: Hero, problem, product, proof, pricing, FAQ, CTA. Copy before pixels.

• Day 3, wireframe the page on one screen: Sections, hierarchy, scroll narrative. No visual yet.

• Day 4, design the high-fi page in Figma or Framer: Build the system in flight, only what the page needs.

• Day 5, build the page in the publishing tool: Framer, Webflow, or Next.js. Pick one and ship.

• Day 6, instrument, QA, and stage: Analytics, A/B, accessibility, performance, mobile.

• Day 7, launch and iterate: Ship, watch the funnel for 48 hours, then iterate.

| Step | Outcome | Timebox | Owner | Common mistake |

|---|---|---|---|---|

| 1. Lock positioning | One-page positioning doc | Day 1 | Founder | Trying to serve three audiences |

| 2. Write copy | Full page copy in a doc | Day 2 | Founder plus writer | Designing before copy is locked |

| 3. Wireframe | One-screen wireframe | Day 3 | Product designer | Skipping straight to high-fi |

| 4. High-fi design | Designed page in Figma or Framer | Day 4 | Product designer | Designing 80 components first |

| 5. Build in tool | Page live on staging URL | Day 5 | Designer plus dev | Picking a heavy stack for a page |

| 6. Instrument and QA | Analytics live, page passes QA | Day 6 | Founder plus engineer | Skipping QA to ship faster |

| 7. Launch and iterate | Page live, baseline measured | Day 7 | Founder | Launching and walking away |

1. Day 1, lock the positioning before you write a single word

Locking the positioning means writing a one-page positioning document that names the audience, the promise, and the proof in three sentences. Without that document, every later decision (copy, design, CTA, pricing) becomes a debate.

Why it matters: Most landing pages that take six weeks were stuck on day one and the team did not notice. The page kept moving without a settled positioning, and every review reopened the same arguments. A locked positioning ends the debate before the page exists. Day one is the cheapest day to make the decision.

How to execute

• Write three sentences: "Our audience is X. The promise is they can do Y faster, cheaper, or better than Z. The proof is A, B, and C."

• Decide on one CTA goal for the page (signup, demo, trial, pricing). Pages with two CTA goals convert worse on both.

• Pick three reference landing pages from companies in adjacent categories (not competitors) and document what you will steal in structure.

• Share the positioning doc with the team. If anyone has a fundamental disagreement, surface it now, not on day four.

Deliver by end of day 1: A one-page positioning document, a chosen CTA goal, and three reference pages tagged.

Common mistakes

• Trying to write the page for three audiences in one go. Three audiences need three pages.

• Choosing two CTA goals because "we should test both." Test after launch, decide before.

• Skipping the positioning doc because "we have it in our heads."

Real example: Linear's home page is built on one settled positioning ("the tool for ambitious product teams"). The audience, promise, and proof are visible in the hero, the section structure, and the proof. The positioning was clearly locked before the page existed.

2. Day 2, write the page copy in a doc before you touch design

Writing the copy first means producing the full page copy (hero, problem, product, proof, pricing, FAQ, CTA) in a plain document on day two, before opening Figma. Copy is the spine of the page. Design dresses the spine, it does not replace it.

Why it matters: Designs built before the copy is locked get torn up the moment the copy lands. Worse, weak copy hides behind strong design for a week and then crashes the launch when no one can explain what the product does. Writing the copy first compresses the timeline and surfaces positioning problems while they are still cheap.

How to execute

• Write the hero first: a six-to-ten word headline, a one-sentence subhead, and the CTA label.

• Write the problem section next: name the audience's specific pain, in their language, in two sentences.

• Write the product section as three to five outcomes with one screenshot each (placeholder for now).

• Write proof (a metric, a quote, two to four customer logos), pricing (the simplest possible version), FAQ (six to eight questions), and the final CTA.

• Read the doc out loud. Cut every word that does not earn its place.

Deliver by end of day 2: A full copy doc with hero through CTA, locked.

Common mistakes

• Letting the designer "write copy in Figma" and shipping placeholder phrases by mistake.

• Writing 1,500 words for a landing page that should run 400 to 700.

• Adding marketing buzzwords ("seamless", "effortless", "AI-powered") instead of naming the outcome.

Real example: Cursor's landing copy is short, direct, and outcome-led. The hero names the audience and the outcome in one sentence. Most pages that take a month to ship had copy half this strong on day one and never fixed it.

3. Day 3, wireframe the page on one screen, no visual yet

Wireframing the page on one screen means laying out the section order, hierarchy, and scroll narrative as boxes and labels in Figma, with no colors, no images, and no type styling. The wireframe locks the structure before the visual debate begins.

Why it matters: Structural problems (the proof section is too late, the pricing is buried, the FAQ is too long) are invisible inside a high-fi mock. They are obvious in a wireframe. Spending day three on structure saves two days of redesign later.

How to execute

• Map the section order: hero, problem, product, proof, pricing, FAQ, CTA. Adjust based on the positioning, but default to this order for B2B SaaS.

• Draw each section as a labelled box. Label the content, not the visual.

• Check the scroll narrative: does each section earn the next scroll. If a section does not, cut it.

• Run the wireframe past one user and one teammate. If either is confused, the wireframe is not done.

Deliver by end of day 3: A single-screen wireframe in Figma with every section labelled and ordered.

Common mistakes

• Skipping the wireframe and going straight to high-fi. Almost always costs a day of rework.

• Wireframing nine sections when the page needs five.

• Wireframing in colour and getting stuck on the gradient instead of the structure.

Real example: Notion's marketing pages are visibly wireframed first. The section order is consistent across pages, the hierarchy is obvious, and the scroll narrative reads cleanly even with the visuals stripped away.

4. Day 4, design the high-fi page in Figma or directly in Framer

Designing the high-fi page means turning the wireframe into a finished visual on day four, using only the design tokens and components the page actually needs. The system is built in flight, not as a prerequisite.

Why it matters: Founders lose weeks trying to build a "real design system" before the landing page. For a one-week landing page, the system is one brand color, two typefaces, a spacing scale, and the eight components the page uses. Anything more is procrastination disguised as polish.

How to execute

• Lock the tokens first: one brand color with five tints, a five-step neutral scale, two typefaces with a six-size scale.

• Design the hero, the problem, and the product sections in that order. Stop and pressure-test the hero before continuing.

• Use real product screenshots, not 3D renders or stock illustrations. If the product is not screenshot-ready, the page is premature.

• Design mobile alongside desktop, not after. Mobile-after is a four-hour rework on day five.

Deliver by end of day 4: A finished high-fi design in Figma or Framer, desktop and mobile.

Common mistakes

• Building 80 components before designing the page that uses 12.

• Using stock illustrations because the product is not photogenic. Fix the product surface first.

• Designing desktop only and treating mobile as a "later" problem.

Real example: Linear's design system is famously tight, and the marketing pages use a fraction of it. The system was built in flight, alongside the page, not before it.

5. Day 5, build the page in the publishing tool you will actually ship in

Building the page in the publishing tool means recreating the high-fi design directly in Framer, Webflow, or your Next.js codebase on day five. The build is faster than the design if the tool is right and the team is decided.

Why it matters: Teams lose days picking the stack. For a one-week landing page, the rule is simple: ship in the tool your team already knows, not the trendy one. The page that ships in Framer this week beats the page that almost shipped in a custom Next.js stack next week.

How to execute

• Pick the tool on day five morning: Framer for design-led teams, Webflow for content-led teams, Next.js for engineering-led teams. Do not change tools mid-build.

• Build section by section in the same order as the design: hero, problem, product, proof, pricing, FAQ, CTA.

• Use the publishing tool's native components, not custom code, wherever possible. Custom code on day five is a launch risk.

• Push to a staging URL by end of day. The staging URL is your day-six baseline.

Deliver by end of day 5: A live staging URL with the full page built, desktop and mobile.

Common mistakes

• Switching tools on day three of the build because "Framer is faster."

• Writing custom React for every section instead of using the tool's primitives.

• Skipping the staging URL and "previewing locally" until launch.

Real example: Lovable's landing page evolves on Framer, with the team shipping updates in days, not weeks. The choice of tool matched the team's design-led muscle, which is why iteration speed compounds.

6. Day 6, instrument, QA, and stage the page like a launch

Instrumenting, QAing, and staging means wiring analytics, accessibility, performance, and mobile QA into the staging URL on day six, before launch. The page is not done until it can be measured and audited.

Why it matters: A landing page without analytics is a guess. A landing page with broken accessibility loses users and rankings. A landing page that scores 60 on PageSpeed costs you conversions before the first visitor reads the hero. Day six is when a one-week page becomes a real product surface.

How to execute

• Add analytics: page views, scroll depth, CTA clicks, signup conversion. PostHog, Vercel Analytics, or Plausible all work for day six.

• Run an accessibility pass: keyboard navigation, contrast ratios, alt text on every image, focus states on every interactive element.

• Run a performance pass: target a Lighthouse score above 90 on mobile, compress every image, lazy-load anything below the fold.

• QA on three real devices (an iPhone, an Android, a laptop) plus a screen reader pass.

Deliver by end of day 6: An instrumented, accessible, fast staging page ready for launch tomorrow.

Common mistakes

• Shipping without analytics and never knowing what worked.

• Skipping accessibility because "we will fix it after launch." After launch is never.

• Testing only in the design tool preview and shipping a broken mobile page.

Real example: Vercel's marketing pages are an instrumentation template. Every CTA is tracked, performance is consistently in the 95 plus range on Lighthouse, and accessibility is non-negotiable. The standard is what one-week pages should match by day six.

7. Day 7, launch the page and iterate on the funnel

Launching and iterating means pushing the page live on day seven, watching the funnel for 48 hours, and committing to one round of iteration based on what the data shows. Launch is not the end of the week, it is the start of the next loop.

Why it matters: A landing page that launches and is forgotten loses to a landing page that launches and learns. The first 48 hours of traffic reveal which section is dropping users, which CTA copy is working, and which mobile breakpoint is broken. The team that watches the funnel ships the second version in week two.

How to execute

• Ship the page on day seven morning, not Friday afternoon. Mornings give you the day to fix anything that breaks.

• Watch the analytics for 48 hours: traffic, scroll depth, CTA conversion. Note the biggest single drop in the funnel.

• Commit to one iteration in the following week, targeted at the biggest drop. Not five iterations, one.

• Document the launch baseline (conversion rate, scroll depth, mobile share) so future iterations can be measured against it.

Deliver by end of day 7: A live page, a 48-hour baseline, and a single iteration committed for the following week.

Common mistakes

• Launching and walking away. The 48-hour data is the most valuable signal you will get all quarter.

• Trying to iterate five things at once and learning nothing.

• Launching on Friday afternoon and discovering a mobile bug on Saturday morning.

Real example: Linear's launch posts and home page updates are visibly iterated. Each version sharpens the positioning, the proof, or the CTA. The team treats the page as a product, not a one-shot artefact.

How to choose what to compress when you do not have a full week

1) Do you have three days instead of seven?

If you have three days, run day 1 (positioning), day 2 (copy), and a combined day 3 (wireframe plus high-fi plus build in Framer). Skip the custom design system, use Framer's primitives, and instrument with Vercel Analytics or Plausible. The page will be 80 percent as good as a seven-day page if positioning and copy are locked.

2) Do you have a designer and a developer, or just one of them?

With both, days 4 and 5 run in parallel and you can ship by day 5. With only a designer, ship in Framer or Webflow (no code needed). With only a developer, use Tailwind UI blocks for the high-fi step and focus the design effort on hero and product sections only.

3) Is this a new page or a redesign of an existing page?

Redesigning an existing page is faster on days 1 and 2 (you have the positioning and copy mostly) but slower on day 6 (you have to preserve URLs, SEO, and tracking). Budget the same total time, just shift the effort.

4) Is the product photogenic yet?

If the product UI is still vibecoded or templated, fix the in-product surface first. A landing page built on screenshots of a templated product converts at the templated product's level. Ship the page after the product looks like the page promises.

If you have positioning locked but want a design partner to run the week with you and ship a page that earns the click instead of just looking nice, that is what AY Design does. We build SaaS landing pages on tight timelines for AI-product teams and post-PMF founders. Book a design audit to see the fastest path to your next landing page.

FAQ

Can you really ship a SaaS landing page in one week?

Yes, a SaaS landing page can ship in seven calendar days if positioning is locked on day one, copy is written before design, and the team uses a publishing tool they already know. The page will not ship in one week if any of those three conditions are broken. Most one-week landing page failures are positioning failures pretending to be design failures.

What is the right length for a SaaS landing page?

A SaaS landing page should run between 400 and 900 words of body copy across the full scroll. Shorter pages underexplain the product to a cold audience, longer pages bury the CTA. Linear, Notion, and Cursor home pages all sit in this range. The exception is a long-form sales page for high-ticket B2B, which can run longer.

Should I build my SaaS landing page in Framer, Webflow, or Next.js?

Build in the tool your team already knows. Framer is fastest for design-led founders, Webflow is strongest for content-heavy marketing teams, Next.js is best when the landing page needs to share components with the app. For a one-week landing page, do not learn a new tool. The tool that ships beats the tool that almost shipped.

What sections does a SaaS landing page need in 2026?

A SaaS landing page in 2026 needs seven sections: hero, problem, product (with real screenshots), proof, pricing, FAQ, and a final CTA. Optional sections include a customer logo bar near the hero and a comparison table for competitive categories. Any section that does not earn the next scroll should be cut.

How important is mobile design for a SaaS landing page?

Mobile design is critical: more than 40 percent of B2B SaaS landing page traffic comes from mobile, and almost all paid-acquisition click-throughs happen on a phone. A landing page that converts on desktop and crashes on mobile is leaking the majority of the funnel. Design mobile and desktop in parallel on day four, not desktop first and mobile later.

Do SaaS landing pages still need an FAQ section?

Yes, an FAQ section is one of the highest-ROI parts of a 2026 SaaS landing page. It answers buyer objections in their own words, captures long-tail search traffic, and feeds AI search engines (ChatGPT, Perplexity, Google AI Overviews) the structured Q and A they extract. Six to eight questions is the sweet spot, with short, direct answers.

What analytics should I install on a new SaaS landing page?

Install four analytics events on a new SaaS landing page: page view, scroll depth (25, 50, 75, 100), CTA clicks, and signup conversion. PostHog, Vercel Analytics, Plausible, or Fathom all do this in under an hour. The four events answer 80 percent of the questions you will ask in the first month after launch.

Should I hire a designer for a SaaS landing page?

Hire a designer if you have budget and the page is the primary acquisition surface for the next two quarters. DIY the page in Framer or Webflow if you have taste, time, and an existing system. For a one-week deadline with high stakes, a specialist landing page designer or an AI-product design agency like AY Design compresses the timeline without sacrificing the quality.