TL;DR
Webflow Source brings visual editing and AI agents to a code-based working environment that can connect to an existing stack. Its limited research preview arrives as code-oriented tools put pressure on visual builders. The opportunity extends to how Raze builds websites with agents, keeps brand decisions human, and creates supported paths for buyers and their assistants to interact, book, and buy.
Webflow Source makes more sense when you look at the pressure on Webflow's original promise.
For years, visual builders offered a compelling shortcut: design and publish a website without taking on the full complexity of software development. The platform handled much of the implementation, and the team accepted its rules in exchange for speed.
AI coding agents are changing that trade. They can help people navigate, modify, and extend a codebase directly. The technical knowledge still matters, but fewer tasks require someone to manually write every line. That gives teams another route to a custom website and weakens the idea that avoiding code should be the main reason to choose a platform.
Our reading is that Webflow had to make a substantial bet on this shift. Source is its attempt to keep visual development useful while moving the foundation underneath it toward real code, agents, and shared team workflows.
There is evidence of competitive pressure behind that reading. There are also limits to what the available market-share figures prove. Both matter if you want to understand the announcement beyond the launch demo.
What is Webflow Source?
Source by Webflow is a platform for marketing teams and their AI agents to build and operate websites together. Webflow describes visual editing and direct code access, dedicated interfaces called Views, and agent work governed by permissions and review.
Source can connect to an existing codebase, CMS, marketing tools, and hosting. It is intended to work beyond websites built in the traditional Webflow Designer.
Webflow introduced Source on September 2, 2026. As of September 3, it is in a limited research preview. This article analyzes the public materials; it is not a hands-on review of the preview.
The ambition extends across the life of a website: building it, publishing content, making changes, measuring what happens, and deciding what to do next. That wider ambition explains why Source includes collaboration and governance alongside creation tools.
Why Webflow had to rethink its advantage
A platform's value depends partly on the alternatives available to its customers. If producing and maintaining custom code becomes more accessible, the value of a system designed to shield people from that code changes too.
Consider a company that needs an interactive product demo, a custom lead-routing flow, or a library of industry pages. A visual builder can make the first version convenient. As requirements become more specific, the team may accumulate embeds, scripts, and integrations that sit awkwardly around the builder's core model.
A codebase gives engineers a place to express those requirements directly. Agents make that route easier to explore: they can inspect existing components, explain unfamiliar code, propose a change, and help work through an implementation. The team still needs to verify behavior, security, accessibility, and performance. But the initial effort involved in changing the software is shifting.
That is the strategic pressure. Webflow has to offer value to teams that now see code as something they can work with, rather than something they must avoid.
Webflow itself acknowledges the catch-up. In its August architectural essay, the company asks whether the move amounts to catching up with code-first tools and answers, “Partly, yes.” It also reports that more than 30% of its enterprise customers were already using agents against production sites through MCP, roughly four times the January figure.
Those are Webflow's own reported numbers. They suggest the change was already happening inside its customer base. Agents were becoming participants in website work, whether or not the platform had originally been designed around them.
What the market-share evidence actually shows
Ramp's vendor pages, checked on September 3, 2026, show Webflow losing adoption share while Vercel gains it within the same observed purchasing category:
Vendor | Adoption in Ramp's Web Hosting & Site Builders category | Year-over-year change |
|---|---|---|
20% | Down 3 percentage points | |
21% | Up 4 percentage points |
Ramp measures businesses purchasing a vendor as a share of businesses purchasing within that category over the preceding twelve months. These figures come from transactions observed through Ramp. They are not percentages of all websites or global revenue market share.
The pattern supports an argument about competitive pressure: a platform oriented toward code-based development is gaining adoption while Webflow's share of that category has weakened. It does not identify individual Webflow customers moving to Vercel, and Vercel adoption is not a count of Next.js migrations.
A separate measure gives useful context. W3Techs reports Webflow on 0.8% of surveyed websites in September 2026, versus 0.9% a year earlier. Its share among sites with a known CMS remained at 1.2%. The denominator changes the story.
The defensible conclusion is that Webflow faces measurable pressure in parts of the market as code-oriented alternatives gain relevance. Source is a strategic response to that environment. Claiming that every lost point went directly to custom code would go further than the evidence.
Source gives Webflow another way to win the customer
If a business has chosen its own codebase and CMS, persuading it to replace both can be a difficult sale. Offering a better environment for the people already working on that stack is a different proposition.
Source lets Webflow pursue the latter. In our view, this is one of the most consequential parts of the announcement: Webflow can compete for the team's daily workflow even when it does not supply every part of the website.
The company has an understandable advantage to build on. Visual editing, collaboration, and making complex website work approachable are problems it has spent years addressing. Source attempts to carry those strengths into a world where agents work directly with code.
Code as the source of truth changes how a site can be maintained
Webflow's architectural explanation describes the existing Designer as working on a proprietary representation that compiles into browser code. Source's direction makes the actual code the authoritative artifact for visual editing and agents.
This is a question of where changes live.
Imagine a developer fixes a navigation component while a designer updates its visual source elsewhere. If the website is repeatedly generated from a separate representation, someone has to establish which version wins and whether the fix survives the next update.
Webflow already has a route for exporting React components through DevLink. Its developer documentation explicitly warns that a subsequent export overwrites manual edits to generated components. That makes the distinction concrete: having React output and maintaining React as the authoritative source are different workflows.
Source is addressing that architectural distinction. Its public materials do not establish every detail of conflict resolution or merging, so those behaviors still need evaluation on a real project.
For the website owner, the potential benefit is continuity. A component can be inspected, versioned, tested, and extended within the same engineering system. Designers and agents can contribute through interfaces that make sense for their work, while the implementation remains available to the people responsible for maintaining it.
That works best when the codebase has understandable boundaries. Reusable components, explicit content models, and a coherent design system give each change a place to belong. A repository full of unrelated generated pages still needs architecture. Our guide to component libraries for Next.js marketing sites explores why that structure matters after the first launch.
What Source's interfaces and agents are trying to solve
The Source product page describes moving between agent work and direct visual editing, turning canvas comments into tasks, and using Views for particular jobs. Views are dedicated surfaces within a workspace, rather than a requirement that everyone operate through the same prompt box.
Here is an illustrative campaign workflow, not a claim about a tested Source configuration.
A product marketer supplies the brief, audience, approved product claims, and launch date. A designer selects appropriate components and refines the composition. An agent helps assemble the first version. An engineer reviews the integration work. The accountable marketer approves the page before traffic reaches it.
The value comes from preserving the meaning of the work between those steps. A designer's comment should retain its visual context. A claim should retain its supporting source. A reviewer should understand what changed. A published page should remain connected to the decision that produced it.
Instructions, permissions, and approvals do different jobs
An agent may be permitted to edit a pricing page, instructed to use approved commercial information, and required to get approval before publishing. Those controls address different questions:
Instructions describe how the work should be done.
Permissions define what the agent can access or change.
Approval establishes who accepts a proposed change before it takes effect.
Good instructions alone cannot substitute for an enforced access boundary. Equally, access controls cannot tell an agent whether a headline is persuasive or a claim is misleading. The operating model needs both technical restrictions and informed review.
Useful context must stay current
Webflow's existing platform already documents persistent agent skills and rules, including references that resolve current components, variables, and CMS resources. Those are documented features of existing Webflow, rather than proof of Source's internal implementation.
The underlying lesson applies to any agent workflow. A direction to use the approved accent color is more durable when it refers to the actual design token. A direction to describe a product accurately needs a maintained product source. Copying old values into dozens of prompts creates another maintenance problem.
The website's context needs an owner just as its code does.
Faster changes need better evidence
Suppose form completions fall. An agent proposes a shorter headline and a brighter button. That might be worth testing. It might also miss a broken tracking event, a changed traffic mix, or a form integration that stopped delivering leads.
A useful recommendation should make the observation, time window, hypothesis, proposed change, and verification plan inspectable. Otherwise, the team can generate an impressive amount of activity without learning anything reliable.
This is the part of agent-assisted marketing that deserves scrutiny. The ability to produce an alternative is easy to demonstrate. The ability to choose a worthwhile intervention, preserve the measurement, and explain the result is a more demanding product test.
What this changes for a company planning its next website
Source's announcement strengthens the case for treating a website as a maintained system with a useful interface for each person who works on it.
That has consequences for the brief. A request for ten pages tells a team very little about how the website should operate. More useful questions are which pages share components, which content changes frequently, who approves claims, which integrations are essential, and who handles the next release.
This is where the announcement connects with the work we do at Raze. Brand decisions and engineering decisions affect each other throughout a project. A distinctive identity needs components that preserve it. A clear message needs a content model that allows it to evolve. A conversion path needs an implementation that actually delivers the enquiry.
Those decisions need to remain useful to the next marketer, engineer, or agent who works on the site.
How we use agentic web development at Raze
We use agents heavily in web development at Raze. They are part of how we work with code, and Source's direction makes sense to us because of that experience.
The attraction is practical. An agent can work with the components, styles, content models, and integrations already in a repository. A task can start with the website as it exists, rather than a blank page and a description of what someone hopes it looks like.
For a new campaign section, that means the working context can include the existing spacing system, approved typography, related components, and the CMS fields that will supply the content. For a change to a form, it can include the validation rules, submission handler, and destination for the enquiry. The more coherent that context is, the less a tool has to invent.
We still own the direction and the result. Choosing the right problem, deciding whether a design feels like the company, reviewing the implementation, and accepting what ships remain human responsibilities. A generated change is material to work with. It has to earn its place in the website.
This is why we care about the codebase the client receives. Agents become more useful when they can work on a system that is understandable and maintained. Clear components and documentation also make it easier for the client to bring in a different engineer or use a different tool later.
Source is betting on that same increase in code's usefulness. For clients, the question is how to turn it into a better website and a more capable team.
Brand still needs people with judgment
A well-configured agent can repeat a weak message with excellent consistency.
Before deciding how a website should produce more content, establish what the company wants to be understood for. Which buyer problem does it solve? What makes its approach credible? Which customer evidence can it use? What should the design communicate before a visitor reads the details?
At Raze, Mërgim leads positioning, identity, and visual design while Edin leads design engineering and technical delivery. Our brand and website work connects those decisions in the same engagement, so the production site grows out of the approved brand.
Consider a customer-story component. Its design has to make the evidence readable and convincing. Its content model has to distinguish a quote from a measured result and identify the person or company behind it. Its implementation has to work with a short story and a long one, with or without a portrait, on a phone as well as a desktop.
Those details define what a good instance of the component looks like. They give editors and agents useful boundaries while preserving a recognizable visual system.
Brand also involves choices that a pile of generated options cannot settle for you. Which audience are you prepared to disappoint? Which claim can the business defend? Does this visual direction express who the company is, or just resemble the last ten websites the team liked?
People have to make those calls with an understanding of the business and its buyers. AI can help explore and execute a direction. The founders, designers, and strategists still need to recognize the right one and take responsibility for it.
Our position is simple: as production gets faster, human judgment matters more to the result. Typography, composition, voice, proof, and the details of an interaction determine whether the site feels considered. Generating more pages with interchangeable claims does not create a stronger brand.
The practical foundation: owned code and a CMS the team can use
Our usual website stack at Raze is Next.js, React, and Tailwind, with content management selected around the client's workflow. Options include Sanity, Contentful, Prismic, and headless WordPress. The point is to give the site a maintainable implementation and the team a workable publishing process.
A custom codebase lets us define how the system behaves. The project can have reusable sections, explicit routing, tested integrations, and a version history that another engineer can understand. That is the foundation of our website design and development approach.
The CMS handles the content decisions the team needs to make repeatedly. Choosing one starts with actual work: who edits a case study, whether pages need localization, how previews are reviewed, and which changes require approval. Our headless CMS guide goes into that workflow in more detail.
Define a complete publishing path
For an integration page, for example, a workable content model might include the integration name, supported use cases, setup requirements, verified limitations, product images, and a next step. The frontend should know how to present those fields consistently.
Before publication, the editor needs a preview. The page needs its URL, metadata, internal links, and any appropriate structured data. If the page contains a form, the submission has to reach the intended destination. After publication, the owner needs a way to see whether the page is being visited and used.
An agent can help with several stages. The publishing path still has to exist.
Make portability specific
The client should receive the agreed source files, repository, access, and documentation needed to operate the website. Those are part of Raze's published ownership commitment, and they should be explicit in any project scope.
That still leaves dependencies to understand. A CMS has a content model. A host may provide proprietary services. An integration can depend on an account the company needs to control.
Next.js documents running an application on a Node.js server or in Docker. A move between providers still requires checking caches, assets, environment configuration, and any provider-specific behavior. Owning the code gives you choices; documenting the dependencies makes those choices practical.
Keep performance inside the release process
Every new campaign can introduce another video, font, script, or interactive section. Agents can add those just as quickly as people can.
A useful performance budget identifies what the team is prepared to ship and how it checks the result. A rich hero can be appropriate, but it needs responsive assets, sensible loading behavior, and a clear reason to exist. The same goes for analytics and experimentation scripts.
Our Next.js performance-budget guide covers that discipline. Generation speed should be accompanied by a reliable way to assess the experience a visitor receives.
Agents building your website are only one side of the change
There are also agents arriving at the website on a buyer's behalf.
An internal agent might help your team update a service page. A buyer's assistant might read that page to understand the offer, compare it with another option, or help the buyer take the next step. Those are different jobs, with different permissions and information needs.
The first job needs access to the working system. The second needs accurate public information and a usable path through whatever actions the company supports.
At Raze, we optimize for both. We use agents to help build websites, and we design websites so a buyer's agent can interact with the business: understand an offer, check relevant details, make an enquiry, book, or buy through a supported integration.
This is another area where the design and engineering need to meet. The website still has to make a clear, credible impression on a person. Its content also needs enough structure and evidence for an assistant to interpret it without guessing. We explore that relationship in our guide to designing agent-ready websites.
Raze's own site provides a concrete example. Our agent connection guide describes a public MCP connection for reading services, projects, and booking information, checking availability, and booking after explicit visitor confirmation. A compatible client must connect and enable the tools; the website cannot silently install itself into every assistant.
Our agent-ready website work starts by deciding which information and actions justify that infrastructure. It requires real data, defined inputs, sensible failure behavior, and approval where an action changes something.
Give a buying agent a complete path to purchase
Consider a store whose customer asks an assistant to find a particular product and buy it within an agreed budget. A useful website needs to expose the product's actual variants, current price, availability, and relevant delivery or return information. The assistant then needs a supported way to prepare the order, obtain the buyer's authorization, and complete payment through the store's checkout system.
The outcome must be unambiguous. The order succeeded and has a reference, the item became unavailable, or the payment failed. Retrying a request should not charge the buyer twice. Those details belong in the implementation and the acceptance criteria.
That is the kind of workflow we design agent-ready sites around, according to the business and its existing commerce systems. A service company might need a confirmed booking instead of a cart. A SaaS business might need a plan comparison and an authorized signup path. The useful action comes from the business model.
The human experience still has to earn trust
A person may discover the company, ask an assistant to investigate it, then return to the site before committing. The brand, customer evidence, and interface still influence that decision. Building a usable agent path adds another way to become a customer while preserving the experience that makes someone want to be one.
Discovery is a related, separate job. Through AI Search Visibility, we work on content, citations, and technical structure that help systems understand and evaluate a company. A functioning tool endpoint does not guarantee that an answer engine will recommend the business. That requires its own evidence and measurement.
Source's arrival makes this wider shift easier to see. The website increasingly has to support people and software on both sides: the team maintaining it and the buyer using it.
If you already use Webflow, start with the constraint
A new platform announcement should prompt an assessment of the current system before it prompts a rebuild.
If the site works well and the team can publish what it needs, continuing to improve it can be a sensible decision. Webflow's Source announcement says the existing platform will continue receiving investment, with a supported path planned for customers who choose Source later.
If the team is already fighting its architecture, identify the specific problem. It might be a content-model limitation, complex application behavior, an awkward integration, or repeated difficulty testing changes. Then establish what the replacement needs to preserve.
A Webflow export alone will not carry the whole operating website into a new stack. Webflow's export documentation lists exclusions including CMS functionality and secondary-locale content; forms and site search also require attention. Those are existing-builder export constraints, not claims about Source.
Raze's Webflow-to-Next.js migration service addresses the components, content, URLs, integrations, and launch behavior that need a destination. The technical migration roadmap explains the work involved. For teams using coding agents in that process, our Claude Code migration guide covers how to keep the rebuild tied to the system being replaced.
After launch, someone still needs to own improvements. Raze's Embedded Partner model keeps the same senior design and engineering team involved as the brand, content, and website evolve. New tools can then be assessed against a maintained system and a clear business priority.
Questions worth answering before adopting Source
The most useful preview evaluation is a real piece of work with clear acceptance criteria.
Choose a shared component change or a content page with an external integration. Inspect how the work is proposed, how its context is retained, who can approve it, and what happens if the result needs reversing. Include the marketer who will use the system regularly.
Ask which parts of the codebase and services are supported today, how custom Views are maintained, what remains available outside the workspace, and how the team retrieves its content and configuration. Source-specific pricing and a general-availability date were not listed on the public pages reviewed on September 3, 2026.
Webflow's agency model for Source includes configuring client workspaces and agents, and creating reusable Views. That gives agencies another potential deliverable. It also leaves a familiar responsibility: the client needs to understand who owns, maintains, and can change the system after handover.
Webflow Source questions, answered
Is Webflow Source available now?
Source is in a limited research preview as of September 3, 2026. Webflow is enrolling selected customers and agency partners. A generally available release date and Source-specific public pricing were not listed in the materials reviewed.
Does Source require Webflow hosting or Webflow CMS?
Webflow says Source can connect to an existing codebase, CMS, marketing tools, and hosting. Compatibility with a particular project still needs checking during evaluation.
Is Webflow losing market share to custom code?
Ramp reports falling Webflow adoption share and rising Vercel adoption in the same purchasing category. W3Techs reports a small decline in detected Webflow website usage but flat known-CMS share. These signals support competitive pressure; they do not establish how many customers migrated from Webflow to custom codebases.
Does having source code eliminate lock-in?
Source ownership makes a website easier to inspect and maintain with other tools or partners. Portability also depends on the CMS, hosting services, assets, integrations, configuration, and documentation. Those dependencies should be assessed as part of the implementation.
Does Source make designers and engineers unnecessary?
The proposed workflow still involves decisions about positioning, design, content, architecture, approvals, and measurement. Agents can help execute the work. People still need to define what a good result looks like and accept responsibility for what ships.
The part of this bet that matters most
Webflow is responding to a change in how websites are made. Code is becoming more accessible, and the company can no longer assume that abstracting it away will be enough to win the next project.
Source is a serious attempt to make its visual and collaborative strengths valuable in that environment. Its success will depend on the ordinary work after the impressive first demo: publishing a page, reviewing a change, maintaining a component, and knowing whether the result helped.
For a business planning its next website, the durable investment is the foundation underneath those tools: a clear brand, maintainable code, a usable content system, trustworthy measurement, and the ability to choose who works on it next.
If that is what your current site is missing, talk to Raze about the brand and website you need.
