I’m Renan, I run OSS Ventures, the most awesome software for operations venture builder in the world (to my knowledge, we’re the only ones). In five years, we created 22 companies from scratch with founders, and we’re now live in 3000 operational sites in the world for roughly 100K users and 41Me ARR.
For most of the SaaS era, “productization” meant one very clear thing: make the product identical for everyone. Ninety-five percent of the usage identical, ninety-five percent of the backend identical. Smooth funnels, beautiful onboarding, a pristine UX, and integrations that — once done — stayed done. The ambition was to bottle repeatability. Ship once, sell many times. Then create absolutely smashing beautiful cohorts with cool numbers.
For a decade, that worldview made perfect sense. The cost of writing custom code was high; the cost of maintaining divergent logic was even higher; and the gravitational center of value was the UX. Every SaaS founder carried the same mantra: do not do professional services, avoid client-specific logic, resist customizations at all costs. And we did, with some pride.
Then AI happened.
Start with the client
As per our ethos at OSS Ventures, we always start with conversations and deep understanding of clients. There’s a pattern we saw everywhere : while the blue collar productivity has largely been solved (the average blue collar in Europe is actually responsible for 2 to 5 million CAPEX investment and is much more akin to a coder coding machines and debugging than a hammer-wielding low-productivity guy), the white collar cost was what made P&L hard to operate in high-cost countries. Planners piloting one excel only, R&D managers doing 1 new design per month with very manual operations.
So we uncovered a simple truth : 10x productivity on those white collar functions had not been delivered by traditional SaaS. That was our kind of Solow paradox : SaaS everywhere, productivity boost dubious at best. So we went to work trying to solve for this.
Notes from the field
To solve the real thing — the kind you deploy in production, in dozens of factories, in live procurement teams, in quoting departments and quality cells where a mistake has a cost taught us a lot. Over the past year at OSS Ventures, building and deploying five AI-native companies and integrating AI across the rest of the portfolio, we stumbled into a simple truth: the old idea of productization is misaligned with reality. Not just slightly off — entirely insufficient.
The shift didn’t come from theory. It came from CTOs in our portfolio, meeting with each other behind closed doors, comparing scars. It came from long evenings in factories, debugging why a model behaved differently on two lines that “should” have been identical. It came from understanding that AI is probabilistic, context-heavy, and surprising — and that no amount of wishful thinking can turn it into deterministic SaaS.
What emerged from those conversations is a new conviction: in entreprise AI, productization no longer means sameness. It means reusability under the hood, and contextual adaptation everywhere else. Think Palantir Foundry : 60% core platform, 40% ad-hoc for the client.
The economic equation has flipped. The cost of writing code has collapsed. The cost of maintaining divergent UX flows has collapsed. But the cost of running models — especially at scale, especially with quality — has exploded. So the logic reverses: you no longer optimize for minimizing bespoke code. You optimize for maximizing reuse of AI-critical modules while embracing that the final shape of each deployment will differ. Also, the high price (because of the immense value created) that can be passed to the client allows for more customization.
One of our companies now maintains more than ninety internal AI sub-modules, each designed for a specific job: classification, anomaly detection, document parsing, feasibility scoring, quoting heuristics, validation layers, workflow sequencing, drift detection, and so on. Those modules are a mix of well-known brands, purpose-specific, contributed to open source modules, ad-hoc and proprietary modules. Every new client adds edge cases, teaches something new, and the module library grows stronger. The product isn’t one monolith. It’s a toolbox being recombined, refined, and battle-tested across contexts. The repeatability lives there — not in forcing every client to walk the same UX path. Funnily enough, this particular company has no front-end because they embbed the results in the core existing systems of the client.
The moat, therefore, is not the “platform.” It is the accumulation of these internal modules, the proprietary datasets they are trained on, and the operational knowledge acquired from real deployments. You do not win by designing a perfect generic product. You win by being the only company that has seen a hundred weird edge cases across a hundred factories and distilled them into primitives, thus enabling true value creation at scale.
The price to pay on team structure
This has immense implications for teams.
First, it kills the idea of the non-technical product manager. In the age of AI, UX decisions are not separable from architecture decisions. The right workflow is often dictated by model performance, safety constraints, or uncertainty tolerances. “The user should fill this field manually because current models misclassify it 7% of the time in this context” is a product decision. But it is also a deeply technical one. Teams need people who can reason across both domains. The bar rises. Ten-times engineers make the right calls; one-times don’t. And the penalty for wrong calls is much higher.
Second, it explains the rise — and necessity — of the Forward Deployed Engineer. Silicon Valley adopted them years ago; Europe is now catching up. When every deployment has a bespoke layer, you need engineers who live with the client, understand the process, adapt the modules, influence the UX, and close the loop between real-world constraints and the evolving library. It is not consulting. It is product development in the wild.
Third, it clarifies why so many SaaS companies of the 2010–2020 era are struggling to “add AI.” Their DNA is built around sameness. Their teams are structured around abstraction. Their revenue model punishes divergence. Their culture resists messy reality. But AI-native products thrive precisely in the mess — in integrating with legacy ERPs that should have been retired in 2004, in tuning heuristics around machine behaviors, in ingesting email chains written in five languages, in aligning logic with fifty local operating modes. Adding AI on top of a SaaS product is easy; building an AI-native company on top of a SaaS mindset is nearly impossible.
We’ve come to see the shift this way: SaaS was about opinionated universality. Entreprise AI is about composable specificity.
And this is not a step backward. It’s a step toward truth.
Factories are not identical. Procurement teams are not identical. Quoting processes are not identical. Even two machines of the same reference, bought in the same year, operated by teams trained under the same SOPs, behave differently after six months. Anyone who has stepped into real operations knows this intuitively.
AI forces software to finally reflect that truth. It asks us to build products that adapt, not products that pretend the world is flatter than it is. It rewards teams who embrace context instead of resisting it.
This new form of productization is emerging quietly, in the trenches.
It’s a multi-year accumulation of proprietary modules.
It’s increasingly deep integrations into client systems, not as a burden but as an advantage — because integration is where the data lives, and the data is where the edge comes from.
It’s small teams of engineers and founders going line by line through workflows and discovering: “Ah. This part must be a module. This part must be manual. This part must be validated. This part can be fully automated.”
It’s realizing that “horizontal AI” is a fantasy, but “scalable modularity with bespoke assembly” is not. The front may look the same but under the hood, it’s way different.
This way of building is slower at the beginning. More painful. More grounded. But it compounds in a way that SaaS never could. Each deployment makes the next one easier. Each client adds to the intelligence of the system. Every forward deployed engineer is a node in a growing knowledge network.
And step by step, the product becomes something that no competitor can copy: not the demo, not the interface, not even the models — but the entire accumulated system behind them.
When I look at our five AI-native companies today, I don’t see SaaS products. I see evolving codebases shaped by real-world entropy. I see teams who have embraced uncertainty not as a bug, but as a constraint of the medium. And I see products that are becoming more powerful precisely because they stopped trying to be identical.
Maybe that’s the quiet revolution.
That in the age of AI, software stops trying to simplify the world — and starts trying to understand it.
How to explain this to my friendly european VC ?
Frankly ? I don’t know. As the joke goes, “when apocalypse hit, better be in Europe because everything happens 5 years later”. Some of our portfolio companies with stellar numbers (think 600K ARR year 1 bootstrapped with 200K contracts deployed and 10x ROIs) are getting passed on for “not having SaaS defensibility”. They’ll get access to capital (they always do, fingers crossed) but the reasons were puzzling.
For the investment community, I think there is a very high cost of opportunity trying to get entirely new assets in old boxes. Our internal calculations at OSS show that past the first year professional service year, the AI margin can be actually higher than traditional SaaS under certain conditions : passing the new inference cost to client without additional margin — which proves easy in manufacturing because clients want the thing to live in their systems anyways, and getting the users to do the heavylift of the maintenance work — in other words, design for the sys admin of the newly formed system.
If you are building in this space, or thinking about it, or wrestling with similar questions, I’d be happy to exchange. These are early reflections, still in motion. Reality will no doubt correct them. It always does. But that’s the fun part of building.