In the Age of AI, Do Not Turn "An App the Customer Could Build Themselves" Into a Product: Defensible Products and Network Effects

Hello, this is Ryuta Hamamoto from TIMEWELL.

Lately I have been hearing a particular question a lot, from people about to found a company or launch a new business: "Can I sell this app I built with AI as a service?" Generative AI and AI coding have become familiar all at once, and an app that used to take months now assembles itself over a weekend from a few instructions. When you have a working thing in your hands, it is only natural to think, "Could this become a business?" I think that is a thoroughly healthy instinct.

What I often end up saying honestly, though, is this question in return: "Could your customer build that app themselves?" That you can build it is wonderful. But being able to build it and being able to sell it, and have it last, are two different things. In this article I want to break down, in terms clear enough for anyone about to start a company, why "an app the customer could build themselves" tends not to grow even when you turn it into a service, and conversely what actually can be defended. Let me note at the outset that the judgment of "will sell or will not sell" is not an established fact I can assert flatly; it is, throughout, my view. On the other hand, the concept of "network effects" that I take up in the second half is well established in management scholarship, so that part I explain accurately, as fact.

"Can I sell this AI app?" is a question I hear more and more

First, let me lay out why this question is on the rise. Behind it are two broad shifts.

One is that the hurdle of building something has dropped dramatically. Give AI an instruction and a simple web app or a business tool takes shape in a short time, even in the hands of someone with little specialist knowledge. This is purely a good thing; the speed of trying out an idea has gone up.

The other is that, precisely for that reason, we have entered an age where "anyone else can easily build the same thing" too. This is the part that gets overlooked. That you could build it over a weekend means your prospective customer, and anyone who might become a competitor, may be able to build it over a weekend just the same. The era in which the difficulty of building was itself the barrier to entry is quietly ending.

Let me tidy up one term here. The word "commoditisation," which comes up a lot, means, put simply, becoming a state where "the contents are the same wherever you buy it, all lined up flat." Differentiation stops working, and in the end you can compete only on price. For a maker it is a frightening word, because it means slowly losing the source of profit. And the spread of generative AI, there is a view, tends to push "a simple app that assembles itself from an instruction" in this direction of commoditisation. A feature that is merely a thin layer laid over a foundational model is easy for anyone to reproduce as an equivalent in a short time.¹

Why does "an app the customer could build themselves" tend not to sell? (my view)

From here, please read this as my view. The apps I regard as "hard to sell" have the following traits.

The first is the simple kind that AI can assemble from an instruction. The function is simple, and almost none of the maker's own ingenuity rides on top of it. The moment the customer realises "I could just have AI build this myself," the reason to buy it vanishes.

The second is the kind that merely judges an input and returns a result. For example, you enter something and it returns "yes or no" or a score, and that is the end of it. Use it once and the mechanism is legible, and from the second time on there is a risk of someone building something similar themselves.

The third is the kind low in update frequency. Build it once and the contents barely change. The world and the frontline move, but the app keeps returning the same answer. Such a thing, far from rising in value over time, actually grows stale.

What these share, I think, is that they "cannot make time their ally." Today's completeness is the maximum, and from tomorrow on all they do is wait to be caught up with. A product that peaks the moment it is built is very weak against the wave of commoditisation. So I grow cautious about placing this kind of standalone app as the pillar of a business.

Just to be safe, let me add: I am not saying "every app built with AI is unsellable." Even something that looks simple can win on distribution, on trust, on timing. My point is only that a product that relies on the difficulty of building alone is precarious. If you first want to know what level your own, or your company's, use of AI is at right now, it is a good idea to start from the free AI literacy check.

So what can be defended? Update frequency and the data moat

So conversely, what can be defended? What I pay attention to falls broadly into the following three.

The first is being high in update frequency. A service whose contents are constantly updated to keep pace with changes in the world and on the frontline is hard to catch up with even when imitated. Because even if a competitor could copy the current version, you have already moved on to the next. A stationary target gets hit; a target that keeps moving is hard to strike. Updating itself becomes the defence, is the image.

The second is that frontline data accumulates and turns into value. The more you use it, the more data that exists nowhere but in that service piles up, and it makes the product smarter and more useful. This is where the word "moat" comes in. The moat that rings a castle. The deeper and wider it is, the harder it is for an enemy to storm in. In business, the elements a competitor cannot easily copy are exactly what the moat is. Proprietary data that accumulates through use is a prime example.

This mechanism, by which data becomes a strength, is called the "data moat." Its substance is a virtuous cycle. Use increases, data accumulates, the product improves, use increases further. As this loop turns round and round, a gap that latecomers cannot catch up with piles up over time. Such a wheel is sometimes called a flywheel.

But this is easy to misunderstand, so let me write it carefully. For a data moat to hold, two conditions are required. One is that the product grows more valuable as data increases. The other is that use itself generates new data.² Only when these two are in place does data become a moat.

Put the other way round, "having a lot of data" is not necessarily a strength in itself. Even a standard analysis points out that the data moat tends to be overrated. It is said, for instance, that the moat weakens when data is not at the centre of the product's value, when handling new edge cases stops being worth the cost, and when the data belongs not to your company but to the customer or the public.² So what matters is not "do you have data?" but "does use generate proprietary data, and does it form a loop that continuously raises the product's core value?" I dig into this from a different angle in the companion piece Hand Your Proprietary Data to AI and Your "Moat" Disappears. Read them together and the contours of the moat come into sharper relief, I think.

What are network effects? Explained through everyday examples

The third of the defensible elements is the other lead of this article: "network effects." This is a concept established in management scholarship, so I explain it accurately, as fact.

A network effect is the phenomenon whereby the value a user gets from a service rises as the number of its users grows.³ It is also called "demand-side economies of scale." Where ordinary economies of scale are a maker-side story ("the more you make, the lower the cost per unit"), this is a user-side story ("the more people use it, the higher the value for each individual"). Users increase, value rises, users increase further, a positive cycle at work.

Let me introduce three representative types through everyday examples.

First, the direct network effect. This is the type where the more users of the same kind there are, the more each individual's value directly rises. The clearest case would be the telephone or a messaging app. If you are the only subscriber, that phone is worth almost nothing. The more people there are you can reach, the more its value leaps up. Social media is the same; the more of your friends take part, the more reasons you have to use it. A service like this becomes useful only once it passes a certain number of users. That tipping point is called "critical mass."

Next, the indirect network effect, also known as the "two-sided" network effect. This is the type where distinct groups of participants, such as supply side and demand side, draw each other in and raise the value. A marketplace is an easy example. The more sellers there are, the more appealing it is to buyers, and the more buyers there are, the more appealing it is to sellers. When one side grows, the other side gathers, and both grow together at once. The relationship between an OS and its apps (the more compatible apps, the more appealing the OS; the more users, the more developers gather) and credit cards (merchants and cardholders) share the same structure. A late entrant has to gather both sides at the same time, and this is very hard. That is why it becomes a strong moat.

And the data network effect, which is exactly the "data moat" from earlier. This is the type where the more use accumulates data, the smarter the product becomes, which in turn draws still more use. A real-time traffic app is a good example: driving data keeps improving congestion prediction without pause, so the accumulation itself becomes value.³

Here let me also touch on "Metcalfe's law," which often gets cited. It is a rule of thumb that a network's value is roughly proportional to the square of the number of connected people (call it N). It expresses the intuition that when participants double, the combinations of connections increase sharply, so value leaps up far beyond doubling. But this is only a rule of thumb, not a strict quantitative law, a point I will add. The actual value does not cleanly become N squared.

Services where data and network effects work tend to grow (analysis)

From here, please read this as analysis and view.

In the digital domain, network effects are regarded as one of the strongest barriers to entry. According to an analysis by NfX, known in the field of venture investment, roughly 70 percent of the value tech companies have created since 1994 derives from companies that hold network effects.⁴ This is the firm's own view, but it serves as one perspective on just how much this force has told. Network effects generate a tendency in which "the bigger the scale, the stronger you get, and the winner wins more."

And onto this is grafted an implication particular to the age of generative AI. There is an organising idea that defensibility resides not in the technology of AI itself but in the "product and data" beneath it.¹ The parts AI can easily replicate, that is, the UI for generation, transformation, or simple judgment, tend to grow thin in value. On the other hand, the advantage that endures over time is said to reside in the traditional moats: uniquely accumulated usage data and feedback loops, deep embedding into the operational workflow together with switching costs, brand and trust and distribution, and network effects.¹

Turned around, this is what I think it means. An app that has merely mounted AI as a "convenient feature" is easily swallowed by the wave of commoditisation. But a product designed so that AI is "a mechanism through which use keeps generating proprietary data and relationships" is easier to defend even amid the wave. When the data moat and network effects mesh, a double loop begins to turn: the more you use it the more data accumulates and the smarter it grows, and because it grows smart people gather, and because people gather data accumulates further. This double loop is, I believe, the shape of a service that tends to grow in the age of AI.

Reworking toward such a "defensible product" is often faster when you bring in an outside perspective than when you agonise over it alone. At TIMEWELL, through our AI consulting service WARP, we work alongside you from the sparring stage of this kind of product strategy. For those about to found a company in particular, there is WARP Entre (/en/warp/entre), which specialises in accompanying founders, and we can think through the design of the moat together from the idea stage.

If you are building from now, weave the moat and the loop into the design

Finally, for those building from here, let me organise a practical perspective. The watchword is "not can it be built, but can it be defended."

Once you hit on an idea, first ask yourself, deliberately meanly, "Couldn't I (or my customer) easily reproduce this with AI?" If it can be easily reproduced, do not stake the fight on that one point alone. Consider whether you can layer the following moats onto it.

• The data moat. Is it designed so that the more it is used, the more proprietary data exists nowhere but in that service accumulates? And does that data continuously raise the product's core value? Judge this not by "do you have it?" but by "does use generate data, and does it form a loop where the data tells?"
• Network effects. Is it structured so that the more users or participants there are, the higher each individual's value? The direct type (the more people use it, the better) or the two-sided type (makers and users call each other in) both work.
• Switching costs and embedding. Have you got deeply into the customer's operational workflow, creating a state where switching hurts?
• Update frequency. Can you keep updating the contents to match changes in the world and on the frontline? Not stopping is itself a defence.

These work far better woven into the design from the outset than added later. Conversely, a "merely easy-to-build app" that holds none of these moats will, however high its completeness is now, be caught up with as time passes. That is my read.

For how to move as someone about to start a company, and how to position yourself as a developer in the age of AI, I have written concretely in other articles too. Do take a look at How to Raise Entrepreneurs Who Command AI and A Guide to Becoming an AI-Driven Developer as well.

To sum up

It ran long, so let me organise the key points.

• With the spread of generative AI, a simple app that assembles itself from an instruction, or a service that merely judges and returns with little ongoing update, is prone to commoditisation. Something the customer can reproduce themselves is hard to sell (my view)
• What can be defended is what is high in update frequency, what accumulates frontline data and turns it into value (the data moat), and what grows more valuable as users increase (network effects)
• Network effects are an established concept in management scholarship, with three representatives: direct, indirect (two-sided), and data. Metcalfe's law (value roughly proportional to the square of the number of people) is a rule of thumb, not a strict law
• The data moat is decided not by "do you have it?" but by "does use generate proprietary data, and does it form a loop that continuously raises core value?" Note that it tends to be overrated (analysis)
• Defensibility resides not in AI technology itself but in the product and data beneath it. Design AI not as a "feature" but as "a mechanism through which use keeps generating proprietary data and relationships" (analysis)
• If you are building from now, ask "can it be defended?" not "can it be built?" Weave the data moat, network effects, switching costs, and update frequency into the design from the outset

Being able to build is, by now, hard to turn into differentiation. Precisely because of that, ask again at the design stage what accumulates after you have built it, and whether you can make time your ally. If you would like to talk in concrete terms about how to build a product's moat, and the path to making AI a weapon for your business, please talk to the WARP team. From the idea stage, we will work alongside you in growing it into a defensible product.

References and primary sources

Footnotes

1. Martin Casado, Matt Bornstein and others, "The New Business of AI (and How It's Different From Traditional Software)," a16z. The organising idea that defensibility passes through to the product and data beneath, rather than residing in AI technology itself, and the analysis that a thin feature laid over a foundational model is easy to reproduce. Forward-looking forecasts and judgments of superiority are treated as the firm's view (analysis). https://a16z.com/the-new-business-of-ai-and-how-its-different-from-traditional-software/ ↩ ↩² ↩³

2. Ibid. (a16z). Analysis and view on the conditions for a data moat to hold (the product grows more valuable as data increases / use generates data), and on the three cases in which the data moat tends to be overrated (data is not central to the product's value / the marginal utility of handling edge cases diminishes / the data belongs not to your company but to the customer or the public). ↩ ↩²

3. Definition and typology of the "network effect" (direct, indirect / two-sided, data, technical performance, social). The concept is treated as established management knowledge. Entered via Wikipedia, with the source organisation referenced in NfX's "The Network Effects Manual." https://en.wikipedia.org/wiki/Network_effect and https://www.nfx.com/post/network-effects-manual ↩ ↩²

4. NfX, "The Network Effects Manual." The figure that roughly 70 percent of the value tech companies have created since 1994 derives from companies holding network effects is the firm's own view (analysis). The number is cited as the firm's own estimate. https://www.nfx.com/post/network-effects-manual ↩