How to Choose the Right Tech Stack for a Marketing Website

Most tech stack debates start in the wrong place. Someone asks whether to use Astro, Next.js, or Webflow, and an answer arrives before anyone has described the content, the publishing workflow, or what the site is supposed to achieve.

A marketing website is a business tool. The stack that fits is the one that makes publishing easy, keeps pages fast, and avoids maintenance work nobody has time for. This guide gives you a framework you can apply before you talk to any developer.

Start with the content and who edits it

The first question is not technical. It is: who changes this site after launch, and how often?

• Rarely, and a developer handles it. A static build is enough. No CMS, no admin accounts, no subscription.
• Monthly, by a marketer without code access. You need a CMS, and the editing experience matters more than the framework.
• Weekly, by several people, with a review step. You need structured content, roles, and a predictable publishing workflow.

Teams routinely buy a stack they cannot edit, then pay a developer for every text change. That cost is invisible in the proposal and obvious six months later.

Separate a website from an application

The second question: does the site need accounts, user data, dashboards, payments, or logic that runs on a server?

If the answer is no, you are building a content site, and almost any modern stack will perform well. If the answer is yes, you are building an application with a marketing site attached, and that changes the decision entirely.

Many projects overbuild here. They pick an application framework for a nine-page brochure site and inherit a build pipeline, a deployment surface, and a dependency tree the content never needed.

The four realistic options

These are the options that come up in almost every project. The stacks I work with day to day are listed on the technologies page.

Static build

Best when the content is stable, the page count is low, and nobody outside the dev team needs to publish. Fastest to load, cheapest to host, almost nothing to maintain. The limit is editing: every change goes through a developer.

Astro

Static-first output with components and a content layer. It ships almost no JavaScript by default, so pages stay fast as the site grows. A strong fit for marketing sites, documentation, and blogs that publish regularly with a CMS behind them.

Next.js

A full application framework: server rendering, API routes, authentication, and data fetching in one codebase. The right answer when the site genuinely needs application behaviour, and an oversized one when it does not. The split is covered in detail in Astro vs Next.js.

Webflow

A visual builder with a hosted CMS. The real advantage is that non-technical people can change layout and content without a deployment step. The tradeoffs are platform ownership, subscription cost, and limits once requirements get unusual — covered in why Webflow still delivers value.

A decision matrix you can actually use

1. Content changes a few times a year and there are no editors: static build.
2. Content is published regularly, editors need a CMS, and the site is content-first: Astro with a headless CMS.
3. The site needs accounts, dashboards, server logic, or deep integrations: Next.js.
4. Marketing owns the site and wants to change layout without developers: Webflow.
5. An approved design exists and time to launch matters more than ownership: Webflow or Astro, depending on who edits after launch.

Three scenarios

A consultancy with eight pages and a quarterly update

A static build or Astro. A CMS added “just in case” becomes a subscription and a login nobody uses, and it adds a moving part to every future change.

A SaaS company publishing two articles a week

Astro plus a headless CMS. Keeping the marketing site separate from the product app means a content change never risks a product deploy, and the marketing team stops queueing behind engineering.

A service business with a booking flow and customer accounts

Next.js for the application. The marketing pages can live in the same codebase or in a separate content site, and that choice comes down to who publishes and how often.

What usually goes wrong

• The stack is chosen before the content. The sitemap and the editing workflow should come first.
• A CMS is bought and never used, or a site ships that nobody in the company can edit.
• Performance is treated as a launch-day metric instead of something the stack keeps enforcing.
• Migration cost is ignored. Moving platforms later means URLs, redirects, and analytics history, which is real migration work.
• Budget is treated as separate from the stack decision, when the two are the same conversation. What actually moves the number is covered in what a marketing website costs.

How to decide in practice

Write down three things before comparing tools: the pages you will genuinely maintain, the person who edits each type of content, and anything the site must do beyond publishing. In most projects the answer becomes obvious once those three exist on paper, and the framework argument stops mattering.