When a Feature You Can Build in 20 Minutes Sells for Eight Figures

MyFitnessPal paid what was likely eight figures, and possibly low nine, to acquire a competing app whose core function was rebuilt on camera in under twenty minutes with a single prompt and a vision model subscription. I am Madhuranjan Kumar, and I want to be direct about what this gap reveals, because the deal has been framed widely as a smart growth move when it reads more accurately as an illustration of a broken acquisition playbook.

Cal AI is a photo-to-calorie tool. You point your phone at food and get a calorie and nutrient estimate immediately. The team that built it was seven people. They had reached around thirty million dollars in annual recurring revenue. The deal took nearly a year of negotiations, which suggests the price was significant to both sides. From one angle it looks like sensible consolidation: a large incumbent absorbs a faster-growing rival, protects its user base, and gains the engineering team that built the competing product. From a different angle it is a company paying eight figures for a feature anyone with a vision model subscription can now replicate before lunch.

A feature worth eight figures can be rebuilt in twenty minutes, and that is the whole story

The rebuild demonstration is what put this deal in a different light. The build started with one short prompt at 11:18 in the morning. By 11:35 a working tool was running. It sends a food photo to a vision model, which identifies each item, estimates portions, and returns calories, protein, carbs, fat, and fiber per item plus totals. A double cheeseburger logged at 744 calories against a real count of 610. Cal AI itself does not get significantly more accurate than that. For the core job of a calorie tracker, close enough is the job.

That accuracy result removes the last place a technical moat could have been hiding. If the feature required years of food-specific model training, proprietary labeled datasets, or a specialized architecture that took months to develop, the twenty-minute clone would have produced a noticeably worse result. It did not. The vision model delivers functionally equivalent accuracy to the product someone just paid eight figures to acquire. The feature was always a thin wrapper around model inference that any paying subscriber can now access, and the rebuild proved it in seventeen minutes.

The acquisition argument has defenders, and the strongest version of that argument is honest: you cannot rebuild thirty million in annual recurring revenue in twenty minutes, and a habituated, loyal user community is not the same thing as a feature clone. That counterpoint is factually true and also beside the point. Revenue built on a thin feature is not the same as revenue built on a defensible capability. Revenue that persists primarily because users have not yet encountered the free substitute is brittle in a way the ARR number does not reveal. The moment the substitute becomes a natural capability inside the assistant users already open dozens of times a day, the separate subscription payment loses its reason to exist.

The deal was not irrational at the time it was announced. A year ago the twenty-minute rebuild was a less obvious move and the vision model landscape was less mature. What the story captures is the pace at which the environment has shifted. A price set on last year's competitive assumptions is being tested by this year's capabilities, and that gap is the thing worth understanding.

Distribution was never a moat, it was a headstart that the market eventually closes

The acquisition playbook that produced this deal, buy the competitor, absorb the users, upsell them on other products, was built on an assumption about software that is now under pressure. That assumption is that the software itself creates the switching costs. A calorie counter with two years of your meal history, saved foods, and logged habits has real friction attached to it. Users stay because moving is annoying, not because the feature is technically irreplaceable.

That friction model still functions, but its durability is shortening fast. When a capable substitute becomes a free capability inside the assistant a user already opens throughout the day, the friction of switching disappears without the user needing to make any deliberate decision. The substitute does not need to import your history if it is embedded in the agent that already knows your health goals, your dietary restrictions, and your daily patterns. There is no second app to open, no migration to plan, no account to create. The capability exists inside the context already running, and the separate subscription stops making sense without any dramatic churn event occurring.

Distribution has always been a headstart. For most of software history that headstart was durable enough to function as a moat, because building the competing product was slow, distributing it to users was slow, and switching habituated users was genuinely hard. The headstart gave a product years of runway, and if the company used those years to build real defensibility, proprietary data, network effects, or deep workflow integrations, it converted the headstart into something that would hold.

The problem is that many subscription apps in the last decade used their distribution lead to grow revenue and optimize for engagement without building any of those things. The feature was the whole product. Distribution kept it alive. And now the cost of building the next version of the feature has dropped far enough to close the headstart gap in seventeen minutes of prompt-and-preview.

For anyone running meta-ads or google-ads to drive trial for a narrow software product, this is a direct pressure point. The cost of acquiring a subscriber through paid media is high enough that if that subscriber is held by a thin feature rather than a sticky moat, the lifetime value is more fragile than the model suggests. Churn in this scenario does not look like a competitor with a better product. It looks like a capability appearing naturally inside the assistant a user already trusts, requiring no download, no migration, and no deliberate decision to switch.

The subscription economy built on thin features is the next category under pressure

Cal AI is not an isolated case. The subscription software economy of the last decade produced thousands of products with the same competitive profile: a small team, a clean implementation of one narrow job, real recurring revenue, and a moat that was primarily distribution and first-mover timing. A receipt scanner. A simple meeting scheduler. A one-click background remover. A basic email sorter. A calorie tracker. Each did one thing well, charged a monthly fee, and grew through smart distribution and word of mouth.

The economics of those products rested on two assumptions that are now weakening simultaneously. The first assumption was that the feature was meaningfully difficult to replicate. The second was that users would not encounter a capable free substitute for years. The first assumption is breaking down because the cost of building the next version of anything has dropped dramatically. The second is already gone because the substitute lives inside the daily-use assistant, not behind a separate discovery and download step.

The single-function subscription app category is the most exposed segment of the current software market. The narrow tools at the edges of the business stack, the ones that do one specific job and charge per seat, are the ones facing the most pressure over the next cycle. Businesses that built a real moat inside this category will weather the transition. Businesses whose only defensible asset was timing and distribution will face compressing retention and compressing paid acquisition economics at the same time, which is a difficult combination to trade out of.

When I look at seo-content strategy for software clients, the moat question is now the first thing I examine before any positioning work. If the honest answer is that the feature is the whole product and the feature is now replicable quickly, the content strategy needs to be built around acquiring users fast and converting them to something stickier, not around defending a position the market is already in the process of closing.

What a real moat looks like now that the feature is not the defensible part

If the feature is not defensible, the moat must live somewhere else. In the current landscape there are three places it can credibly sit, and a product without any of the three is genuinely exposed.

Proprietary data is the first. A product that trains on or structures access to data that no outside party can replicate builds a genuine capability advantage. A medical documentation tool trained on years of de-identified clinical notes from a specific specialty cannot be rebuilt by describing the feature in a prompt. The model was shaped by data that is not publicly available, and the output quality in context-specific cases is noticeably better as a result. That gap justifies the subscription in a way that a general-purpose vision model cannot close. The same logic applies to any product whose core value rests on access to a proprietary data source or a community-generated dataset that the product itself built and structured over years.

Network effects are the second. A product whose value increases as more people use it builds a moat that time and distribution reinforce rather than erode. A professional community where members find each other, share work, build trust, and generate review histories has a relationship layer that a general-purpose agent cannot synthesize on demand. A marketplace with transaction history, repeat relationships, and accumulated reputation is a social structure, not a feature or a database. It took years to form and cannot be prompted into existence.

Integration depth is the third. A product that has spent years connecting to the specific tools, data sources, and workflows of a particular industry is substantially harder to substitute. An accounting platform that connects to a firm's bank feeds, payroll processor, document storage, and tax filing system is doing dozens of interconnected things. Replacing it requires rebuilding every integration, not just the core capability. That depth is a real moat because the switching cost is measured in months of work across multiple systems, not the twenty minutes it takes to build a feature clone.

The audit every software owner and software buyer should run this quarter

The practical response to this analysis is a structured audit that takes one focused afternoon and produces clear decisions about the software stack and the products competing within it.

For software buyers, the starting question for every line item on the tool stack is direct: does this tool do something an AI assistant cannot replicate for the cost of a subscription already paid? Work through the subscriptions under fifty dollars a month first. For each tool, describe what it does in plain language and ask an existing AI assistant to do the same job. The tools that pass this test are doing something the agent cannot: connecting to proprietary data, providing a professional network the agent cannot access, or integrating with systems that resist substitution. The tools that fail the check are candidates for removal from the stack, not renewal.

For software sellers, the audit runs in the opposite direction. For every core feature in the product, ask the same question from the buyer's perspective. Could a competitor or a well-prompted general-purpose AI agent replicate this in under an hour? If yes, the follow-up question is whether something surrounding the feature makes it valuable regardless. Where is the proprietary data? Where is the network effect? Where is the integration depth that justifies the subscription fee? If the honest answer is that the feature is the whole product and the feature is now a commodity, the next investment priority is moat-building, not distribution.

For anyone evaluating an acquisition target in the current market, this story suggests a specific due diligence question that should precede any letter of intent. If the target's core feature can be replicated by a capable AI agent in under an hour, what is actually being purchased? If the answer is a user base and revenue, the follow-up question is how durable that user base is once users encounter the free substitute at scale. The price should reflect the durability of the retention, not the current run rate.

The lesson is not that acquisitions are wrong or that distribution has no value. Distribution matters enormously, and a well-distributed product with real recurring revenue is a real asset. The lesson is that distribution alone does not constitute a moat in the current environment, and a price set primarily on distribution-built revenue deserves a harder question about what happens when the feature becomes free. Every business that owns software or buys software should run this audit this quarter. The answer tells you more about the durability of the business than any revenue metric can.