[Column] The Age of Building and Selling Apps Is Over

Overview

In an era where non-developers can build their own services, what happens to the client services of traditional software companies? I dare to predict the future I see.

This Time, It’s About the Companies

In my previous piece, [Column] ‘We Can’t Build It Without a Developer’ No Longer Holds, I wrote about the crisis facing individual developers. My argument was that agentic coding assistants have put the act of writing code within everyone’s reach, dissolving the scarcity that once made developers so valuable.

But after spending over a month chewing on the topic after publishing that piece, I realized I had missed something. I had been so focused on the crisis of individual developers that I lost sight of the bigger picture. Behind the crisis of individual developers lies a far larger tectonic shift. If developers are being shaken, what happens to the companies that hired those developers to build services? In a world where everyone can write code, what is the purpose of software companies that build and sell apps and web services?

That’s what this piece is about. If the age of developers has changed, the age of companies is changing too. And the direction of that change points somewhere most people haven’t yet seriously considered.

What’s Happening Right Now

Let’s start with the current state of things.

In the previous piece, I mentioned a phenomenon called vibe coding. It’s a style of building software where you describe what you want to an AI in natural language instead of writing code yourself. This has been spreading explosively over just the past few months.

A marketer builds a lead management tool for their team over the weekend and deploys it on Monday. An accountant builds their own client management dashboard. A real estate agent creates a property management app and shares it with colleagues. A fitness trainer builds their own member management and workout program app. These aren’t hypothetical scenarios. They’re happening right now.

What’s worth noting is the motivation behind these people. They’re not building apps out of technological curiosity. They’re building to solve specific pain points in their work. There were needs that existing services couldn’t meet, and now that a tool exists to address those needs directly, they’re building as naturally as breathing.

This subtle distinction matters. It means vibe coding isn’t just a tech trend - it’s a fundamental shift in how work gets done.

The critical point is that these aren’t just toy projects. As agentic coding assistants like Claude Code and Cursor have improved, the quality of services built by non-developers has crossed from usable to good enough. The designs are clean, basic CRUD features work flawlessly, and even seemingly complex features like payment integration and authentication can be implemented by following AI’s guidance.

Just a year ago, an AI-built app meant crude UI with barely functioning features - demo-level at best. Not anymore. agentic coding assistants are advancing so rapidly that what was a limitation six months ago has become today’s basic feature.

How far this pace will continue is anyone’s guess. But the direction is clear. The quality of apps built by non-developers keeps rising, and the gap with professional development teams is narrowing fast.

There are still limitations, of course. Areas like complex business logic or high-traffic processing remain difficult without professional developers. But the vast majority of software in the world isn’t that complex. Most apps are CRUD operations with a bit of business logic sprinkled on top. And in exactly that space, agentic coding assistants are already more than capable.

This raises a question. If non-developers can build the services they need for themselves, what happens to the companies that were providing those services?

The Compromise of General-Purpose Services

Let’s step back for a moment and think about why we use apps and web services built by companies.

In most cases, the answer is simple. It’s because we can’t build our own. When you need a to-do app, you download Todoist. When you need notes, you use Notion. When you need project management, you use Jira. Not because these services fit you perfectly, but because you can’t build what you actually want, so you pick the closest option available.

If we’re being honest, we’ve all had this experience. Using an app and thinking “why is this feature designed this way?”, “this isn’t how I want it to work,” “I don’t need this feature, I wish it had that one instead.” But there were no alternatives. Unless you learned to code or hired a developer, you had to accept existing services as they were.

On top of that, we’ve been perpetually forced to choose within the app ecosystem. Dozens of apps with similar features exist, and you have to download them, try them out, compare, and eventually settle on the one that’s least unsatisfying.

This was never really a process of finding what fits me. It was a process of finding what fits me least badly.

This is how the software industry has worked until now. Companies build services for an average user. A to-do app used by 500,000 people fits none of those 500,000 perfectly. But it fits all of them well enough, and that’s why it can exist. It stands on a compromise of generality. That’s the essence of the traditional software business.

As a service scales, this compromise deepens. To satisfy 500,000 users, features must become more generic and the interface more averaged out. Features for power users confuse beginners; simplicity for beginners frustrates power users. Companies perpetually tug between these extremes. And inevitably, they produce a product that fully satisfies no one.

But that premise is crumbling.

I’ll Build My Own App

What happens when users can build services tailored exactly to their needs?

Consider this example. A freelance translator with a unique workflow. They send quotes to clients, manage translation projects, maintain glossaries, and issue invoices. They could try existing project management tools. Notion, maybe, or Trello. But those tools weren’t designed for a translator’s workflow. Glossaries need to be managed separately, quote templates require a different tool, and invoices need yet another service. They end up juggling multiple tools and living with the inefficiency.

Now this translator tells an agentic coding assistant: “Build me an app to manage my translation work. Client management, quote generation, project tracking, glossary management, and invoicing, all in one.” The AI hears these requirements and builds an app tailored exactly to this translator.

The design might be a little rough. Some features might not be perfect. But this is a tool precisely fitted to this translator’s workflow. Far more efficient than bouncing between Notion, Trello, and an invoicing service.

Apply this scenario to every profession.

A lawyer builds their own case management system. A small cafe owner builds an inventory management app fitted to their store. A YouTuber creates a dashboard for content planning and schedule management. A tutoring center director builds a student management and class scheduling system. Each person gets software optimized for their own work.

What’s even more important is that these custom apps aren’t a one-and-done affair. When you find something inconvenient while using it, you just tell the AI “change this part to work like this.” What used to require submitting a feature request and waiting months for the development team to act on it gets resolved instantly. Users control their own product roadmap. What features to add, in what order to improve things - every decision is in the user’s own hands.

Imagine a general-purpose to-do app used by 500,000 people alongside a custom-built to-do app made just for you. If both are free, which one would you use? The answer is obvious.

The moment the reason for general-purpose services to exist - because you can’t build your own - disappears, the value of those services drops sharply. This is the fundamental crisis facing existing software companies.

The Dilemma of Existing Companies

This shift won’t impact all software companies equally. But a significant number will find themselves in a serious dilemma.

The first to take a hit are simple CRUD-based utility apps and productivity tools. To-do apps, note apps, habit trackers, budget apps, and calendar managers all fit this description. The core functionality of these apps is creating, reading, updating, and deleting data, which is precisely the area where agentic coding assistants excel.

Think about the business model of companies running these apps. Most use freemium. Basic features are free, and premium ones sit behind a monthly subscription. Or they show ads to free users and monetize through advertising.

But when users can build their own apps, the foundation of this business model starts to crack. Why pay $5 a month for someone else’s to-do app? I can build one with exactly the features I want. Why endure ads in a free app? I can build my own without ads.

This isn’t just about one or two apps. It’s a structural problem for the software industry.

Until now, the competitive strategies of software companies have broadly been two things: offer more features at a lower price, or offer a better user experience. But when users can build services that fit them exactly, both strategies lose their meaning. More features? Users only want the features they need. Better UX? Users design it themselves in whatever way is most comfortable.

There’s another uncomfortable truth here. The feature additions of existing software companies were often not for users but for the business. They would artificially segment features to justify a subscription model, restrict core functionality in the free tier, and create premium features designed purely for upselling.

As a user, you’ve probably had the experience of needing to subscribe to a “Pro plan” loaded with features you’ll never use, just to access the one feature you actually need. When you build your own app, these artificial restrictions vanish. You include what you need and nothing more.

Of course, this won’t happen overnight. Not every user will immediately build their own app with AI. But the direction is clear. And the moment the direction becomes clear, companies need to start preparing.

This is not a change in technology. It’s a transfer of power. The power to create software is shifting from companies to individuals. In the past, companies decided what you’ll use. Users had to pick from the menu that companies had prepared. In the future, users decide what to build for themselves. The significance of this power shift should not be underestimated.

The Crisis of the Advertising Model

There’s another thread worth pulling on here. The advertising model.

A substantial portion of the internet economy currently runs on advertising. Google, Meta, and countless free apps and services all fit the pattern. Their business models are fundamentally the same. They provide a free service to users and sell those users’ attention to advertisers. They collect user data to run sophisticated targeted ads. This model has dominated the internet economy for the past 20 years.

But there are no ads in apps users build themselves. Obviously. Why would I put ads in an app I built for my own needs? There’s no data collection either. My data lives in my app, on my server (or my cloud). There’s no reason for it to reach a third party.

Think about what this means.

When users start using their own custom apps instead of general-purpose free apps, the touchpoints for showing ads shrink. The channels through which companies can collect user behavior data narrow. The foundation of the ad-based business model - access to a massive user pool - weakens.

Google Search and YouTube aren’t going to vanish overnight, of course. But for small and mid-sized apps and services, the ad-based model will become increasingly difficult. The moment users can choose my own app + no ads over free app + ads, the appeal of the advertising model plummets.

The data collection model faces the same pressure. Many services have been built on the implicit deal of use it for free, just give us your data. Most users either didn’t realize this deal existed or accepted it because there was no alternative. But now there is an alternative. You can build your own service without handing over your data.

This isn’t just a problem for the ad industry. It’s a challenge to the very structure of the internet economy built on advertising and data collection.

Take it one step further. If the advertising model weakens, the very concept of free services starts to shake. The countless free services we’ve been enjoying were never actually free. We were paying with our attention and our data. When users build their own apps, they exit this implicit transaction entirely. No ads, no tracking, no push notifications nagging you to come back.

What remains is software that exists purely for its owner’s purpose. Perhaps that’s what software was always supposed to be.

The Arrival of the Module Economy

So what direction should existing software companies pivot toward? I dare to predict that the answer lies in the module economy. This is my personal speculation. But it is speculation with what I believe to be solid reasoning behind it.

Until now, software companies sold finished products. They planned, designed, developed, tested, and delivered completed apps or web services to users. Users used those finished products as-is.

Future software companies will sell components. Think payment functionality, authentication, maps, chat, delivery tracking, booking systems, and payment settlement. These capabilities will be offered as independent modules, and users (or their AIs) will assemble them to build their own services.

The pioneers of this model already exist. And they happen to be among the most highly valued companies in the software industry.

Stripe provides payment functionality via API. Stripe doesn’t build its own shopping mall or payment app for end users. Its model is: if you need payments, use our API. Twilio provides SMS, voice calls, and video calls as APIs. Auth0 provides authentication. Mapbox provides maps. Algolia provides search.

What do these companies have in common? They don’t build their own client-facing services. Instead, they implement specific capabilities at the highest level and provide them in a pluggable form for other services. What they sell isn’t an app - it’s a capability.

I believe this could be the future of the software industry. This is, of course, my prediction. I won’t go so far as to claim every software company will transform this way. But I think the time could come when a significant number of companies will need to redefine their business model from selling finished products to providing capabilities.

The essence of this transition isn’t about what you sell but about who you sell to. Stripe’s customers aren’t end consumers - they’re developers. When a developer chooses Stripe, millions of end users naturally transact through Stripe. In the future, this structure extends one layer further. The customer isn’t the developer but the AI agent. When an AI determines payment functionality is needed, it automatically selects and integrates the most suitable module. A company’s marketing target shifts from humans to AI. Strange as it sounds, this could become reality.

Think about it. When you tell an agentic coding assistant “Build me an online store with payments,” the AI will build a store integrated with the Stripe API. Say “Add real-time chat” and it will plug in an existing chat SDK. “Show store locations on a map” and it will integrate a maps API. The AI isn’t implementing everything from scratch - it’s assembling well-built capability modules.

What holds value in this structure? Not the finished app, but the individual capability modules that compose it.

Think of processing payments safely and conveniently, real-time communication that handles millions of simultaneous connections, accurate and fast map rendering. These are things non-developers can’t easily build with AI alone. They require deep expertise, infrastructure, and economies of scale.

A critical reversal happens here. In the past, companies told users: use our app. In the future, companies will tell users (and their AIs): use our capability. The relationship with users shifts from B2C to B2B2C, or more precisely, B2AI2C.

The Block-Assembly Service Ecosystem

When the module economy takes off in earnest, the very way software is built will fundamentally change.

Today, building a service means either implementing everything from start to finish yourself, or building within the constraints of a single platform. But in the module economy, you assemble services like Lego blocks.

The payment block comes from Stripe, the authentication block from Auth0, the map block from Mapbox, the search block from Algolia. Add your own business logic, and you have a complete service. This assembly process can be done by a human or by AI.

In this kind of ecosystem, new forms of marketplaces will emerge. If app stores were marketplaces for finished apps, the marketplace of the future could be one that trades capability modules. Whether built by companies or individual developers, specific capabilities will be packaged as modules and published so that other users can assemble them into their own services.

Think of package managers like npm or PyPI. Right now, only developers use this ecosystem. But with agentic coding assistants acting as interpreters in between, non-developers can tap into it too.

Tell an AI “Add payment functionality to my app” and the AI finds the right payment module and integrates it.

This raises another interesting question. In such an ecosystem, what are the most valuable modules?

I see two types. The first is capabilities with infrastructure-level complexity. Payment processing, authentication, real-time communication, media processing, and search engines all belong here. Implementing these properly requires enormous expertise and infrastructure. A non-developer asking AI to “build a payment system from scratch” won’t be able to handle financial regulations, PCI DSS compliance, fraud detection, or multi-currency processing. Specialized companies providing these as modules makes overwhelmingly more sense.

The second is domain-specific capabilities. Examples include electronic prescription systems in healthcare, delivery route optimization engines in logistics, risk assessment models in finance, and learning progress tracking systems in education. These require deep domain knowledge and regulatory compliance for specific industries. Non-developers can’t easily implement these with AI alone either. But if specialized companies provide well-built modules, even non-developers can integrate them into their services.

Ultimately, the software companies of the future will need to evolve toward building deep expertise in one of these two types and delivering it as modules.

There’s one more thing to consider. Module quality will be evaluated on an entirely different dimension. Until now, software quality was primarily judged by feature completeness and UI polish. But in the module economy, different criteria matter. Is the API design intuitive? Is the documentation thorough? Are error messages clear enough for AI to understand? How well does it play with other modules? Does it maintain backward compatibility across version updates? These factors will determine a module’s competitiveness.

This reshapes the very capability structure of software companies. If frontend designers and UX specialists were key talent in the past, module companies will need API architects, documentation writers, and DX (Developer Experience) specialists as their core team. And going forward, it might not be DX but AX (AI Experience) - the ability to design experiences that are easy for AI to consume - that becomes the critical competency.

The Era of Plugging Directly Into AI Agents

There is one more current worth tracing within this picture of the module economy. The very channel through which capabilities are exposed to the outside is changing.

The API economy as we have known it has, at its core, been aimed at developers. Stripe, Twilio, Auth0 - all of them required a human developer to install an SDK, generate keys, and write code before anything would run. From a user’s standpoint, there was no occasion to even notice that those modules were running underneath. The recently emerging MCP (Model Context Protocol) shifts this structure one step further. It is a protocol that standardizes how an AI agent talks to external services so it can call them directly. Without going through a human developer, an assistant like Claude or ChatGPT picks the right capability from its connected tool list and executes it on the spot. The future this piece has been describing - AI assembling modules - is no longer an abstract metaphor but is settling into a concrete implementation mechanism.

For companies, what this shift means is unambiguous. Exposing your core vertical service as an MCP server becomes equivalent to opening up a new distribution channel. Domain-specific capabilities like flight booking, hotel reservations, food delivery, financial transactions, medical record lookups, real estate listings, or course enrollment - if you wrap them in MCP, users no longer have to launch your app to use them. They invoke your service from inside whatever AI assistant they happen to be using. When a user says “Book me a KTX to Busan this Saturday and grab a hotel near Gwangalli too,” Korail’s MCP and a hotel booking service’s MCP get called together, and both transactions wrap up inside a single conversation. This kind of scenario is no longer a stretch of the imagination.

What is interesting is that this same channel is wide open to non-developer individuals. From the perspective of the build-your-own-app users we discussed earlier, MCP is the most natural way to attach external capabilities to that app. The freelance translator who builds a workflow management app can hand payments off to a Stripe MCP, invoice delivery to a mail service MCP, and exchange rate lookups to a financial data MCP. The point I made earlier - that the consumers of the module economy expand from people alone to AI agents - shows up most clearly right here. The buyer of capability modules flows from developer to AI, and through that AI back down to ordinary individuals.

Once a company recognizes this shift, the strategic question is no longer “how do we get users into our app.” It becomes “how do we get our service into every AI assistant’s tool list.” Adding more channels through which users consume your service without ever opening your app stops being a threat and starts looking like an opportunity. The deeper you embed your service inside an AI assistant’s tool list, the more likely a user is to encounter your service no matter which interface they came in through. Conversely, companies that fail to ride this wave will hand their entire user touchpoint over to AI assistants and find themselves reduced to a backend data store. The moment an AI is talking to the user directly, a service that does not appear anywhere in that AI’s tool list effectively does not exist.

In my view, this is the most practical conclusion of the whole module economy argument. We are entering an era where it is no longer enough to abstractly turn your capabilities into modules - you also have to design which AI agent’s mouth those modules end up inside. If the corporate task of the past 20 years was getting onto the first page of search results, the task ahead is getting into the tool list of AI assistants. Just as being absent from search results meant being invisible to users, being absent from the AI tool list now means never being called by users at all.

What Survives and What Fades

Not every software service will be replaced by modules. It’s important to distinguish what survives from what’s at risk in this transformation.

What survives.

First, services where network effects are core. This category includes social networks and messaging platforms like KakaoTalk, Instagram, YouTube, and LinkedIn. The value of these services isn’t in their features - it’s in the fact that other people are there. No matter how good a messenger I build, it’s meaningless if my friends aren’t on it. Network effects are a barrier to entry that individuals cannot replicate.

Second, services where massive data is the source of value. Google Search, Google Maps, Spotify, and Netflix are prime examples. Their value lies in data assets: billions of indexed web pages, global road and location data, tens of millions of licensed songs, tens of thousands of video titles. These data assets cannot be replicated by individuals.

Third, cloud infrastructure. Cloud platforms like AWS, Azure, and GCP fall into this bucket. Even when users build their own apps, those apps need to be hosted somewhere. Demand for server infrastructure may actually increase. If everyone builds their own app, the total volume of apps needing hosting explodes.

Fourth, AI platforms themselves. AI model providers like OpenAI, Anthropic, and Google belong here. These companies provide the core engines of agentic coding assistants. They are the infrastructure on top of the infrastructure in the module economy. The more users build services through AI, the more value AI platforms accrue. They are the biggest beneficiaries of this paradigm shift.

What’s at risk.

First, simple CRUD apps. To-do apps, note apps, habit trackers, budget trackers, and journal apps all fall in this category. The core features of these apps can be easily replicated by AI. When users can build their own tailored versions, the reason to use a general-purpose app diminishes. The fact that searching to-do app on app stores already returns thousands of results is evidence this market is oversaturated. Add infinite customization as an option and survival for existing to-do app companies becomes extremely difficult.

Second, small and mid-sized SaaS products. Niche SaaS whose only differentiator is a convenient interface or all-in-one feature bundle are especially exposed. The value proposition of these services is something agentic coding assistants can replicate.

Third, ad-supported free apps. As discussed, when users can build their own ad-free apps, the incentive to endure ads in free apps disappears.

Fourth, simple wrapper services. These are services whose entire value is a pretty interface layered on top of existing APIs. Since AI can create interfaces, the value of this intermediary layer decreases. In fact, many wrapper services are already being hit by AI’s emergence. Services that charged monthly subscriptions for a thin UI on top of AI APIs are losing their reason to exist as users gain the ability to call APIs directly.

Fifth, large portal-style conglomerates. Operators that bundle search, mail, news, shopping, maps, payments, and finance into a single app and portal fall into this category. Their value proposition has rested on the all-in-one convenience of solving everything in one place, but once the user touchpoint shifts to the AI assistant, the meaning of that bundle itself weakens. Instead of entering a portal and picking from a menu, users state their intent to the AI in natural language, and the AI calls the most suitable service (an MCP server or tool entry) and returns only the result. Traditional assets like the portal home page, recommendation slots, ad inventory, and menu structure are bypassed wholesale, and the revenue structure built on advertising and traffic funneling shakes along with it. The advertising-model crisis discussed earlier applies just as well at this giant-corporate scale. The likely outcome is that these companies cede the user touchpoint to AI assistants and retreat into being backend data warehouses and single-purpose module suppliers. Some areas with clear moats such as network effects or massive data will survive, but the value proposition of being merely an all-in-one bundle can no longer hold its ground.

The essence is this: services with irreplaceable assets survive, while services whose value is purely functional are at risk. Network effects, massive data, deep expertise, and physical infrastructure are the assets in question. These cannot be replicated by AI. But features built in code can be.

Survival Strategies for Companies

What strategies should companies that recognize this shift adopt?

First, transition from service provider to capability provider. Move from a model of delivering end-user services through proprietary apps and websites to a model of providing core capabilities as APIs, SDKs, MCP servers, and modules. Companies need to identify what their deepest expertise is, modularize it into independently usable components, and expose it through channels that both humans and AI agents can call.

Second, design AI-agent-friendly interfaces. The user of the future may not be a person but an AI agent. Exposing your capabilities over a standard protocol like MCP so that they enter the tool list of major AI assistants becomes the most concrete task of this era. On top of that foundation, APIs must be designed so that AI can automatically search, evaluate, and integrate modules. Well-organized documentation, clear error messages, and available test environments become table stakes. These will become the criteria by which AI agents select capabilities.

Third, build irreplaceable assets. Features written in code can be replicated. But data accumulated over years, compliance with industry regulations, a track record of reliability, and partner networks cannot be easily copied. Companies must deliberately build these irreplaceable assets.

Fourth, modularize domain expertise. If a company has deep understanding of a specific industry, packaging that understanding into code becomes a powerful strategy. Think of a patient data management module that fully complies with healthcare regulations, a transaction processing engine that meets financial regulations, or a delivery management SDK equipped with logistics optimization algorithms. The combination of domain knowledge and technology creates the highest-defense moat.

Fifth, pursue an ecosystem strategy. Rather than trying to build a monopolistic platform, aim to be the best component in an open ecosystem. Many companies have pursued the do everything on our platform all-in-one strategy. But in an era where users assemble their own services, being the best at a specific capability and fitting seamlessly into any combination is more advantageous. Stripe’s hold on payments is a textbook example of that positioning.

One principle runs through all these strategies: the shift from building for to enabling. In the past, companies built services on behalf of users. Going forward, they transition into helping users build for themselves. Providing ingredients rather than finished dishes. Selling raw materials rather than recipes. This shift in perspective may be the hardest part. For a company that has operated for 20 years with the mindset of we’ll build the best app and deliver it to you, declaring we’re becoming a component supplier is partly a matter of pride.

But pride that runs against the market’s direction is a luxury.

This Transformation Has Already Begun

This might sound like a story about the distant future. But the change has already started.

The concept of the API economy has existed for years now. Stripe, Twilio, Auth0, SendGrid, Cloudinary, and Algolia are the names that come to mind. These companies are already succeeding with a sell capabilities business model. They’re not from the future - they’re models validated in today’s market.

What’s changing is the scope of this model’s application. In the past, the consumers of capability modules were developers and companies. Technical skills were needed to integrate APIs and incorporate SDKs. But as agentic coding assistants lower this technical barrier, the potential consumers of capability modules expand to everyone.

A marketer will be able to tell an AI: “Build me an email marketing automation tool. Use SendGrid for sending emails and Stripe for payments.” A small business owner will say: “Build a reservation system for my shop. Send KakaoTalk notifications and accept payments.”

The AI combines the right modules to build the service.

This is both an expansion and an opening up of the API economy. The module ecosystem that was accessible only to developers is being opened to everyone through AI.

And this opening up creates a feedback loop. As the number of module consumers grows, so does the number of module providers. As more capability modules emerge, the variety of services AI can assemble expands. As the variety expands, more users think I could build something too. Once this virtuous cycle kicks in, the module economy accelerates.

Addressing the Counterarguments

Some readers may push back at this point.

“Most users are too lazy to build their own. It’s easier to just download an existing app.”

True. For now. But that’s because the UX of agentic coding assistants isn’t simple enough yet. Building an app still requires crafting prompts, checking results, requesting modifications, and going through deployment. It’s far more cumbersome than tapping a download button on the app store.

But this friction is steadily decreasing. What happens when you say “Build me a budget app” and it’s installed on your phone in 30 seconds? If that’s faster than searching for budget apps on the app store, comparing ten options, downloading one, creating an account, and configuring settings? When that moment arrives, too lazy no longer holds as a counterargument.

“Existing services have years of accumulated know-how and data.”

This is partially true. But how much value that know-how actually delivers to users deserves scrutiny. In many cases, a service’s know-how is really know-how about how to keep users engaged longer or how to increase paid conversion rates - not how to solve users’ problems better. Apps built by users themselves have no dark patterns, no artificial restrictions, and can focus purely on solving their own problems.

These counterarguments aren’t entirely wrong. But they don’t dispute the direction of change itself - they’re merely debates about the speed of change. And in the history of technological advancement, the side that underestimates the speed has almost always lost.

A Paradigm Shift in the Software Industry

Let’s zoom out to the big picture.

For the last 20 years, the software industry has operated on the model of delivering finished services directly to end users. Upload an app to the app store, open a website, acquire users, and monetize through ads or subscriptions. The core premise of this model was: users can’t build it, so we build it for them.

agentic coding assistants are undermining that premise. When users can build things themselves, the value of the we build it for you business model diminishes. The future I see is a world where selling components makes more sense than selling finished products.

This is similar to what already happened in manufacturing. In the past, buying furniture meant buying a finished product from a furniture store. Then IKEA came along and started selling components. Consumers could assemble them, getting cheaper products and combinations that matched their taste. With 3D printers becoming widely available, you can now even make the components themselves if you have the design files.

The software industry is following a similar trajectory. It’s moving from the era of finished products to the era of semi-finished goods (modules), and ultimately to an era where users build everything from scratch alongside AI. The final stage will take time, of course. But the transition to the intermediate stage - the module economy - is already right in front of us.

There’s a positive side to this transition as well. The idea that everyone can have software tailored to their needs means software is no longer the exclusive domain of a select few. Until now, software has had a separation between makers and users. That separation is dissolving. Not everyone becomes a developer, but every user becomes the owner of their own software. Instead of adapting to features and interfaces decided by companies, people define software that fits their own lives and work.

This may be the biggest shift in computing paradigms since the PC revolution. If PCs put computer use in everyone’s hands, agentic coding assistants are putting the act of telling computers what to do in everyone’s hands.

In the previous piece, I wrote: “I want to ask developers: does your value lie in the act of writing code, or in the problems you solve with it?” This time, I’m posing the same question to software companies.

Does your company’s value lie in the act of building and distributing apps, or in the core capabilities and expertise contained within those apps?

An era where anyone can build an app is coming. But the payment systems, authentication frameworks, and domain-specific logic inside those apps cannot be built by just anyone. I believe the companies that can build those things will be the winners in the module economy.

Just as the age of developers has changed, the age of companies is changing too. I predict that the era of building and selling client services will fade, and the era of providing core capabilities as modules will take its place.

As I asked developers in the previous piece, I’ll pose a question with the same structure here. Is your company an app-building company or a problem-solving company? An app is just a tool. Tools can be replaced. But deep expertise and trust cannot.

Only the companies that recognize and prepare for this transition will survive in the next age. And to be frank, this transition will arrive far sooner than most companies think.