“There’s an app for that.” In 2009, Apple started using this phrase in their TV ads and it quickly spread beyond just the iPhone App Store context. People realized that instead of scary computer programs running on PCs, with visible files and folders that needed to be managed via Windows Control Panel, you could just have a simple thing that works.

Of course apps are about files, too. And often they rely on servers running somewhere, resulting in a web of complexity and dependencies. But those complexities were hidden away from the app user. All they saw was an icon to click and a graphical UI to work with. The less buttons visible, the better the app was often perceived to be. It was simple and secure because it offered fewer things for the user to worry about.

We’ve been turning systems into apps ever since. Not just compressing them into a format that fits a touch-screen on a smartphone device. Web apps today often behave like they were a giant phone app, just used on a big monitor and clicked with a mouse cursor instead of your thumb. The expectation has been that the more the UX of a business solution resembles a consumer-grade iPhone app, the more it will get adopted and used, thus driving positive ROI and making the world a better place.

I don’t think this is going to be true for much longer.

I feel we are getting close to a moment when the applification of everything turns on itself — if it hasn’t already happened. The reason is AI, but not in the way vendors like Microsoft claim it is redefining the future of work. Because Copilot is also one type of a wall that keeps the users from getting to where the true value lies: data and code.

For two years now, I’ve been using Microsoft 365 Copilot. I’ve been waiting for it to eventually get better at supporting my real work tasks. So far, the only must-have feature that I’d truly miss is the Teams meeting transcripts that Copilot can work with on the fly. Yet that is also a wall that limits the usefulness of AI, the moment you need to cross a tenant boundary. “Oh, this meeting request is from another M365 tenant, guess I won’t have access to any Copilot related features then.”

Apart from the meeting transcript processing, none of the AI features that are constrained to be inside apps have proven to be particularly useful. An independent AI chat from a neutral LLM vendor has almost always triumphed in the everyday scenarios that I’ve had to work in. This is somewhat surprising, given how initially many of us assumed “if only I could use this ChatGPT thing but make it aware of what my app sees, I’d be much more productive with AI”.

Yet reality has proven that these app islands typically preserve walls that prevent AI from being able to truly work on the data like a human user can. For example, even when Microsoft launches features like Agent Mode in Excel, they are confined to the context of a single app. If I’m chatting about something in M365 Copilot, there is no way for this AI to create Excel workbooks in the cloud, nor modify any existing workbooks in there:

Sure, Excel on the web exists in the Microsoft cloud. It’s just another browser tab that I could open and work with. From a GUI perspective, it has been logical that all the millions of features that the M365 cloud contains are not just lumped in one place. Similarly, it made sense not to bring everything that Excel on your PC can do to the Excel on your iPhone screen. The app was what a human user preferred.

The context window of a human being is dramatically different from that of a frontier AI model. LLMs learn nothing while being prompted, yet they can process big chunks of seemingly arbitrary data with ease. Paste it in there and the magic box will organize it for you. Humans are the opposite: we learn in our own ways from every event in our lives (and unlearn/forget, too), we just have a hard time keeping a six-digit PIN code in our working memory when needing to enter it from one app screen to another.

What makes humans productive is what destroys the productivity of LLMs. This explains why your typical apps have prioritized the “build big buttons and pretty charts” features over something that we’d need today for AI. One recent example was the MobilePay app used widely here in Finland (our equivalent of Venmo), which I discovered to not have any “export as .CSV capability, nor a web app. I could have either exercised my GDPR rights and wait for a big data dump, or do things right away — meaning take 14 screenshots and paste them to Claude’s chat prompt for constructing the CSV:

I’m sure more and more regular people are running into such limitations when using consumer-facing apps. Yet it’s on a whole different level when dealing with an abstraction layer built to hide away code for business applications — meaning Power Platform.

This week, I have spent far too much time looking at Power Automate cloud flow editor screens like this, waiting for the configuration data to appear (or not):

What initially made Power Automate so easy for citizen developers to approach was that it offered a simple-looking GUI for “if-this-then-that” logic, readily available M365 connectors, and a bunch of templates to use. You didn’t need to design a full app UI and worry about user interaction patterns like with Power Apps canvas apps. As a result, every customer tenant I’ve ever analyzed as part of Power Platform governance model development work has had way more flows than apps created by business users.

But once you go beyond the template scenarios of “when a SharePoint item is created, send email”, oh boy does it get painful awfully fast. And it’s mostly thanks to the app - meaning the GUI that is offered for managing flows. It has always felt to me more like an obstacle rather than an enabler. You’re constantly hunting for information that you know you need, but what the GUI doesn’t offer. Even when you know what you want to do, there’s no efficient path to getting it done. Death by a hundred clicks and scrolls — and waiting for the UI to hopefully load the screen.