Yes, this is a long one, but I promise it's worth it.
In my journey as an interface developer, I've noticed how easy it is to confuse the screen with the product. The screen is what everyone sees: it's what shows up in the demo and what you can put in a presentation. That's why, when someone wants to improve a service with technology, the first impulse is almost always to build a screen.
And that's where a common trap for service businesses begins.
It starts with good intentions. The business owner wants to give clients a better experience and builds a client area. Then a dashboard. Then exercises. Then gamification. Then reports. Then settings. Then dozens of features.
By the time they notice, most of their effort goes into building and maintaining software. And now the client has to learn how to use the product.
They stopped using software to deliver a better service and started selling software.
Two different businesses
The difference is clearer in two sentences:
- SaaS: "I give you a tool so you can do the work."
- Service: "I deliver the work, and software is the infrastructure."
SaaS is software as a service: you pay a subscription, usually per user, and you use the tool. The result depends on you using it well.
With a service, you pay someone to deliver a result. Whether they use a spreadsheet, their own system or AI is their problem.
This distinction gained weight with AI. In 2024, Sequoia Capital described in Generative AI's Act o1 a shift they called service-as-a-software: companies that, instead of selling access to a tool, sell the work itself and charge for the outcome. Their thesis is about software companies doing work that used to be done by people.
In 2026, Julien Bek, also from Sequoia, shared a number that helps explain why this bet is so big: for every dollar spent on software, six are spent on services. Investors are looking at services because that's where most of the money is.
My concern here is the opposite path: service businesses that turn into software companies without noticing.
How the trap happens
Picture a personal training business. One trainer, a handful of clients, a method that works because he follows each of them closely.
He decides to build an app for his clients. It makes sense: workouts are organized in one place. Then a client asks to log weights. Another wants to see progress in a chart. A competitor has a leaderboard, so why not. Then come notifications, smartwatch integration, a video library, meal plans...
Each feature, on its own, is reasonable. That's the problem. Nobody decides to become a software company. The decision gets made one feature at a time.
A year later, the trainer spends his evenings answering bug reports, paying developers and thinking about the roadmap. The client, meanwhile, opens the app, looks at the chart and decides alone what to do. The close follow-up, the whole reason to hire that trainer, became a "talk to your coach" button in the corner of the screen.
Neither model is wrong. Selling software can be a great business. The problem is ending up there without having chosen it. Along the way, the differentiator, which was the expert, fades into the background, and you start competing with companies that only do software, with teams and budgets a service provider rarely has.
And there's an irony in that. If Sequoia's number is right, whoever falls into this trap leaves the bigger market, services, to fight over the smaller one, software. Right when AI is starting to make services more scalable.
Who is working for whom?
The question I use to figure out which side I'm on is simple: who is working for whom?
If the software works for the expert to deliver the result to the client, it's a service with good technology.
If the client has to work inside the software to produce their own result, it's SaaS, even if you still call it a service.
There's an important nuance. In many services, the client will always have to do their part. Nobody gets fit by proxy, and nobody learns a language without speaking it. The effort belongs to the client. What they shouldn't have to do is manage that effort: noticing where they're stuck, deciding the next step, remembering what has already improved. In an app, that work is on the user. In a service, it's on someone else.
The interface is a window, not the product
As someone who spends a good part of his time building interfaces, I say this with no prejudice at all: interfaces aren't the problem. The client can have their own area, and the expert can have a dashboard. There can be history, content and progress charts.
I once built an analytics platform for the clients of an energy company. Nobody there was buying the platform: the clients were buying energy and the management of their assets. The platform was how they kept track of it. When it works like that, the interface makes the service more visible instead of taking its place.
The difference is what the interface is for. The dashboard shouldn't be the product; it's a window into the service. The product is still the result the client paid for.
A test I like: if the client goes a week without opening the platform, does the service keep happening?
With SaaS, it doesn't. If you don't open the app, nothing happens. With a service, it does: someone notices you've gone quiet, figures out why and adjusts the plan.
This is where AI gets interesting for service providers. It can do a lot of the invisible work, like analyzing, organizing, summarizing and suggesting the next step, and leave the expert with what only they can do. It's technology working behind the service, not one more screen in front of the client.
Before adding the next feature
A few questions that help keep the decision a conscious one:
- What is the service's promise, in one sentence? If the new feature doesn't improve that promise, it's building a different business.
- Does this take work off the expert or put work on the client? The first usually means service. The second usually means product.
- Can it be tested manually first? Much of what becomes a system could start as a manual process, with a spreadsheet and a bit of AI, and only get automated once it proves its worth.
- Who's going to maintain this a year from now? All code needs maintenance and support, and it costs money even after it's done.
If the answers point to product and that's what you want, great: now it's your choice, not an accident.
The question that changes
For years, the question was: "How do we turn this service into software?"
Maybe now a more interesting question is: "How do we use software to make this service ridiculously better?"