What Technical Companies Use for Their Marketing Websites.

A technical product does not necessarily need a technical marketing website. The product stack and the marketing stack often have different jobs, and the platforms companies choose reveal more about how the website is operated than how sophisticated the underlying product is.

Research question

What platforms are technical companies using for their marketing websites, and what does that reveal about how those websites are operated?

Scope

This review examines the public marketing websites of technical companies, with attention to the platforms used to build and operate them. The comparison covers Webflow, Framer, and custom code, using current technology-detection data alongside direct company and platform case studies.

The review focuses on the marketing layer rather than the application stack behind the product. Technology-detection data provides current public signals, but it does not establish when a company adopted a platform, whether every part of a domain uses it, or why the company made the decision.

The review was conducted in September 2026.

Finding 01 — The product stack does not determine the marketing stack.

The clearest pattern is the separation between the product and the website.

Technical companies commonly build products with application technologies such as React and Next.js because their products need application logic, state, APIs, data access, authentication, infrastructure, and other software capabilities.

The marketing website has a different responsibility.

It needs to explain the product, publish new pages, manage content, support campaigns, communicate positioning, surface proof, and provide a stable entry point into the product. Those requirements can be better served by a dedicated website platform than by the same application framework used for the product.

This separation is visible in company examples where the public website is operated as a marketing system rather than as an extension of the product codebase.

Roboflow, an AI-powered computer vision infrastructure company, describes its website as a major acquisition channel and says its marketing team owns the site while engineers remain focused on the product. Webflow describes the site as supporting model-specific pages, deployment guides, comparisons, personalized pages, and an expanding content operation.

The important part is that the website has a different operating model from the product itself.

Finding 02 — Webflow has the broadest observed presence across technical marketing sites.

Among the visual website platforms in the companies examined, Webflow has the broader observed presence.

Current Wappalyzer data lists around 390,000 live websites using Webflow. The technical-company examples examined include LangChain, RunPod, Aikido, Mapbox, WorkOS, Clay, Fathom, and Wispr Flow.

The significance is not the absolute number of Webflow sites. A large share of the global web falls outside the population being studied.

The more useful observation is the breadth of technical use cases.

Webflow also appears repeatedly in companies where the marketing website has become operationally important.

Anrok moved from a custom-coded marketing site to Webflow after its website became difficult for its marketing team to maintain. The company described wanting a system that marketing could operate without routing ordinary site changes through technical staff.

Marker.io describes a similar transition. Its original marketing website was custom coded, but ownership eventually shifted toward engineering. Moving to Webflow allowed the marketing team to create landing pages, publish content, and iterate without depending on developers for routine work.

The recurring issue is not whether code can produce a good website.

It is who can operate the website after it exists.

Finding 03 — Framer has a strong concentration among newer and design-led technical companies.

Framer's overall footprint is smaller, but its distribution is distinctive.

Wappalyzer currently tracks around 160,000 live Framer Sites. The technical-company examples examined include Peec, Outlier, Flora, Recraft, Perplexity, Legora, GitBook, and Motion.

There is strong representation from AI-native companies and companies where visual communication and rapid iteration are central to the marketing function.

The company-published examples make the operating pattern clearer.

Perplexity says nearly every public-facing marketing page is built in Framer, including its help center, careers page, security page, get-started guide, changelog, and major campaign pages.

StackAI describes a similar evolution. Its website grew into a large content system containing enterprise use cases, workflow templates, industry solutions, and interactive demonstrations. The company says a lean marketing and growth team maintains the site directly and publishes updates without involving engineering.

Delphi describes choosing Framer because its small team needed to move from idea to live marketing page in hours rather than through a longer developer workflow.

These examples show that a technically sophisticated company does not automatically need a code-heavy marketing stack.

Finding 04 — Platform choice appears to follow website operations more than product complexity.

Once the product and marketing layers are separated, the platform patterns become easier to interpret.

Webflow appears repeatedly where the website has become an operational marketing system: content, landing pages, search-driven pages, collaboration, personalization, structured CMS content, and ongoing experimentation.

Framer appears particularly strong where rapid publishing, visual iteration, direct design ownership, and a small team's ability to ship are central requirements.

Neither observation establishes a universal rule.

There are technical companies using Framer with large, sophisticated websites. Legora, for example, describes a marketing site that grew from a small initial structure to a much larger system, with dozens of weekly updates and a substantial editorial team.

There are also highly technical products using Webflow where the website functions as a significant acquisition and content engine. Roboflow is one current example.

The platform appears to reflect how the website is operated rather than simply the sophistication of the underlying product.

Finding 05 — Custom code can become an operational bottleneck.

The evidence does not support saying that custom code is unsuitable for technical marketing sites.

It does reveal a recurring problem with using the product engineering stack as the default website stack.

Anrok's original marketing site was hand coded and became difficult for the business to maintain.

Marker.io also started with a custom-coded marketing site before moving to Webflow because engineering had effectively become responsible for ordinary marketing-site changes.

The issue in these cases was not whether the code could produce a good website.

It could.

The issue was who could operate the website after it existed.

A marketing website is not finished when it launches. New campaigns, new pages, new content, product changes, new positioning, SEO work, and experiments continue long after the original build.

A technically excellent implementation can therefore become operationally poor if every change requires the same people who build the product.

Interpretation

The evidence supports a narrower conclusion than a platform comparison.

Technical companies are treating the marketing website as a distinct system with distinct requirements.

The product stack optimizes for building and running the product.

The marketing stack optimizes for explaining, publishing, experimenting, and maintaining the public representation of that product.

That distinction explains why the same company can use a code-first application stack and a visual website platform without any architectural contradiction.

It also suggests that platform choice is often connected to marketing ownership and operating requirements rather than product sophistication alone.

Webflow has the broader observed presence across the technical companies examined. Framer has a particularly visible presence among newer, design-led, and AI-native companies.

The useful decision is therefore to understand what the marketing site needs to become before deciding what should power it.

What the evidence says about platform choice.

The evidence points to different operating patterns rather than a universal platform choice.

Webflow

Webflow is strongly represented where the marketing website behaves like a mature content and growth system.

The observed use cases include:

• large CMS-driven content systems
• technical and developer-focused content
• high-volume landing-page production
• personalization and programmatic content
• collaboration between marketing, design, and development
• websites that need to keep evolving without making engineering the gatekeeper

This is not a claim that Webflow is inherently better at these tasks. It is a description of the kinds of technical companies currently using it and the operating problems those companies describe.

Framer

Framer is especially visible among newer, design-led, and AI-native companies.

The observed use cases emphasize:

• rapid launches
• rapid iteration
• direct design and marketing ownership
• frequent campaign and product-page changes
• strong visual communication
• smaller teams that need to publish without developer handoff

Again, this is an observed pattern, not a universal limitation of the platform.

Custom code

Custom code remains appropriate when the marketing layer genuinely needs capabilities that are difficult or inefficient to express in a visual website platform.

It also remains a reasonable choice when an organization deliberately wants the marketing site to live inside the same engineering system as the product.

The evidence does not support the assumption that a technical product automatically benefits from a code-first marketing website.

That distinction is more useful than the technology labels alone.

The larger pattern

The most useful conclusion from the research is not a platform ranking.

It is this:

Technical products do not necessarily need technical marketing websites.

A company can build an extremely sophisticated product while choosing a marketing stack optimized for communication and operational independence.

The marketing site has to make the product legible before a visitor ever reaches the product itself.

It may need to explain workflows, publish documentation, surface changelogs, show integrations, communicate security, create industry pages, support search, launch campaigns, and change as the company's understanding of its market improves.

Those are not secondary responsibilities.

They are the website's job.

The relevant question is therefore not simply what the product is built with.

It is what the marketing website needs to become, and who needs to operate it.

What to investigate next

The next useful question is what happens when a company outgrows the first version of its marketing stack.

Do companies migrate from custom code to Webflow or Framer because the website becomes a bottleneck?

Do companies move from Framer to Webflow as their content model, team size, or governance requirements grow?

Do companies move in the opposite direction when speed and design ownership become more important?

And how much of that migration is caused by the platform itself versus changes in the company's operating model?

Those questions would require a larger longitudinal sample than the current study. They are worth investigating because the choice of marketing stack may tell us less about what a company is building than about how it expects the website to operate as the company grows.

Related research

A marketing website is not simply the public wrapper around a technical product. Its architecture determines how easily a company can explain, publish, adapt, and maintain that product's story as the system grows.