Mark OomsFor most of the history of software, the interface was the expensive part. Someone had to decide up front which screens there would be, which fields, which buttons and in what order, and everyone who used the tool afterwards lived inside that decision. That made sense. If building a screen takes a sprint, you build one screen for everybody, and you think hard about it before you start.
I've been thinking about this a lot lately, because inside companies something slightly odd is happening. Everyone can build now. People who have never written a line of code are vibe coding tools in an afternoon, and a good share of those tools are genuinely useful. But almost all of them take the same shape: a login, a few screens, a database, a URL you can pass around. An app. Not because the problem asked for an app, but because that's what software looked like when we learned what software looks like.
An app is a decision made on someone else's behalf
When you build an app, you decide for everyone who will use it later how they're going to look at the information inside it. Which questions they can ask, which filters exist, what's on the first screen and what's hidden three clicks deep. When software was expensive, that was a reasonable trade: one carefully designed interface, shared by many people, paid for once.
But the person vibe coding an app on a Friday afternoon is making those same decisions, quickly, based on their own way of working. Everyone else inherits them.
Imagine someone builds a small dashboard that shows which projects are running over budget. It's useful, so people start using it. Then one manager wants to see it per team instead of per client. Another only cares about projects where the margin dropped this month. A third wants it next to the hours that haven't been invoiced yet. Every request is reasonable and every request becomes a feature, and a few months later the dashboard has turned into a small, slightly awkward product with one maintainer, a backlog, and a group of users who each use about a fifth of it. If you could see the usage numbers, you'd probably find a big spike in the first week and a slow decline after that, until one loyal person is still opening it on Monday mornings.
None of those managers actually wanted a dashboard. They wanted an answer to a question about the same data, and each of them had a slightly different question.
What changes when the interface is cheap
This is where artifacts start to matter, and I think they matter more than most people realise. In Claude you can ask a question about your data and get back a small working interface built for exactly that question, instead of a wall of text. A chart with the filter you asked for, a table you can sort, a little tool you can click through. If you want it differently tomorrow, you ask differently. The person next to you asks for something else and gets something else. Nobody had to agree on what the screen should look like, because there isn't a single screen anymore.
That's a strange idea if you grew up with software as a fixed thing. The interface stops being the product and becomes something closer to a sentence: produced at the moment you need it, shaped by the question, and fine to throw away afterwards. What lasts is the layer underneath. The data, the rules about who is allowed to see what, and the context the assistant already has about you and your work.
That last part is underrated, I think. A separate app knows nothing about you beyond what you type into its search box. An assistant that already knows which project you're on, what's in your calendar and what you discussed in this morning's meeting can take a much vaguer question and still do something useful with it. You don't click through filters to find a colleague with the right experience. You describe what you're about to do, and it works out who you should talk to, and maybe proposes a time that fits both your agendas while it's at it. Every new app pulls a little bit of work out of that shared context and into its own separate room, where you have to explain yourself again from scratch.
I notice it in how I work myself. I spend a large part of my day simply talking to Claude, and I open other tools less and less. Not because those tools are bad, but because asking for something has quietly become faster than navigating to it.
What should still be an app
I don't think the answer is never. Some things need a fixed interface precisely because it's fixed. When a management team looks at the same report every Monday, part of the value is that they're all looking at the same thing, and a personal view for each of them would undermine the shared picture they're trying to build. When customers or other people outside your organisation need to use something, you can't assume they have your assistant, your data access or your context. When a process has to run on its own in the middle of the night, there's no conversation in which an interface could be generated. And sometimes clicking a button really is nicer than typing a sentence, which is a perfectly legitimate reason as well.
So I've started asking the question differently. Whether we can build something is no longer interesting, because the answer is almost always yes. The more useful question is whether this interface needs to be the same for everyone, and stay the same over time. If it does, then freeze it, build the app, and give it everything an app deserves: an owner, a proper place in the company's codebase, access control that someone has actually thought about, and a person who fixes it when it breaks. If it doesn't, then building an app means freezing something that would have been better left fluid, and the company ends up paying the maintenance cost of a decision nobody needed anyone to make.
For that second category, the real work isn't building apps at all. It's the less visible work underneath: making company data reachable through one well-guarded connection, with permissions that follow the person asking, and then offering skills and artifacts on top of it. That layer is terrible to demo. It's also what makes it possible for twenty people to each get the interface they need without anyone having to maintain twenty codebases.
Where I'm not sure
There's a version of this argument that is too neat. Not everyone wants to talk to an AI to get their work done, and I tend to forget those people exist because I'm not one of them. Working together on artifacts is still clumsy; changing something a colleague made often means rebuilding their context before you can make a sensible edit. And moving everything into one assistant creates a dependency on one vendor, which is something a company should decide on deliberately rather than drift into.
I might also simply be wrong about how fast this goes. But when I look at how people inside companies are building right now, I see a lot of energy going into recreating the shape of software from ten years ago, including all the maintenance that comes with it, at the very moment that shape is becoming optional. I don't think the most useful thing a product person can do there is say no to people's ideas. I think it's to ask, for each idea, which part of it actually needs to be fixed in place, and which part could just as well have stayed a question.