Building an AI tool and getting anyone to use it are separate jobs. In a first-person DEV Community account, a builder named Oleksandr says he deployed 35 MCP servers in 10 days, added two payment-gated services and a Google Sheets add-on, yet had no active users and no revenue at the point he described. His experience is a useful case study in a gap that payment options alone cannot close: distribution.
What the builder deployed—and what happened next
Oleksandr’s account describes 35 MCP servers covering tools such as validators, parsers, extractors and domain-specific utilities. He also reports building two Cloudflare Workers—an HS Codes Classifier and a Document-to-JSON tool—with x402 payment gates, settling payments in USDC on Base.
As an Amazon Associate I earn from qualifying purchases.
For the classifier, he added a Google Sheets custom function, =HSCODE(A2). The add-on called the same Worker and cached results locally, according to his account. The idea was to let spreadsheet users try the tool without first configuring an API or an MCP client.
Despite saying the services were configured and responding, Oleksandr reported zero active users and zero revenue at the time of writing. Those figures describe one builder’s experience, not a general measure of MCP adoption or proof that marketplaces or agent payments cannot work. The source is DEV Community’s October 5 account; its search result does not specify the year, and its implementation details and metrics are not independently audited.
#1 Best Overall
Three monetization models, with different trade-offs
The author describes offering free access, a marketplace subscription and pay-per-call pricing. He says these could coexist on a server, citing an IBAN validator as an example. The terms below are the author’s article-time claims, not verified current offers.
| Model | Reported terms | What it asks of the user | Revenue pattern |
|---|---|---|---|
| Free tier | 50 calls per day per server | Try the service without paying, subject to the daily limit | Trial access does not itself generate revenue |
| Marketplace subscription | Pro tier: $19 per month for 5,000 calls, with a marketplace API key and uniform billing | Choose a paid tier and use the marketplace’s billing setup | Recurring subscription revenue, dependent on sign-ups and continued use |
| Pay per call | $0.01 for a single operation; $0.05 for a batch of up to 100 items | Pay for an operation, with the reported x402 flow settling in USDC on Base | Usage-dependent payments rather than a recurring subscription |
These models change the payment experience, not the underlying need for users. A free allowance may reduce the cost of trying a tool; a subscription makes the price and usage allowance explicit; per-call payment can fit a discrete operation. The account supplies no conversion or revenue comparison, so it does not establish that one model performs better.
Why a working paywall can still earn nothing
A payment mechanism handles a transaction after a user or agent wants the tool. It does not create that reason to use it, put the tool in front of the right audience, or make the tool discoverable in an agent’s workflow. As Oleksandr put it, “Configuration is not distribution.”
Free tools Windows power users keep installed
One-click scans. No signup required.
His related point—“x402 doesn’t sell itself”—is about the path to a call. An agent must have a task the service can solve and a way to find or select that service. Without those conditions, a technically functional paywall can remain unused. This is the author’s explanation of his own result, not a claim that every x402 service has the same outcome.
What the account says about implementation friction
The article includes a few practical debugging observations, which should be treated as leads from one implementation rather than universal rules about current platform behavior.
- Worker-to-Worker requests: Oleksandr says a public
fetch()from one Worker to another did not arrive because of Cloudflare loop protection, and that a Service Binding resolved the call path. - Repeated classification requests: He describes caching in KV using a SHA-256 hash of a normalized description as the key.
- Secret changes: He reports that after updating a secret, he sometimes needed another deployment for the change to take effect.
These details help explain the work behind a deployed tool, but they do not establish current Cloudflare requirements. Check the platform’s applicable documentation and configuration when diagnosing a similar issue.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Distribution experiments the builder proposed
Oleksandr’s proposed next steps focus on reducing setup effort and reaching people where they already look for answers. The account proposes these experiments; it does not report that they generated users or revenue.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteOffer an interface for the audience, not just the API
The Sheets function was meant to give logistics or spreadsheet users a familiar way to access HS-code classification. That can remove the need to configure an MCP client or call an endpoint directly. The broader lesson is to match the interface to the user’s task and comfort level, rather than assuming every potential user will integrate an API.
Create pages for specific problems
The author suggests programmatic SEO pages targeting long-tail searches—for example, HS codes for named objects or IBAN validation for a particular country. Such pages can give a person with a specific need a direct route to the relevant tool. They are a proposed discovery tactic, not evidence of search traffic or conversions.
Reach existing communities
He names DEV.to, Medium, Reddit communities, Hacker News and AI-agent Discord communities as possible places to introduce the tools. Posting in a channel is not the same as finding a fit: each community has its own norms, and the account provides no conversion results from these outlets.
Make the first-user goal concrete
The author says his next goal was to get the first 100 users to see the tools. That is a visibility target, not a reported achievement. A useful next measurement would distinguish people who merely encounter a listing from those who try a tool, return to it or pay—because each step tests a different part of the path from discovery to revenue.
The practical takeaway for AI-tool builders
This account is most useful as a reminder to treat distribution as part of product development, rather than as the final step after deployment. Before adding another payment option, identify the specific user, the task they need done, the interface they can actually use and the route by which they will discover the tool. Then measure whether that route brings relevant trials and repeat use. The experience does not show that the 35 servers were broadly representative; it does show that, for this builder, technical completion and payment support did not by themselves produce customers.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
