When we shipped an MCP server for GoodBarber a few weeks ago, I’ll admit I filed it mentally under “nice for the AI-power-user crowd.” An open protocol that lets an AI assistant drive your app by conversation: clever, on-trend, probably niche.
I was wrong, and the way I was wrong turned out to be more interesting than the feature itself. Two things surprised me. One is about how we build. The other is about who showed up.
Talking to a SaaS instead of clicking through it
The first thing is easy to describe and hard to unsee once you’ve felt it. Instead of opening a back office, finding the right screen, and filling the right fields, you say what you want in a sentence and it happens. “Publish this event for Saturday.” “Send Tuesday’s update to iOS users, in their local time.” The MCP server does the clicking.
It sounds like a convenience, and it is. But there’s a second-order effect that took me a while to notice.
We shipped the capability before we built the screen
Here is the part I keep thinking about.
Normally, shipping a feature means two jobs: building the capability (the API that does the thing) and designing the interface for it (a screen a non-technical person can understand and use without a manual). The second job is often the slow one. Some actions are genuinely hard to make simple. Push notifications are a good example: between platform, audience segment, a specific user, local-time scheduling, and where the tap should land, the options multiply fast. A screen that exposes all of that without overwhelming people is a real design problem, and it takes time.
With MCP, the capability can ship the moment the API exists, because the interface is a sentence. “Send this to users who opened the app in the last 30 days, on Android, at 9am their time, and open this article when they tap.” You don’t need a form for that. Language absorbs the complexity a fixed screen would struggle with.
So we shipped targeted push through the MCP server before we finished the back-office screen for it. The capability was ready, the good UI wasn’t, and for once that didn’t have to hold the capability hostage. That reframes MCP for me. It isn’t only a faster way to operate an app. It’s a way to put a capability in people’s hands before, or sometimes instead of, designing the screen it would otherwise need.
The people who showed up
The second surprise was who used it.
I expected a handful of tinkerers, and instead the line kept climbing. In the first week, around 20 apps tried it. By the end of the month, 71 had, and new ones kept turning up every week, not just at launch. Volume moved the same way: setting aside one agency that runs a large portfolio (agencies live in repetition, which is exactly what a conversational layer removes), weekly use grew about 3× from the first week to the last, and the back half of the month ran at about 3× the front.
What they do with it is telling. About 84% of the calls are content work: publishing articles and events, building map sections, updating paragraphs. Push comes next. E-commerce barely registers so far. And half of all the calls write something rather than just read, so people aren’t browsing their app, they’re running it, and they’re doing it from the same chat app they already use, not a terminal. The targeted push we shipped without a screen, for what it’s worth, gets used more than the simple broadcast.
None of this is a hockey stick. It’s a month of steady, widening use by people doing real work, which convinces me more than a spike would.
What I think it means
I don’t think the back office is going away. Screens are still the right interface for a lot of things, and most people will keep clicking. But I’ve stopped seeing the conversational layer as a novelty bolted on the side. It behaves more like a second, permanent surface on the product, one that’s especially good at the things screens are bad at: many-parameter actions, one-off requests, work you’d rather describe than navigate.
The question it leaves me with isn’t “will people talk to their software.” Some already do. It’s a design question: which capabilities are better expressed in words than in screens? For anything meant to last, that’s worth getting right, because it quietly changes what “shipping a feature” means. Sometimes it means building the screen. Sometimes, now, it means not having to.
If you run software and you’ve opened this door, I’m curious what your users actually do on the other side of it. And if you were going to give one action of your product a voice before its screen, which one would it be?