NewBase
Get in touch

Webflow to Astro for AI companies

An AI company's marketing site changes faster than most. The migration is about keeping that pace: what stays content, what becomes a component, and where the public site stops and the product's API begins.

Get in touch

Draw the line while you are moving the site.

Three systems, and the one in the middle

Astro

The marketing site

  • Positioning, as content rather than markup
  • Use cases, comparisons and launches
  • The changelog
  • Structured data and the crawler rules

The handoff

Where the two meet

  • Signup and demos
  • A model call, through an endpoint you own
  • Analytics events
  • Live product data

Your product

The model and the app

  • The model, and the API in front of it
  • Auth and accounts
  • Billing and usage
  • Anything with a cost per call
A migration is the cheapest time to write down which system owns what. Marketing work that used to reach the product team by accident usually did so through the seam in the middle, which is the part worth testing on both sides.

The story moves as a model, not as pages.

Use cases, capabilities, comparisons and technical proof each become a collection with its own template. What exists today moves as entries; what gets added next month is a content change rather than another build.

Product story One content model, many pages

Use cases

Models and capabilities

Comparisons and alternatives

Docs and resources

Use cases
The problems people actually arrive trying to solve.
Models and capabilities
What the product can do, stated concretely.
Comparisons and alternatives
How buyers evaluate it against the other approach.
Docs and resources
The technical proof behind the marketing claims.

Keep the product readable when the scripts stop.

A rebuild is the moment to decide what lives in the markup rather than in a script that has to run first. Both audiences below read the same structure, which is why it is worth settling while the site is being rebuilt.

Your product

One clear structure

  • Product
  • Use cases
  • Integrations
  • Docs
  • Proof

People

  • Understand the product
  • Compare it with the alternative
  • Find proof it works
  • Know what to do next

Machines

  • Identify the company and product
  • Understand the relationships
  • Retrieve supporting content
  • Surface a useful answer

The stack matters as much as the pages.

Astro The marketing site

What gets decided before the rebuild.

  1. 01

    What is content and what is a component

    Positioning that changes monthly belongs in the content model. The shape it is poured into belongs in the codebase. Getting that line wrong is what makes a rebuild slow to live in.

  2. 02

    Whether the use cases are pages or a template

    A handful can stay individual pages. A library that keeps growing wants one template and a collection, which is also the part of the migration that scales.

  3. 03

    What a machine can read once the scripts stop

    Product meaning carried only in animation or client-side rendering is the part most at risk in any move. Putting it in the markup is worth doing while the site is being rebuilt anyway.

  4. 04

    Where the demo boundary sits

    A live model call needs a key, and a key does not belong in a public page. Naming that boundary before the rebuild stops it being discovered afterward.

Questions from AI companies.

Our positioning changes every few weeks. Does moving to a codebase slow that down?

It depends entirely on what was modeled as content before the rebuild. Copy, headlines, use-case entries and changelog posts can stay editable in a CMS, and changing them is publishing rather than a release. A new section that has never existed becomes a change in the codebase with a review on it. That review is the cost, and it is worth naming rather than discovering.

What reaches our product from the marketing site?

Only what you decide to send. A form posts to the system you name and analytics events go where you configure them. The site does not read your product data and does not hold credentials, and anything that would have to belongs behind an endpoint you own.

Can the interactive demos come across?

The behavior can. Interactions configured in Webflow are rebuilt in the new codebase rather than carried over with the Webflow runtime, so a demo that mattered gets rewritten deliberately and one that never earned its weight is a conversation. A production model call with a key in the page should not survive the move in that shape, and if something in the current site works that way I will say so.

What happens to our structured data and crawler rules?

They move with the pages and get checked against what the new page actually says. Structured data that matches its page and crawler rules that say what you mean are worth reviewing during a migration, because both are easy to carry across stale. No single file or schema type is an answer-engine strategy, and nobody can promise what an assistant will do with any of it.

Can our marketing team manage the site afterward?

For the content that was modeled as content, yes: that is the point of deciding it up front. Repeated content lives in the CMS and the components are built to be rearranged. Publishing does not need engineering; inventing a new page pattern does.

Building something else?

Reach out and see if we are a good fit.

Get in touch

Currently booking two to four weeks out.