Service as Software
How the world is eating software as we know it
It’s 2025 and the technology world is changing rapidly.
This is going to be a tough one, so brace yourselves.
We see a rise of no-code tools and automation platforms such as n8n, and vibe-coded solutions supported by prototyping tools (Lovable) and GenAI-integrated IDE tools (Windsurf, Cursor) - the timespan between idea and execution becoming smaller every day. With this fleeting timespan comes a fleeting interest in generic off-the-shelf vendors to address our needs for software-supported operations.
This trend correlates with a growing market fatigue towards B2B SaaS products, both generic and specialized ones. After a post-Covid cycle of price increases, many SaaS offerings have reached customers' willingness-to-pay threshold and have become targets for cost optimization.
What once served as an ideal ecosystem for venture capitalists to "spray and pray" investment strategies is now slowly falling out of favor with both its customer bases and investors alike.
For the founders, this presents a real challenge as valuation multiples are not based on projected success anymore, but hard bottomline numbers of revenue, revenue growth and profitability. Perceived value of IP has dropped significantly as it’s the actual market volumes acquirers are going after.
In the mean time, Big Tech is going for its n-th iteration of layoffs, now somewhat disguised as a side-effect of AI adoption, but what we are actually seeing is the opposite of the age-old dream of “Software Eating the World”: instead the world is going after Service.
We all use products every day, but the ones we specially care about are where the product doesn’t stand in the way of the value it provides: the data it manages for us, the processes it supports, the relations, trends and correlations it reflects, its networked community of all-day-working users. As much as products have evolved into platforms, their entry tickets to access have stayed primarily within the selfish dimensions they find it easiest to reason about: number of seats, data volumes, transactions. But what about actual workload they take care of?
Despite good intentions around value-based selling, very few products dare to price themselves based on actual outcome or value they provide to customers. Instead, many software vendors focus primarily on expansion or upsell strategies and are sticking with overly sophisticated and convoluted pricing models.
These approaches create misaligned incentives, with many vendors hiding actual consumption-based costs away until the next billing or contract renewal cycle. The fundamental problem is clear: old-school vendors want to be pre-paid for post-usage value, while the market increasingly demands the opposite arrangement.
So, enter Service as Software. As a customer, you buy Service, run by software. But the latter remains purely the supplier’s concern. With the right level of automation, the service can be provided in a differentiated, efficient and profitable way.
As the software landscape by itself is continuously changing, customers have become increasingly intolerant of self-imposed, sometimes fashionable changes of product roadmaps: instead they want a trust-based, long-lasting relationship with a reliable service provider. And they only want to pay for the actual value this relationship presents to them: making more effective use of the one and only rare material we have access to: TIME. Because freed-up time creates room for agency, opportunity, urgency and agility. Secondary values are no less important: quality, reliability and peace of mind.
Service as Software will be switching the equation of cost vs. value around.
In my next post, we’re going to look into how this fundamental change should be reflected in organisational and leadership structures — in (software) companies, to make sure they can save themselves in the future. Spoilers: the COO role, the role of Forward-Deployed Engineers at Palantir, and use of agentic AI.
With love,
Steven.


As software creation becomes easier and easier, if the future does happen where code is generated almost instantly to cover the needs of the user/product designer, will the problem not be standardisations for inter-operability? Who will be the leaders of such standardisation efforts?