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. How agentic coding assistants have democratized the act of writing code, 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. 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. 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. The 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.
A general-purpose to-do app used by 500,000 people versus 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, calendar managers. The core functionality of these apps is creating, reading, updating, and deleting data. Precisely the area where agentic coding assistants excel.
Think about the business model of companies running these apps. Most use freemium. Free basic features, monthly subscription for premium ones. 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. Artificially segmenting features to justify a subscription model, restricting core functionality in the free tier, creating premium features designed 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, countless free apps and services. Their business models are fundamentally the same. Provide a free service to users and sell those users’ attention to advertisers. 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.
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. Payment functionality, authentication, maps, chat, delivery tracking, booking systems, 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.
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 are packaged as modules and published, and other users 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, search engines. 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. Electronic prescription systems in healthcare, delivery route optimization engines in logistics, risk assessment models in finance, 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.
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. 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, Netflix. 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. 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. 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, journal apps. 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. SaaS targeting specific niches whose differentiator is a convenient interface or all-in-one features. 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. 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.
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, physical infrastructure. 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, and modules. Companies need to identify what their deepest expertise is and modularize it into independently usable components.
Second, design AI-agent-friendly interfaces. The user of the future may not be a person but an AI agent. APIs must be designed so that AI can automatically search, evaluate, and integrate modules. Well-organized documentation, clear error messages, and available test environments. 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, module domain expertise. If a company has deep understanding of a specific industry, packaging that understanding into code becomes a powerful strategy. A patient data management module that fully complies with healthcare regulations, a transaction processing engine that meets financial regulations, a delivery management SDK equipped with logistics optimization algorithms. The combination of domain knowledge and technology creates the highest-defense moat.
Fifth, 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. Just as Stripe has claimed that position in payments.
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, Algolia. 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 a democratization of the API economy. The module ecosystem that was accessible only to developers is being opened to everyone through AI.
And this democratization 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. 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 represents the completion of software democratization. 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 democratized using computers, agentic coding assistants are democratizing telling computers what to do.
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.
Leave a comment