We built four apps before we noticed they were all the same app

Four apps, built for four unrelated reasons

We started building Webflow Designer apps because clients kept asking for the same repetitive things and doing them by hand was making the delivery work worse. Each app came out of a specific irritation rather than a strategy.

Assetflow came from alt text. A site would arrive with a few hundred images and no alt text on any of them, usually because the images were added at speed by different people over two years. Writing alt text for four hundred images is a task nobody has ever wanted.

Attriflow came from attributes. Somebody needs to change one custom attribute across ninety CMS items, and the interface is built for editing one item well.

HTMLtoflow came from getting content in. Somebody has content that exists as HTML somewhere else and needs it inside Webflow with the structure intact, and that boundary is where structure reliably gets lost.

AI CMS Helper Text came from confusion. A collection has fourteen fields and the person filling it in was not there when it was designed, so half the fields get used for something other than what they were for.

Four irritations, four apps, no connecting theory. We shipped three publicly and kept the fourth internal.

What Webflow is actually good at

It matters to be clear about this before the rest of the argument, because the observation that follows is easy to misread as a complaint.

Webflow is a genuinely good tool for building a website. The visual model maps onto how the web actually works rather than hiding it, the CMS is properly relational, the output is clean, and the gap between what a designer draws and what ships is smaller than in most alternatives. We built a business on it for six years and would choose it again.

It is also a building tool, which is what it says it is. It is optimised for producing a site and for editing that site page by page, and it does both well. Nothing in this article is a shortcoming of Webflow. The apps exist because a building tool and an operating tool are different things, and every platform in this category has the same shape.

The thing all four had in common

We noticed it properly while building the fourth one, which is later than we should have.

Every one of the four acts across a whole site rather than on a page. Alt text on four hundred images. An attribute across ninety items. A whole document's structure preserved across a boundary. Every field in a collection.

And every one of them is remediation. None of these tasks would exist if the thing had been done correctly at the point it was created. Alt text should have been written when the image was uploaded. The attribute should have been set when the item was made. The field should have been documented when it was designed.

So each app is a bulk fix for a failure that happened slowly, one reasonable decision at a time, across a site nobody was watching. That is not four problems. That is one problem, arriving in four costumes.

Every app we built was a way of catching up with a site that had got ahead of the people responsible for it.

App layer thinking against operations layer thinking

Once the pattern was visible, the difference between what we had been building and what the problem actually needed was easier to state.

The distinction is not about capability. Several rows below are things an app could technically do. It is about what the tool is responsible for and when it runs, and those two properties change everything downstream.

The row that mattered most

Who initiates is the row that changed what we decided to build.

Every one of our apps requires somebody to already know there is a problem. You open Assetflow because you know the alt text is missing. Nobody opens it speculatively.

Which means the app is only useful to a team that is already paying attention, and the teams that are already paying attention are not the ones whose sites decay. The tool was reaching the people who needed it least, and that is not a marketing problem, it is a design consequence of building at the app layer.

The failure that produces most of the damage on a website is nobody noticing. A tool that begins after somebody notices has, by construction, skipped the part that fails.

What each app taught, specifically

Retrospectively, each one was a finding about where website teams struggle, and none of us treated them as findings at the time.

Assetflow taught that accessibility work is real, valued, and owned by nobody. It gets done in a burst before a compliance conversation and then stops, because the route by which a new image gets alt text at upload time does not exist. The remediation is popular and the prevention has no owner.

Attriflow taught that the CMS shapes what is easy, and cross cutting change is the thing every CMS makes hardest. Per item editing is well supported. Change one thing across ninety items and you are outside the interface's assumptions. That is a data model observation dressed as a tooling gap.

HTMLtoflow taught that boundaries are where structure is lost. Content crossing from one system to another arrives with its meaning flattened, and somebody has to rebuild it by hand. That is the same failure as generated content arriving without structure, which we did not connect at the time.

AI CMS Helper Text taught the one I think about most. People fill in fields without knowing what the fields are for, because the model is not self documenting and the person who designed it has moved on. Every wrong value in a CMS was typed by somebody being reasonable with insufficient information.

The connecting thread, stated once because it is easy to miss across four examples: in every case the failure happened at authoring time and was discovered at audit time, and the gap between those two moments was measured in months. Everything we are building now is an attempt to shorten that gap rather than to make the audit faster.

Why the apps do not add up to the thing

The obvious move from four apps is a fifth app, or a suite. We considered that seriously and it does not work, for a reason worth stating plainly.

Four tools that each act on request produce a team that has four more things to remember to open. The cognitive load does not reduce, it fragments. And none of them addresses the initiating problem, which is that nobody knew there was anything to fix.

The other reason is that the interesting information in each app is thrown away. Assetflow knows which images had no alt text. Attriflow knows which attributes were inconsistent across a collection. Neither records it anywhere, because a task tool has no reason to keep state after the task is done. Every run of every app was a free audit of somebody's site and we kept none of it.

That is the specific realisation that pointed at a different kind of product.

There is a commercial version of the same point that took longer to accept. Apps in a marketplace are bought by individuals for a specific task at a low price, and the buying decision is made in about ninety seconds by somebody solving today's problem. An operations product is bought by somebody responsible for a site over years, and that is a different buyer, a different conversation and a different price. We spent a while trying to reach the second buyer through the first product, which does not work regardless of how good the product is.

What we are actually building now

Creogen is the operations layer: findings tied to specific URLs, a record of what changed and why, an expectation written before a change and checked afterwards, and a way to notice that a page has not been looked at in a year. Creobot is the input side, collecting the questions visitors ask that no page answers, so the site has somewhere to hear from.

Both are in private development. Neither is finished and I am not going to describe them as more mature than they are, because the argument in this article is about what we learned rather than about what we have shipped.

What I will say concretely is what changed in how we build. The identity model came first, before any editing capability, because the apps taught us what happens when a change breaks something nobody recorded a dependency on. The record of what changed came before the ability to change things. Both of those orderings are the direct result of having built the app layer first and seen where it stopped.

What this means for the apps

Three of the four are public and installable today and they continue to work. We are not deprecating them and there is nothing clever behind that decision. They solve real tasks and people use them for those tasks.

It is worth saying plainly that the apps were also how we learned to build software as a company rather than as a delivery shop. Client work teaches you to finish things. Shipping a product to strangers teaches you what happens when somebody uses it in a way you did not anticipate, at a volume you did not plan for, and then writes to you about it. Those are different skills and the second one is the one an operations platform needs.

What has changed is that we no longer think of them as the product direction. They are useful tools and they were, more importantly, six years of field research that we did not know we were conducting.

If you are building on the Webflow platform, that is the transferable part. Pay attention to what your users are asking your tool to fix. The pattern in the requests is usually more valuable than the feature that satisfies them, and it is available for free to anybody who is looking.

Where teams make the same mistake

Building the next tool in the sequence. Each individual request is reasonable and each tool is justifiable, and four of them can still add up to a suite that avoids the actual problem.

Treating remediation demand as product validation. High demand for a bulk fix is evidence that something upstream is broken. It is real demand and it is also a symptom, and the two get conflated because one of them is easier to sell.

Discarding the diagnostic exhaust. Every tool that fixes something knows what was wrong before it fixed it. Most tools throw that away, and it is often more valuable than the fix.

Waiting for a strategy before noticing a pattern. We had the pattern in the first app and did not see it until the fourth. Nothing prevented us from seeing it earlier except that we were not looking across our own work.

How to tell which layer you are working at

Three questions, and they apply to any tool in this space rather than only to ours.

If a tool answers app layer to all three, that is fine and it should be honest about it. The problem is only when an app layer tool is sold as an operations answer.

Where this leaves us

Six years of Webflow delivery and four apps taught us that the hard part of a website is not building it and is not editing it. It is that the site keeps existing after everybody has moved on to the next thing, and it is nobody's job to notice when it stops being true.

Webflow is not the reason for that, and no building tool is. It is a consequence of how websites are funded and staffed, and it will be there whatever platform you choose.

We are building for that gap now, in the open enough that the reasoning is on this site rather than in a deck. If you run an agency and this pattern is familiar, the conversation is more useful to us than the pitch is, which is why the apps are still free to install and the products are not ready to sell.