Flowdrive

A Webflow developer builds audio testimonials for a client. Webflow will not host an mp3, so he uses the workaround the community had settled on: rename the mp3 to .txt, upload that, point a player at it. Webflow accepts it. It plays. He ships and invoices.

Then the client opens the site in Safari and hears nothing.

The workaround is not missing. It exists, it is widely shared, and it fails silently in one browser after the invoice has gone out. The cost is not effort — it is the developer's credibility with their client.

Webflow caps uploads at 30MB, restricts which types you can upload at all, and has no native audio or video hosting. Background video carries no audio. A CMS video field takes a YouTube or Vimeo link, not a file.

Before building I wanted to know whether this gap would close on its own. My read was that it would not: storage and bandwidth are a direct cost to Webflow, and file hosting loses the prioritisation argument every quarter because it does not drive their revenue.

That is the reframing that made this worth building. A missing feature ships eventually and your product evaporates. A structural constraint stays open — the same opening Finsweet, Flowbase and Slater were each built into.

Early in my career I was the only designer on a team building a community product. I believed design was UI. My research was a competitor scan and tests built on questions like would you use this? Everyone said yes. We shipped to the App Store. Nobody used it. The runway ran out and I was let go, phrased as a pause rather than a layoff.

I had read those yeses as validation. They were politeness. A question that contains its own answer collects agreement, not information.

What I did next matters more. I opened my following role by naming that failure and asking for a research budget before accepting the work — and got one. That product is still live, with paying customers and enterprise integrations.

The guide I used for Flowdrive

The rule is the Mom Test: if your mother would say yes to the question, the question is broken. So every question below is about something that already happened, and the product is never mentioned until the problem has been described without it.

Reconstructed in September 2026 from the method described in the recording above. I do not run surveys for this — a survey is a leading question you cannot follow up on.

The Widening questions are where the product changed. People were not blocked on uploading — most rarely uploaded anything. They were blocked on video: pushed onto YouTube or Vimeo, wearing someone else's player, often onto a paid plan to remove it.

I set out to build an upload widget. The interviews turned it into a delivery product, and video is still the majority of what Flowdrive serves.

Did the finding hold?

A finding from a handful of interviews is a hypothesis. What made me trust this one is that customers kept arriving at it unprompted, in public, describing the same problem in the same terms — including the detail I would have been least likely to invent, that people actively did not want to use Vimeo.

Two of these did more than confirm the finding. Customers independently reported trying S3 or AWS and abandoning it as too complicated, which is the conclusion I reached from the other direction when choosing where to store the bytes. And the pattern Evgenii names — that the bill arrives precisely because a site is doing well — became the premise of the pricing decision further down: bandwidth pricing punishes the customers succeeding most.

The finding above cost me a rebuild. I had shipped the first version in two weeks, and because it grew out of a single client request — let my visitors submit files — it was built around uploading. The interviews said uploading was the smaller job.

I can show that reframe rather than assert it, because the product named the job in its own headline three times and changed its mind twice.

01 · First release Upload

Headline: “File upload for webflow in minutes”

What moved it on: Usage. Uploads were in the thousands while video requests were in the hundreds of thousands. The feature I had led with was not the one being used.

02 · Second framing Hosting

Headline: “File hosting for webflow in minutes”

What moved it on: Still too broad. “Hosting” describes what the software does, not the moment someone arrives in trouble — and nobody searches for a hosting layer at 1am.

03 · Today Video

Headline: “The easiest way to host videos and files on Webflow”

Video leads and files follow, which is the order the interviews found and the order the traffic confirmed. The number that settled it was my own:

What the first app got wrong

The framing was not the only thing that was off. Putting the first file screen beside the current one shows the decision that took longest to see: in version one, the URL — the single object the entire product exists to hand over — was an unlabelled icon.

The conceptual model in the next section is what I should have designed to from the start. I arrived at it by watching people fail to find a copy button.

What I promised before I built it

One more thing worth admitting, since the point of shipping in two weeks was to find out whether anyone wanted this at all: the first version went live with duplicate placeholder copy under all three feature columns, and a testimonial credited to “Definitely Someone :)”. It was not ready. It was live, which was the only property that mattered that month.

Every decision below follows from one model. A Webflow user already understands elements and sites. Flowdrive introduces exactly two new objects — a file and the URL it resolves to — and the URL is where the new part hands off to the part they already know.

Each could have gone the other way, and each closed something off. The costs are listed because a decision without a cost is a feature announcement.

The signal came from a professional Webflow developer who had already hand-built his own audio element, and did not know these existed:

One boundary I held deliberately: the Flowdrive script tag is required only for the upload widget. Hosting and playback need nothing injected into the page — which is why moving files to Flowdrive shows up as a Lighthouse improvement rather than a regression.

Upload was the original client request, and it had the hardest audience problem in the product: the same feature has to serve someone who has never written JavaScript and someone wiring it into existing Webflow form logic. Rather than build two features or pick a side, I made it a ladder — each rung works alone, and you only climb if the rung below does not fit.

The third rung is the one I am most pleased with. It resists the instinct to own the whole form: by writing into a field the user already built, Flowdrive stays a component inside their system rather than replacing it.

Three changes came from users rather than from me. The third column is the one worth reading — shipping a request is not the end of the loop.

Flowdrive was working. Agencies and brands were on it and I had been talking to the Webflow team. I was pushing an update and meant to clear my test assets. The configuration was pointed at production. I pushed.

Backups existed but were not sufficient. I recovered some. Most were gone.

I told every user immediately — before they noticed, and before I knew how bad the recovery would be. Then I built a path to replace an asset without re-uploading, so a URL already embedded across a live site would keep resolving once the file was restored.

That fix helps someone with fifteen videos. It does little for someone with six hundred files. And it helps nobody whose files arrived through the upload widget — those were submitted by their end users, so they were never my customer's to re-upload. Recognising which class of user a fix cannot reach was the most useful thing I did that week, and the least satisfying.

Customers who had paid since day one cancelled the plan and the emails. For a week I got messages daily asking whether they had done something wrong, each answered with: no, it was me.

The actual root cause

The proximate cause was a configuration flag. The real cause was upstream: I was rushing the release because I believed I needed a shipped feature before I was allowed to market anything. That habit put me in a hurry next to a destructive operation. Fixing the deploy process without fixing the belief would have left the same accident waiting.

The soft-delete window matters beyond my own accident: it means a customer’s own mistake is survivable too.

• Role-based access in the first version. Shipping collaboration where every invited person can delete everything was a decision by omission — the kind a customer discovers instead of me.
• Soft delete before scale, not after. Recoverability is not a feature you add once you have something to lose. It is the cost of storing other people's work at all.
• Make destructive operations name their target. The accident was possible because a flag could quietly point at production. A destructive action should require typing the environment it affects — a design problem in my own tools I had never treated as one.
• Give the code editor its own model. It is still wearing the file host's file tree. The people using it most are served worst by the interface they were handed.

The first of those was asked of me in public, at launch, and I did not have a good answer:

It is on the testimonials page rather than buried, because a question I could not answer is more useful to me than another compliment — and because the access model it points at is still the weakest part of the product.

Flowdrive serves more than 70 million requests a month. It is live at tryflowdrive.com, on a free tier, if you would rather use it than read about it.

Markdrop, StudioDuo, StayNorth and Ben Bites — the other products and client engagements, each with the role I held and what it changed.