If building pages gets easier, what exactly are you selling?

The prospect who was going to try it themselves first

A prospect told a Webflow agency I know that they were going to have a go at building it themselves with an AI tool before commissioning anybody. The agency owner did not lose the deal over it and he did not panic. What he wanted to know was whether that prospect was an outlier or the start of something.

He asked while his pipeline was full, which is the right time and almost never when the question gets asked. The answer is that the prospect was probably not an outlier and also not the threat.

That is the right time to ask it, and the answer I gave him is the argument here. The prospect was probably not an outlier, and also not the threat. The threat is older and duller than any tool: an agency whose only unit of sale is a finished site is exposed to anything that makes finished sites cheaper, and that has been happening steadily for fifteen years.

What is genuinely getting cheaper

It is worth being specific rather than gesturing at disruption, because the specifics tell you what to do.

Producing a page from a design is cheaper than it was, and has been getting cheaper continuously through templates, component systems, no code builders and now generation. Each step was real.

Producing a design from a reference is cheaper. Turning content from one format into another is cheaper. Writing a first draft of copy is cheaper. Building a small interaction that used to need a developer is cheaper.

What has not moved: deciding what the site should say, deciding which pages should exist, knowing what a specific client's buyers ask before they buy, and keeping the whole thing correct after launch. Those have got harder if anything, because there are now more pages to keep correct.

Look at that split and the strategy writes itself. The exposed part of the business is the part that got cheaper. The defensible part is the part that did not, and most Webflow teams already do it and charge nothing for it.

There is a second order effect worth naming. When production gets cheaper, clients produce more, which means more pages exist that need to stay correct. So the same shift that compresses the value of build hours expands the value of the work that comes after. That is not a consolation, it is the actual opportunity, and it is available to exactly the people whose build revenue is under pressure.

What Webflow teams should keep

I want to be clear that this is not an argument to become something else. The teams that get into trouble in transitions like this are usually the ones that abandon a working business to chase a new category.

Keep the craft. A genuinely well built Webflow site, with a sensible CMS model, a component system somebody can use, and clean output, is not a commodity and generation does not produce one. Anybody who has tried to take generated output and turn it into a maintainable site knows the gap.

Keep the platform depth. Knowing what Webflow can and cannot do, where the CMS limits are, how to structure collections so the site survives a rename, how interactions behave on real devices. That knowledge takes years and it is the thing clients cannot verify in advance and rely on completely.

Keep the delivery reliability. Shipping on a date, to a standard, with a handover that works. Unglamorous, hard, and the actual reason most clients stay.

None of that is at risk. What is at risk is selling only that, priced by the hour, with nothing attached before or after.

What to add

Four capabilities, ordered by how close they are to what a Webflow team already does. None of them requires hiring a different kind of person to start, though all of them eventually reward it.

Content structure. Deciding which page types exist, where each fact authoritatively lives, and how the CMS model survives a product rename. Most Webflow teams already make these decisions implicitly during a build. The move is to make them explicit, write them down, and charge for them as a deliverable.

Website operations. The recurring practice of noticing what is wrong and fixing it, reported as changes against named pages rather than hours. This is the largest opportunity and it is mostly already being done inside support retainers at the wrong price.

Listening. A route from the client's sales and support conversations into the site. This is the capability that most changes what you can charge, because it turns you from somebody who executes requests into somebody who brings the request.

AI operations. Not generating pages. Using these systems for what they are good at on a site you look after: finding contradictions across pages, checking that structured data still matches content, drafting against a decision somebody already made. That is a genuine efficiency and it is invisible to the client, which is fine.

A note on sequencing that matters more than the list. Do not try to add all four. Pick one, sell it to one existing client who trusts you, and find out what it actually costs you to deliver before you put it in a proposal. Every agency I have watched do this successfully added one capability to one client first. Every one I have watched struggle announced a new service line and then had to build it under deadline pressure with a paying customer watching.

A capability map

This is the version I sketch when an agency owner asks where to start. The first column is what most Webflow teams have. The middle is what is worth adding. The last column is the honest note on difficulty, because two of these are much harder than they look.

Read it as a sequence rather than a menu. Content structure first, because everything else depends on the site being modelled so that changes are cheap.

The two hard ones, and why they are worth it

Listening is the hardest and it is the one that changes your position most. It requires a client who will let you sit in on sales conversations or read their support inbox, which requires trust you probably have and have never asked to use.

The reason it is worth the awkward request is that it inverts the relationship. An agency that executes requests is a supplier. An agency that arrives saying your sales team answered this question eleven times last quarter and there is no page for it is something else, and the difference is visible in how the renewal conversation goes.

AI operations is hard for a different reason: the judgement is about what not to automate. Using a model to find every page that mentions pricing is excellent. Using one to write the pricing page is a decision that needs a person who understands the client's commercial position. Teams that get this wrong in either direction lose, and there is no rule that decides it for you.

Both of these are genuinely difficult and I would rather say so than present a four step plan that implies otherwise.

An agency that executes requests is a supplier. An agency that brings the request is something a client cannot replace easily.

What this does to how you hire

Worth thinking about before the work arrives, because the profile that is most valuable changes.

The person who is best at building a page fast is not necessarily the person who is best at noticing that a client's pricing page contradicts their product. Those are different dispositions, and the second one is closer to curiosity about somebody else's business than it is to craft.

In practice the operations work suits somebody mid level with good judgement and an interest in the client, more than it suits your strongest builder. That is useful because your strongest builder is expensive and their time is better spent on the build work that still commands a premium.

It also changes the shape of the week. Build work is lumpy and schedulable. Operations work is smooth and interruptible, and the two do not share people well. A fixed block on named days works. On demand does not.

The other change is what you look for in a first conversation with a candidate. For build roles, you look at what they have made. For operations roles, the more predictive question is whether they get curious about a business they have just heard about. That is harder to interview for and it is the thing that determines whether they will notice the pricing page contradiction that nobody asked them to look at.

What Webflow is doing, and why it does not change the argument

The platform is adding capability in this direction too, as any platform would, and it is reasonable to ask whether that closes the gap.

I do not think it does, and the reason is structural rather than about any particular feature. A platform builds tools that work for everybody on it. The judgement about which page a specific client should fix next depends on that client's buyers, their sales conversations and their commercial position, and none of that is visible to a platform.

This is the same reason the app layer stopped short for us. A tool acts when somebody who already noticed a problem opens it. Noticing is the part that requires knowing the business.

So the capability the platform adds makes the execution cheaper, which is the direction everything has been moving anyway, and leaves the judgement where it was. That is a good outcome for a team whose value is judgement and a bad one for a team whose value is hours.

Where teams get this wrong

Abandoning the build business. The build is still the way you get in, it still pays, and it is where the trust comes from. Adding a practice is not the same as replacing one.

Rebranding without changing the unit. Calling a maintenance retainer an operations retainer changes nothing if the report still lists hours. The change record against named pages is the whole product.

Waiting for a full pipeline to empty. The right time to build the second capability is while the first one is busy, which is exactly when nobody wants to. The agency owner who called me had a full pipeline, which is why he was asking at the right moment.

Chasing the AI positioning. A Webflow team advertising AI capability without a specific thing it does for a specific client is competing on a claim anybody can make. Contradiction checks across a client's site is a specific thing. AI powered web design is not.

Treating platform depth as a commodity because it feels routine to you. Clients cannot evaluate it and rely on it completely, which is close to the definition of something worth charging for.

What good looks like in two years

A Webflow team that has made this transition does not look dramatically different from the outside. It still builds sites and the sites are still good.

What is different is the shape of the revenue and the shape of the conversation. A meaningful share of income is recurring and is priced on judgement rather than hours. Clients bring problems earlier because the team is already looking at the site. Proposals name pages rather than describing activity. And when a prospect says they will try building it themselves first, that is a conversation about the year afterwards rather than a lost deal.

The internal tell is smaller. Somebody on the team can tell you which client site is currently wrong, and what they are doing about it, without checking.

Why we are saying this rather than keeping it quiet

We spent six years doing Webflow delivery, a good share of it white labelled behind other agencies, and then built four Designer apps. Everything above is the transition we are in the middle of rather than one we completed and are reporting on.

Creogen is the operations layer we are building for it, and Creobot is the listening half. Both are in private development and open to agency partners first, which is a deliberate choice rather than a marketing one: agencies are already doing this work, and they will find out faster than we will where the tooling is wrong.

The reason for writing this publicly rather than treating it as positioning is straightforward. If you run a Webflow team and this argument is familiar, the conversation is more useful to us than the pitch is. And if it is not familiar, the capability map costs nothing to try and does not require anything of ours.