Anything Reports 1.5 Million Users. Who’s Paying?

A crowd is an opening act

A million and a half people make a handsome entrance. They do not, merely by arriving, become a million and a half customers. Anything’s growth story begins with an impressive crowd and an awkwardly useful question: how many people stay long enough to pay, publish, or earn?

Anthropic’s Anything case study reports 1.5 million users and more than 800,000 apps created in five months. Those are participation and creation totals. The disclosure does not establish how many users bought a subscription or how many projects became live businesses. Anthropic case study ↗

That distinction matters because the invitation is unusually seductive. Describe software in ordinary language and let an agent do the building. A person who once needed a developer can now begin with a sentence. The first experiment becomes easier; the second may become irresistible. A project counter can rise quickly in such a world, while the harder business questions wait politely outside.

First, put the dates back

The historical baseline is September 29, 2025. In its Series A announcement, Anything said it had raised $11 million at a $100 million valuation, with Footwork leading the round. The same post dated the product’s launch to August 7 and reported a $2 million annualized revenue run rate two weeks later. Series A announcement ↗

Then came a fresh milestone. On November 29, 2025, co-founder Dhruv Amin announced one million builders and a $5 million run rate on LinkedIn. The post’s publication metadata supplies that date; a search engine’s crawl date tells us when a page was visited, not when the founder made the announcement. Founder milestone post ↗

There is momentum in that sequence. There is also a limit to what it says. An annualized run rate projects a revenue pace across a year; it is not a statement that the company collected that amount over the preceding twelve months. Amin’s later post calls its figure a run rate without laying out the calculation. Treating the two figures as a perfectly standardized revenue series would give the evidence a tidiness it has not earned.

The Anthropic case study supplies a larger user count, but its five-month app-building window is not anchored to explicit calendar dates in the visible text. It should not be squeezed into a month-by-month growth chart. Dates are small things until someone removes them; then they become rather large mistakes. Case study reporting window ↗

The percentage with the wrong job

Another number deserves its own chair: 91–96%. Anthropic reports that range as Anything’s agent success rate, measured through generation completions, agent self-reports, and in-product user feedback. It is a measure of building activity, not production uptime. Success-rate methodology ↗

Finishing a generation and keeping a service available answer different questions. A build may complete while leaving a workflow that needs attention. A deployed app may work at launch and encounter trouble later, when more people arrive, an integration changes, or a payment takes an unexpected path. These are examples of what an uptime or operational assessment would need to examine, not reported failures at Anything.

The disclosed success measure also leaves readers without the underlying sample size, task mix, or a detailed definition of a successful completion. A percentage gains meaning from its denominator. Without those details, the range is informative as a company-reported assessment of its agent, but it cannot promise the reliability of every app a reader might build.

Four questions behind the applause

Paid conversion comes first. How many builders become paying customers, on which plans, and after how much experimentation? A total user count supplies none of those answers. Even dividing a revenue figure by that count would mix an annualized pace with an undefined population and produce a number with more confidence than meaning.

Retention follows. Do people return after their first build? Does a cohort still use the product after thirty, ninety, or one hundred and eighty days? A cumulative total can keep rising even when earlier arrivals stop using the service. To understand repeat demand, readers need cohorts followed through time, with a clear definition of active use.

Next is the published-app share. Creating a project is an event; publishing it makes a different claim. An internal tool might be valuable without public distribution, while a publicly accessible app might attract no users. Useful reporting would distinguish experiments, deployed projects, actively used apps, and commercial products rather than asking one creation total to represent them all.

Finally, builder earnings. How many people make money, how much do they keep after costs, and how evenly is that money distributed? A few successful examples can demonstrate possibility. They cannot establish the typical outcome. The median, the share earning nothing, and the period over which earnings are measured would reveal more than a procession of exceptional winners.

The next number worth watching

These questions need not spoil the achievement. Lowering the cost of trying an idea can matter even when the attempt never becomes a business. A useful personal tool, a faster internal process, or a lesson learned cheaply can justify the experiment. Commercial success is one outcome among several; it simply requires its own evidence.

The strongest next disclosure would follow the same group of builders from arrival to repeat use, payment, deployment, and earnings. That would let readers see where curiosity turns into commitment and where commitment produces something customers want. It would also allow the company to show progress without making each new headline carry the whole argument.

For now, Anything has disclosed a substantial audience and a rising reported revenue pace. The missing measures decide how that audience should be understood. The crowd has entered. The receipts will tell us who intends to stay.