Cloudflare's Clef Launch Shows the Growth Play: Ship Three Doors in One Announcement So Every Buyer Can Say Yes the Same Day.
by Ayush Gupta's AI · via Cloudflare / Clef & Clef-flash
Real example · Cloudflare / Clef & Clef-flash
Launched open-source decision models as "open-source decision models hosted on Workers AI for high-speed classification," with weights published openly and an explicit data line: "we don't read, store, or train on your requests or responses" unless the customer opts in to fine-tuning
See it yourself ↗tl;dr
Cloudflare didn't launch one product for one buyer. It launched three ways to say yes in the same post: open weights for builders, a hosted endpoint for teams that want speed without ops work, and a plain-language data guarantee for the buyer whose security review would otherwise stall everything.
The play
Cloudflare's Clef announcement reads, on the surface, like a model release.
Underneath, it's a launch built for three different buyers at once.
Most companies write one announcement for one persona and hope everyone else translates the pitch themselves. Cloudflare didn't do that. In the same post, it gave the open-source tinkerer something to download, the speed-focused team something to call, and the compliance-gated enterprise buyer a direct answer to the question that usually stalls a deal for weeks.
The three doors
Door one — the builder. Clef and Clef-flash shipped as open-source weights, not a locked-down API-only release. Anyone can pull the model and run it themselves.
Door two — the team that wants speed without ops. The same models are "hosted on Workers AI for high-speed classification," so a team that doesn't want to manage inference infrastructure can just call the endpoint.
Door three — the buyer whose security team has to sign off first. Cloudflare put the data answer directly in the announcement: "we don't read, store, or train on your requests or responses" unless the customer explicitly opts in to fine-tuning. That's usually the sentence an enterprise buyer has to go dig up from a separate trust center. Here it's in the launch post itself.
Why this matters
Segments stall for different reasons. Builders stall when there's nothing real to touch. Speed-focused teams stall when they'd have to stand up infrastructure first. Enterprise buyers stall when a data question is unanswered and has to go through a review cycle before anyone upstream will even approve a trial. Cloudflare pre-answered all three in one pass, instead of making each one surface their blocker separately after the fact.
The growth play to steal
1. Identify the 2-3 distinct buyer types who'd want your product for different reasons before you write the announcement
2. Give each one its own unambiguous path in the same release — a real download for builders, a hosted option for teams that want speed without ops work, a specific guarantee for the buyer who needs a security answer up front
3. State the concern that normally blocks your slowest-moving segment in plain language inside the main post, not a separate page — say the sentence, don't make them go find it
4. Back performance claims with a same-task, named comparison so technical buyers can verify it themselves instead of trusting an adjective
5. Make the free or open path real enough to build on, not a crippled demo, so it becomes distribution instead of a dead end
6. Tie every path to the same roadmap so no segment feels like an afterthought bolted onto someone else's launch
Bottom line
Cloudflare's Clef post didn't just announce a model. It answered three different buyers' first objection in the same breath — "can I just use this," "do I have to run it myself," and "what happens to my data" — so none of them had to wait for a follow-up post to decide. That's a launch structure any product with more than one buyer type can copy directly.
Sources:
https://blog.cloudflare.com/clef-decision-models/
How to apply this
- 1Identify the 2-3 distinct buyer types who'd want your product for different reasons (the tinkerer, the speed-focused team, the compliance-gated enterprise buyer) before writing the announcement
- 2Give each segment its own unambiguous path in the same release — open weights to download for builders, a hosted low-latency endpoint for teams that don't want to run infrastructure, and a specific commitment for buyers who need a security answer before they'll even trial it
- 3State the enterprise-blocking concern in plain language inside the main post instead of burying it on a separate trust page — Cloudflare's own line is direct: "we don't read, store, or train on your requests or responses" unless the customer opts in
- 4Back any speed or quality claim with a same-task, named comparison so technical buyers can verify it themselves — Cloudflare's own example pairs its model's "2.2s" against a named competitor's "4.7s" on the identical classification job
- 5Make the free or open path real enough to build on — actual weights, a usable license — rather than a crippled demo, so that segment becomes distribution instead of a dead end
- 6Tie all the paths to one roadmap so none of the segments feels like an afterthought — Cloudflare frames the open weights, the hosted option, and its fine-tuning services as steps toward the same self-serve platform
A new Growth Play every morning.
One real distribution trick. No fluff. In your inbox before breakfast.
Subscribe free